Next Version of Lua?

classic Classic list List threaded Threaded
143 messages Options
12345678
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (__setindex metamethod)

Mark Hamburg
With regard to __setindex, I was just thinking this morning about the  
costs associated with creating read-only tables and thinking that it  
would be worth benchmarking the approach of using a stub userdata:

        ud.mt = { __index = read-only-table }

And using a proxy table:

        {}.mt = { __index = read-only-table, __newindex = error-function }

__setindex would be the simplest option but would then need to be  
benchmarked for its effect on all table assignments.

Mark

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Asko Kauppi
In reply to this post by Niklas Frykholm

About the complex type, LNUM patch allows all Lua numbers to be  
complex (compile with LNUM_COMPLEX defined; C99 required for C complex  
support).

The approach could of course be extended to making a native 3D vector  
datatype, as well.

-asko


Niklas Frykholm kirjoitti 10.6.2009 kello 17:42:

> 2009/6/10 Duncan Cross <[hidden email]>:
>> On Wed, Jun 10, 2009 at 2:55 PM, Niklas  
>> Frykholm<[hidden email]> wrote:
>>> 2009/6/10 Olivier Hamel <[hidden email]>:
>>> Currently, if you want to create Complex or Vector3 type you have to
>>> do it as a table or a userdata. And if you do a serious ammount of
>>> processing on them, the ammount of garbage generated by simple
>>> arithmetic operations will soon put a significant strain on the
>>> system. (You could use a pool of such objects, but that would mean
>>> resorting to manual memory management with all its pains -  
>>> especially
>>> when you are using it for something as simple as numbers.)
>>
>> Perhaps I am misunderstanding, but if the pool is a table that has
>> been set to have weak values (i.e. its metatable's __mode field is  
>> set
>> to 'v'), you should not have to do any manual memory management -
>> values that only exist in the pool will be eligible for garbage
>> collection.
>
> My description was a bit short, but the whole point of having a pool
> was to avoid generating garbage. (By using a free object from the
> pool, rather than creating a new one, whenever a new object is
> needed.) But this requires us to manually track which objects in the
> pool are free or not (i.e., manual memory management).
>
> If the objects in the pool are eligible for garbage collection, then
> the pool doesn't really buy us anything. We will generate the same
> ammount of garbage with the pool as without it.
>
> // Niklas

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

jbsnyder
Administrator
In reply to this post by Luiz Henrique de Figueiredo

On Jun 10, 2009, at 5:24 AM, Luiz Henrique de Figueiredo wrote:
>
>> * VM: Add support for __overrideindex (as the meta-method's name
>> suggest, override a key in the table which already contains a non-nil
>> value with a new value, nil or otherwise)
>
> The usual answer is to use proxies.


Proxies work well for a fair number of things, except for some types  
of lazy evaluation like accessing tables in a remote Lua environment.  
If one wants to do things like call functions in the remote  
environment, but also be able to index values on remote tables and  
have them be able to be accessed locally, it is difficult to decide  
when a series of __index events should result in returning another  
proxy vs returning the value on the table.

Say for example you have a handle for the remote environment,  
conveniently called "handle":

handle.foo.bar(a,b,c)

It's pretty easy to know how to deal with this situation since it  
includes a call, but what if that same remote table called foo has a  
value on it that I want:

local_value = handle.foo

Do I make local_value a proxy or the actual value?  The metatable  
hooks allow for dealing with a number of operations, but what if I  
just want to do somehting like:

math.cos(local_value)

It would be nice to be able to hook things maybe at the index2adr  
level, or provide some way so that when the actual type is checked or  
looked up that the value could be pulled down just before the operation.

Some of this functionality could come from adding a __tonumber, and  
covering a few more type conversions, but this would provide a more  
general lazy evaluation hook.

I assume it would also potentially slow down every lookup for data,  
but perhaps there's some way to make that hit negligible?

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt
ph: (847) 448-0386


PGP.sig (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Roberto Ierusalimschy
In reply to this post by Olivier Hamel
> Roberto said they (inner Lua dev group) weren't happy with any known  
> implementation of bitwise operators, it would be helpful to know what  
> they are not pleased with so we may propose alternate  
> solutions/implementations.

My dream was bitwise operators that make sense for floating numbers,
like shifts and negation do. But I gave up.

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Enrico Colombini
Roberto Ierusalimschy wrote:
> My dream was bitwise operators that make sense for floating numbers,
> like shifts and negation do. But I gave up.

Well, having an 'official' bitlib will be convenient in any case, even
with some limitations.

   Enrico
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Olivier Hamel
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:

>> Roberto said they (inner Lua dev group) weren't happy with any known  
>> implementation of bitwise operators, it would be helpful to know what  
>> they are not pleased with so we may propose alternate  
>> solutions/implementations.
>>    
>
> My dream was bitwise operators that make sense for floating numbers,
> like shifts and negation do. But I gave up.
>
> -- Roberto
>
>  
Oh. Well. Yah, you won't be getting very far with bitwise ops on float,
I suggest that floats be cast to ints (or whatever) and then the ops
performed on them. It's common knowledge you won't be getting bitwise
ops on floats natively/naturally unless you add some (a lot) of magic
powder to the mix with a slice of lemon. But even there, I don't thing
the idea of bitwise ops can ever EVER apply to floats, since their
internal representation does not match that of a 'simpler' number like
char/short/int/etc... That said, I had in mind to use bitwise ops on
whole numbers anyways...

Have we considered adding fixed point precision numbers?

Olivier

Reply | Threaded
Open this post in threaded view
|

RE: Next Version of Lua? (__iter metamethod)

John Hind
In reply to this post by Adrian Sietsma
> -----Original Message-----
> From: [hidden email] [mailto:lua-
> [hidden email]] On Behalf Of Adrian Sietsma
> Sent: 10 June 2009 16:20
> To: Lua list
> Subject: Re: Next Version of Lua? (__iter metamethod)
>
> I often have multi-use tables, such that t[id] = t[n] = object.
> I can then lookup objects by id, or iterate them with ipairs.
> In this case, how would your code 'contextually select' the iterator ?
>

So why would you want to use "pairs" in this case? If your table meets the
requirements for "ipairs" and you do not care what order the elements are
returned in, what is wrong with "ipairs"? Either "ipairs" works and is
sufficient, or it does not, in which case you have to use "pairs". In any
case, metamethods only impact if you choose to use them, so nothing breaks
your code. Why would you want to use the proposed "__pairs" or "__ipairs"
metamethods?

> > Apart from this consideration of principle, it is using two
> metamethods to
> > do a half-assed job that could be properly done with just one!
> Is the solution half-assed, or your understanding of the problem ?
>

Always possible, as of course may be your understanding! Actually I do not
think there is a problem here - just an opportunity for improvement, or for
taking a backward step.



Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Roberto Ierusalimschy
In reply to this post by Enrico Colombini
> Roberto Ierusalimschy wrote:
>> My dream was bitwise operators that make sense for floating numbers,
>> like shifts and negation do. But I gave up.
>
> Well, having an 'official' bitlib will be convenient in any case, even  
> with some limitations.

Sure. We will probably add a "standard" bitlib in the standard libraries.

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re[2]: Next Version of Lua?

Bulat Ziganshin
In reply to this post by Mark Hamburg
Hello Mark,

Wednesday, June 10, 2009, 6:57:00 PM, you wrote:

> ViewList = {
>         Button( "I'm always here" ),
>         Optional( TestCondition(), Button( "Condition Was True" ) )
>         Button( "I'm always here too" )
> }

i don't used Ruby for a while, but afair, it uses "*" on both sides
(caller and callee):

f(a,b,*rest_of_args)

def f (a,b,*rest_of_args)
...
end

so we may try to expand {a,b,*x,c,d} to append( append({a,b},x), {c,d})


--
Best regards,
 Bulat                            mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Jim Mellander
In reply to this post by Olivier Hamel
Olivier Hamel wrote:

> Roberto Ierusalimschy wrote:
>>> Roberto said they (inner Lua dev group) weren't happy with any known
>>> implementation of bitwise operators, it would be helpful to know
>>> what  they are not pleased with so we may propose alternate
>>> solutions/implementations.
>>>    
>>
>> My dream was bitwise operators that make sense for floating numbers,
>> like shifts and negation do. But I gave up.
>>
>> -- Roberto
>>
>>  
> Oh. Well. Yah, you won't be getting very far with bitwise ops on float,
> I suggest that floats be cast to ints (or whatever) and then the ops
> performed on them. It's common knowledge you won't be getting bitwise
> ops on floats natively/naturally unless you add some (a lot) of magic
> powder to the mix with a slice of lemon. But even there, I don't thing
> the idea of bitwise ops can ever EVER apply to floats, since their
> internal representation does not match that of a 'simpler' number like
> char/short/int/etc... That said, I had in mind to use bitwise ops on
> whole numbers anyways...
>
> Have we considered adding fixed point precision numbers?
>
> Olivier
>
>

My 2nd favorite language (awk as implemented in gawk), which also uses a
double as the numeric type, takes the following tack when doing bitwise ops:

"For all of these functions, first the double-precision floating-point
value is converted to the widest C unsigned integer type, then the
bitwise operation is performed. If the result cannot be represented
exactly as a C double, leading nonzero bits are removed one by one until
it can be represented exactly. The result is then converted back into a
C double. (If you don't understand this paragraph, don't worry about it.)"

from http://www.gnu.org/manual/gawk/html_node/Bitwise-Functions.html

--
Jim Mellander
Incident Response Manager
Computer Protection Program
Lawrence Berkeley National Laboratory
(510) 486-7204

The reason you are having computer problems is:

Daemon escaped from pentagram
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Joshua Jensen
In reply to this post by Luiz Henrique de Figueiredo
----- Original Message -----
From: Luiz Henrique de Figueiredo
Date: 6/10/2009 4:24 AM
>> * Lexer Only: A continue statement is in dire need
>>    
> We don't see such a dire need for that. Plus it does have semantics problems,
> due to upvalues in closures, discussed here in the past.
>  
Every person I train in Lua asks me why 'continue' doesn't work.  I show
them the "equivalent", and it never meets with any kind of satisfaction.

for index = 1, 10 do repeat
    if index == 5 then break end
    -- do stuff
until true end

The standard alternative introduces nested code:

for index = 1, 10 do
    if index ~= 5 then
        -- do stuff
    end
end

I'm in the camp where I see a real need for it in Lua, not only for
clarity, but because it is a very useful loop construct that anyone
coming from another popular (scripting) language will expect to be able
to use.

Josh

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Asko Kauppi
In reply to this post by Olivier Hamel

Yes, we have.

http://lua-users.org/cgi-bin/namazu.cgi?query=fixed+point&idxname=lua-l&max=20&result=normal&sort=score


Olivier Hamel kirjoitti 10.6.2009 kello 19:16:

> Have we considered adding fixed point precision numbers?

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Asko Kauppi
In reply to this post by Jim Mellander

On the bitwise operations discussion:

If LNUM integer patch would be adopted, it would be natural to define  
the bit operations with 'lua_tointeger()' and giving an error if a  
value is not an integer.

Personally, I am of the opinion that bitops are for enums and not for  
numbers.  But there is no support for enums to Lua; thus, add enums  
first and rethink bitops then.

(But I do feel like Cato on this one....)

-asko


Jim Mellander kirjoitti 10.6.2009 kello 19:51:

> Olivier Hamel wrote:
>> Roberto Ierusalimschy wrote:
>>>> Roberto said they (inner Lua dev group) weren't happy with any  
>>>> known
>>>> implementation of bitwise operators, it would be helpful to know
>>>> what  they are not pleased with so we may propose alternate
>>>> solutions/implementations.
>>>>
>>>
>>> My dream was bitwise operators that make sense for floating numbers,
>>> like shifts and negation do. But I gave up.
>>>
>>> -- Roberto
>>>
>>>
>> Oh. Well. Yah, you won't be getting very far with bitwise ops on  
>> float,
>> I suggest that floats be cast to ints (or whatever) and then the ops
>> performed on them. It's common knowledge you won't be getting bitwise
>> ops on floats natively/naturally unless you add some (a lot) of magic
>> powder to the mix with a slice of lemon. But even there, I don't  
>> thing
>> the idea of bitwise ops can ever EVER apply to floats, since their
>> internal representation does not match that of a 'simpler' number  
>> like
>> char/short/int/etc... That said, I had in mind to use bitwise ops on
>> whole numbers anyways...
>>
>> Have we considered adding fixed point precision numbers?
>>
>> Olivier
>>
>>
>
> My 2nd favorite language (awk as implemented in gawk), which also  
> uses a
> double as the numeric type, takes the following tack when doing  
> bitwise ops:
>
> "For all of these functions, first the double-precision floating-point
> value is converted to the widest C unsigned integer type, then the
> bitwise operation is performed. If the result cannot be represented
> exactly as a C double, leading nonzero bits are removed one by one  
> until
> it can be represented exactly. The result is then converted back  
> into a
> C double. (If you don't understand this paragraph, don't worry about  
> it.)"
>
> from http://www.gnu.org/manual/gawk/html_node/Bitwise-Functions.html
>
> --
> Jim Mellander
> Incident Response Manager
> Computer Protection Program
> Lawrence Berkeley National Laboratory
> (510) 486-7204
>
> The reason you are having computer problems is:
>
> Daemon escaped from pentagram

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Petite Abeille

On Jun 10, 2009, at 7:47 PM, Asko Kauppi wrote:

> (But I do feel like Cato on this one....)

Cato? As Cato the Elder? Carthage must be destroyed!!!!

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Enrico Colombini
In reply to this post by Asko Kauppi
Asko Kauppi wrote:
> Personally, I am of the opinion that bitops are for enums and not for
> numbers.  

Apart from many data processing applications... as an example, consider
the case where I open a bitmap file and want to apply some algorithm to
4-bit pixels.

   Enrico
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Javier Guerra Giraldez
In reply to this post by Petite Abeille
On Wed, Jun 10, 2009 at 12:54 PM, Petite
Abeille<[hidden email]> wrote:
>
> On Jun 10, 2009, at 7:47 PM, Asko Kauppi wrote:
>
>> (But I do feel like Cato on this one....)
>
> Cato? As Cato the Elder? Carthage must be destroyed!!!!

or Kato, the Green Hornet sidekick, played by Bruce Lee? (which was
beaten by Robin when Batman fight the Green Hornet!)

or Cato, the Inspector Clouseau's house boy?

--
Javier
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Roberto Ierusalimschy
In reply to this post by Joshua Jensen
> Every person I train in Lua asks me why 'continue' doesn't work.  I show  
> them the "equivalent", and it never meets with any kind of satisfaction.
>
> [...]
>
> I'm in the camp where I see a real need for it in Lua, not only for  
> clarity, but because it is a very useful loop construct that anyone  
> coming from another popular (scripting) language will expect to be able  
> to use.

Any comment about this?

  http://lua-users.org/lists/lua-l/2005-09/msg00548.html

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Asko Kauppi
In reply to this post by Enrico Colombini

The whole idea is longer than I feel like repeating here and now. It  
does allow operations like you mention by use of "non-family" enums.

It has been discussed on the list earlier, and concensus was that  
there's no need. C API enums can be done with Lua strings instead.  I  
still hold my position on this, though (and can repeat the discussions  
if someone sees necessary).

-asko


Enrico Colombini kirjoitti 10.6.2009 kello 20:59:

> Asko Kauppi wrote:
>> Personally, I am of the opinion that bitops are for enums and not  
>> for numbers.
>
> Apart from many data processing applications... as an example,  
> consider the case where I open a bitmap file and want to apply some  
> algorithm to 4-bit pixels.
>
>  Enrico

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (__iter metamethod)

Sam Roberts
In reply to this post by Peter Cawley
On Wed, Jun 10, 2009 at 7:41 AM, John Hind<[hidden email]> wrote:
> Looking at it fundamentally, any object that implements collection semantics
> benefits from iterator functionality. "pairs" is appropriate for
> dictionary-like collections (whether implemented using tables or otherwise)
> while "ipairs" is appropriate for "list" or "array" like collections
> (whether implemented using tables or otherwise). With basic Lua whether a
> table is "dictionary-like" or "list-like" is about how you assign the keys,

Its not an "or". Its a fairly common lua design idiom for tables to be
BOTH dictionary-like and list-like.

I've never used another language like this, so
maybe its unusual, but its fundamental to the flavour of the language, and
used to good effect.

I've built tree-like structures where ipairs() is used to iterate the
children, and string keys are used for annotations on the node (and
pairs is used to iterate all keys). There's an example like this in
_Programming in Lua_, but I can't find it, sorry.

Anyhow, the __pairs and __ipairs allows userdata to be first-class
citizens, closer to full table-like functionality, not just limited to
"array EXCLUSIVE-OR dictionary", and a single iteration strategy.

> but with true object orientation (using metatables) you will usually decide
> the structure of the table in the class design. OK sometimes an object

Userdata are not required to be used as part of an O-O class design,
though they can be. Lua is multi-paradigm.

Cheers,
Sam
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Asko Kauppi
In reply to this post by Roberto Ierusalimschy

Roberto Ierusalimschy kirjoitti 10.6.2009 kello 21:03:

>> Every person I train in Lua asks me why 'continue' doesn't work.  I  
>> show
>> them the "equivalent", and it never meets with any kind of  
>> satisfaction.
>>
>> [...]
>>
>> I'm in the camp where I see a real need for it in Lua, not only for
>> clarity, but because it is a very useful loop construct that anyone
>> coming from another popular (scripting) language will expect to be  
>> able
>> to use.
>
> Any comment about this?
>
>  http://lua-users.org/lists/lua-l/2005-09/msg00548.html
>
> -- Roberto

It is curious that the number of times I have missed 'continue'  
exceeds the number of times I've needed 'repeat' (which is 0).

But that's just me. :)

-asko


12345678