Next Version of Lua?

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

Next Version of Lua?

Olivier Hamel
Probably way pre-mature but I can resist asking, does anyone but Roberto
know anything of what will be the next version of Lua? I'm interested
because from what I've seen Lua has a (good?) peculiar tendency to
radically change it's 'feel'/design radically at each iteration.

Just interested in knowing what might be in the next version, partially
because I can't think of anything to add other than a few minor features
(different numerics support, built-in/standardized bitwise ops,
integeral divisions, most of these are available via patches but it'd be
nice IMHO if they were standard).

Apologies ahead of time if I'm ahead of things here...
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Jim Whitehead II
On Wed, Jun 10, 2009 at 9:15 AM, Olivier Hamel<[hidden email]> wrote:
> Probably way pre-mature but I can resist asking, does anyone but Roberto
> know anything of what will be the next version of Lua? I'm interested
> because from what I've seen Lua has a (good?) peculiar tendency to radically
> change it's 'feel'/design radically at each iteration.

The wiki page that someone started last year is probably the closest
we have right now: http://lua-users.org/wiki/LuaFiveTwo

>
> Just interested in knowing what might be in the next version, partially
> because I can't think of anything to add other than a few minor features
> (different numerics support, built-in/standardized bitwise ops, integeral
> divisions, most of these are available via patches but it'd be nice IMHO if
> they were standard).
>
> Apologies ahead of time if I'm ahead of things here...
>
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Meer, H. van der
In reply to this post by Olivier Hamel
In the message from Jim Whitehead II [hidden email]:

On Wed, Jun 10, 2009 at 9:15 AM, Olivier Hamel<[hidden email]> wrote:
Probably way pre-mature but I can resist asking, does anyone but Roberto
know anything of what will be the next version of Lua? I'm interested
because from what I've seen Lua has a (good?) peculiar tendency to radically
change it's 'feel'/design radically at each iteration.

The wiki page that someone started last year is probably the closest
we have right now: 
http://lua-users.org/wiki/LuaFiveTwo


I examined the LuaFiveTwo page mentioned above and saw the discussion on the implementation of bitmaps:

some form of bit operations. (We are not very happy with any known implementation. Maybe just incorporate bitlib?)

As I did a bitmap implementation, I hereby add its html-docs of this for what it is worth in the discussion. Interested parties can find the code here (use it with due credit): http://staff.science.uva.nl/~hansm/publications.html

Hans van der Meer






bits.html (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Olivier Hamel
Hans van der Meer wrote:

> In the message from Jim Whitehead II [hidden email]
> <mailto:[hidden email]>:
>
> I examined the LuaFiveTwo page mentioned above and saw the discussion
> on the implementation of bitmaps:
>
>> some form of bit operations. (We are not very happy with any known
>> implementation. Maybe just incorporate bitlib?)
>
> As I did a bitmap implementation, I hereby add its html-docs of this
> for what it is worth in the discussion. Interested parties can find
> the code here (use it with due
> credit): http://staff.science.uva.nl/~hansm/publications.html 
> <http://staff.science.uva.nl/%7Ehansm/publications.html>
>
> Hans van der Meer
>
My first thought when I read 'bitmaps' was Win32 bitmaps, after which I
read this and it seems to be some sort of massive array of bits which
can be manipulated? Oh wait, this is a wrapping of a number handled as
an object /w metamethods, correct? If it is then this is a new take on
the problem I hadn't considered at all! Nice to see a new take on the
problem, but I'd be annoyed at using such an interface when I want to
just do i = i << 1 and then use i for some other calculation.

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.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

steve donovan
On Wed, Jun 10, 2009 at 11:15 AM, Olivier Hamel<[hidden email]> 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.
>

Mike Pall's LuaBit is likely to become a de-facto standard, expecially
when LuaJIT 2.x comes along and these operations are supported
directly.

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Olivier Hamel
steve donovan wrote:

> On Wed, Jun 10, 2009 at 11:15 AM, Olivier Hamel<[hidden email]> 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.
>>
>>    
>
> Mike Pall's LuaBit is likely to become a de-facto standard, expecially
> when LuaJIT 2.x comes along and these operations are supported
> directly.
>
> steve d.
>
>  
That's another thing, anyone heard from his top-secret underground
laboratory on LuaJIT 2.x's progress? Has anyone considered
promoting/heiring him full time for LuaJIT? A x64 port would make this a
lot more portable & attractive for commercial/multi-platform apps,
though from what I know of assembly it'll be a pain to do (perhaps just
for me because I'm a complete newcomer to it).
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Meer, H. van der
In reply to this post by Olivier Hamel


On 10 jun 2009, at 11:15, Olivier Hamel wrote:

Hans van der Meer wrote:
As I did a bitmap implementation, I hereby add its html-docs of this for what it is worth in the discussion. Interested parties can find the code here (use it with due credit): http://staff.science.uva.nl/~hansm/publications.html <http://staff.science.uva.nl/%7Ehansm/publications.html>

My first thought when I read 'bitmaps' was Win32 bitmaps, after which I read this and it seems to be some sort of massive array of bits which can be manipulated?

Yes, it is an array of bits, packed as tight as can be. Bits in the array can be set, queried and iterated on. The testfile in the package does a prime number sieve of Eratosthenes as an example, showing that very many boolean flags can be manipulated comfortably.

Oh wait, this is a wrapping of a number handled as an object /w metamethods, correct?

Indeed, metamethods may be used for combining bitmaps with AND, OR, XOR.

If it is then this is a new take on the problem I hadn't considered at all! Nice to see a new take on the problem, but I'd be annoyed at using such an interface when I want to just do i = i << 1 and then use i for some other calculation.

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.

The module cannot do arithmetic operations(like i<<1 or i>>1 for doing powers of two). It was not designed as such and I agree with the quote of Roberto in that one should not lightly tamper with arithmetics.

Hans van der Meer

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Olivier Hamel
Hans van der Meer wrote:

>
> Yes, it is an array of bits, packed as tight as can be. Bits in the
> array can be set, queried and iterated on. The testfile in the package
> does a prime number sieve of Eratosthenes as an example, showing that
> very many boolean flags can be manipulated comfortably.
>
> Indeed, metamethods may be used for combining bitmaps with AND, OR, XOR.
>
> The module cannot do arithmetic operations(like i<<1 or i>>1 for doing
> powers of two). It was not designed as such and I agree with the quote
> of Roberto in that one should not lightly tamper with arithmetics.
>
> Hans van der Meer
>
In all respect, I beg to differ. Quite a few algorithms could be
significantly improved/facilitated/made implementable with such direct
bitwise ops, though I agree that adding << and >> just for performing
powers of two is indeed a waste, but I'd only used those as an example.
Your implementation seems to handle bitflags well, which is the main
reason (for me at least, that + some algorithms) I'm hoping for bitwise
ops. But I'd think it'd be more overhead/bother to do (sorry don't have
the ref sheet with me ATM so please bear as I use the incorrect
constructs/method calls):

local WASDActive = bitmap.Create(FLAG_KEYBOARD_W, FLAG_KEYBOARD_A,
FLAG_KEYBOARD_S, FLAG_KEYBOARD_D)
ExplodePlayerIfWASDIsPressed(WASDActive:GetValue())

Instead of:

ExplodePlayerIfWASDIsPressed(FLAG_KEYBOARD_W | FLAG_KEYBOARD_A |
FLAG_KEYBOARD_S | FLAG_KEYBOARD_D)

Adding your object as a core type might be a solution, but then that
adds a kludge to Lua's otherwise (near-?)perfect type universe.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Eike Decker
> local WASDActive = bitmap.Create(FLAG_KEYBOARD_W, FLAG_KEYBOARD_A,
> FLAG_KEYBOARD_S, FLAG_KEYBOARD_D)
> ExplodePlayerIfWASDIsPressed(WASDActive:GetValue())
>
> Instead of:
>
> ExplodePlayerIfWASDIsPressed(FLAG_KEYBOARD_W | FLAG_KEYBOARD_A |
> FLAG_KEYBOARD_S | FLAG_KEYBOARD_D)
>

Actually you don't need bitwise OR to do that kind of operation. You
could also write:

ExplodePlayerIfWASDIsPressed(FLAG_KEYBOARD_W + FLAG_KEYBOARD_A +
  FLAG_KEYBOARD_S + FLAG_KEYBOARD_D)

The + operation is equivalent (to my knowledge) to the bitwise |
operation as long as the bits that are used are not overlapping, for
example (binary):
010 + 100 = 010 | 100 = 110
010 + 010 = 100  ~= 010 | 010 = 010

Combining bit flags with an add operation works well that way as long
as this is respected. Even if true bitwise OR is needed, you could
still write a wrapper to handle it this way:

ExplodePlayerIfWASDIsPressed( bOR(FLAG_KEYBOARD_W, FLAG_KEYBOARD_A,
FLAG_KEYBOARD_S, FLAG_KEYBOARD_D))

... which would hardly be more ugly than the C-like counterpart.

Eike
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Olivier Hamel
In reply to this post by Jim Whitehead II
Jim Whitehead II wrote:

> On Wed, Jun 10, 2009 at 9:15 AM, Olivier Hamel<[hidden email]> wrote:
>  
>> Probably way pre-mature but I can resist asking, does anyone but Roberto
>> know anything of what will be the next version of Lua? I'm interested
>> because from what I've seen Lua has a (good?) peculiar tendency to radically
>> change it's 'feel'/design radically at each iteration.
>>    
>
> The wiki page that someone started last year is probably the closest
> we have right now: http://lua-users.org/wiki/LuaFiveTwo
>
>  
>> Just interested in knowing what might be in the next version, partially
>> because I can't think of anything to add other than a few minor features
>> (different numerics support, built-in/standardized bitwise ops, integeral
>> divisions, most of these are available via patches but it'd be nice IMHO if
>> they were standard).
>>
>> Apologies ahead of time if I'm ahead of things here...
>>
>>    

Ah, I thank you for point this page out to me. I'll take this
opportunity to dump my suggestions/wishes/hopes for Lua 5.2. Basically
Lua 5.1 is very close to what I would consider the penultimate scripting
language (please no Swiss Army Chainsaws!), so I propose we basically
keep it as it is except for the following changes (more than willing to
hear counter-points/arguments on this though):

Numerics Related:
* Lexer Only: Hex format definition (you know, 0x00000000, 0x0F001CE0,
etc...)
* VM + Lexer (+ metatables?): Support for most/all bitwise ops
* VM + Lexer (+ metatables?): Integeral division

Coroutines:
* VM: Coco patch integration?

Syntax:
* Lexer Only: A continue statement is in dire need, I've found myself
often wrapping large segments (read: rest of loop code) in a big
if-then-end block because I couldn't do if-then-continue-end
* (VM?) + Lexer: Have an explicitly defined handling of cases like {[3]
= 3, 1, 2, 3} and do not adjust the return codes to one unless an
operation is directly performed on it. Example:
local tbl = {ReturnSixIncrementalValuesFromZeroToSix(), 7, 8, 9} -- this
would equate to doing {1, 2, 3, 4, 5, 6, 7, 8, 9}
local tbl = {ReturnSixIncrementalValuesFromZeroToSix() + 10, 7, 8, 9} --
this would equate to doing {11, 7, 8, 9}
The alternate suggestion of using ';' to elaborate when to use multiple
returns might be better (feedback on this please?)?

Metamethods:
* VM: Add support for __ne, __gt, and __ge (not equal, greater than,
greater than or equal to); Would this impact performance in any
significant way?
* 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)
* VM: Add support for __finalize (do-able? or would it drive the
collector insane?)

Strings:
* C Std Lib: UTF-8 string support, (would require update of just the
string library + math.char?)
* C Std Lib: More powerful support for format/additional functions like
string split/explode (Only if there is enough interest? Is anyone
interested in that anyways?)

Virtual Machine:
* VM: Optional time-delayed bailout (setmaxexectime(<non negative number
representing seconds for a state to return to c completely, otherwise
it's killed/forced bailout>? Doesn't seem too critical, perhaps leave it
to people to implement as power-patch?)

'Module' Function:
* Global Std Function: Change behaviour so it detects if the return
value of require is not assigned to a variable and, and only then,
create a global table with the module name. For people who say "if
module Foo requires module Bar and people code expecting Bar after they
require Foo, and then Foo is changed and no longer requires Bar then
it'll causes errors." should consider the fact that they should be
requiring both Foo and Bar explicitly if they are using both. Pardon me
but this is just common sense and good practice.
Additionally people should be choosing good module names and NOT
polluting the global env unnecessarily anyways, so saying that a
collision might occur is stretching it a bit (read: a lot) far  IMHO.

And that's all I can think of at the moment... I'll be sure to chip in
anything else I can think of...
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Olivier Hamel
In reply to this post by Eike Decker
Eike Decker wrote:

>
> Actually you don't need bitwise OR to do that kind of operation. You
> could also write:
>
> ExplodePlayerIfWASDIsPressed(FLAG_KEYBOARD_W + FLAG_KEYBOARD_A +
>   FLAG_KEYBOARD_S + FLAG_KEYBOARD_D)
>
> The + operation is equivalent (to my knowledge) to the bitwise |
> operation as long as the bits that are used are not overlapping, for
> example (binary):
> 010 + 100 = 010 | 100 = 110
> 010 + 010 = 100  ~= 010 | 010 = 010
>
> Combining bit flags with an add operation works well that way as long
> as this is respected. Even if true bitwise OR is needed, you could
> still write a wrapper to handle it this way:
>
> ExplodePlayerIfWASDIsPressed( bOR(FLAG_KEYBOARD_W, FLAG_KEYBOARD_A,
> FLAG_KEYBOARD_S, FLAG_KEYBOARD_D))
>
> ... which would hardly be more ugly than the C-like counterpart.
>
> Eike
>  
True, I guess we'll leave it up to Roberto to decide unless someone can
present a convincing counter-argument. (If he ever decides to tell us
what he doesn't like about our current implementations.)
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

steve donovan
In reply to this post by Olivier Hamel
On Wed, Jun 10, 2009 at 12:02 PM, Olivier Hamel<[hidden email]> wrote:
> Basically Lua 5.1 is very
> close to what I would consider the penultimate scripting language (please no
> Swiss Army Chainsaws!)

Amen! The world already has enough of those!

> * Lexer Only: Hex format definition (you know, 0x00000000, 0x0F001CE0,

It does this already, last time I checked (-3 secs ago) Are you
thinking of hex string literals?

> * VM + Lexer (+ metatables?): Support for most/all bitwise ops

As operators? I think most of us would live with a set of 'blessed'
functions to do this.

> Syntax:
> * Lexer Only: A continue statement is in dire need, I've found myself often
> wrapping large segments (read: rest of loop code) in a big if-then-end block
> because I couldn't do if-then-continue-end

Yeah, that's a good one. This crops up fairly frequently.

> * (VM?) + Lexer: Have an explicitly defined handling of cases like {[3] = 3,
> 1, 2, 3} and do not adjust the return codes to one unless an operation is
> directly performed on it. Example:

The thing, we're used to the rule that multiple args only get expanded
at the end of a table ctor. Maybe an explicit 'explode' function, but
keeping the default behaviour? Changes like this can break lots of
code.

> Metamethods:
> * VM: Add support for __ne, __gt, and __ge (not equal, greater than, greater
> than or equal to); Would this impact performance in any significant way?

That's the big question, seeing as it is such a basic operation. Time
for experiments, anyone?

> * 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)

OK, so like __setindex if the key is nil, but works even otherwise.
You can then override '=' for keys basically.  But there are tricks
you can use already to get this effect, e.g. the key is actually
called '_a' but use __setindex so that 'A.a = 2' updates _a, etc.

> * VM: Add support for __finalize (do-able? or would it drive the collector
> insane?)

I like RAII so this would really be good.

> * C Std Lib: More powerful support for format/additional functions like
> string split/explode (Only if there is enough interest? Is anyone interested
> in that anyways?)

They're very useful, but pure Lua implementations are usually fast enough.

> Additionally people should be choosing good module names and NOT polluting
> the global env unnecessarily anyways, so saying that a collision might occur
> is stretching it a bit (read: a lot) far  IMHO.

This is a wisdom problem, not a Lua problem ;)

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Luiz Henrique de Figueiredo
In reply to this post by Olivier Hamel
> * Lexer Only: Hex format definition (you know, 0x00000000, 0x0F001CE0,

You can do that already in 5.1.

> * VM: Coco patch integration?

Not direct integration, but 5.2 will remove most restrictions on
yielding across metamethod/C-call boundaries.

> * 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.

> local tbl = {ReturnSixIncrementalValuesFromZeroToSix(), 7, 8, 9} -- this
> would equate to doing {1, 2, 3, 4, 5, 6, 7, 8, 9}

This is a bad idea.

> * 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.

> * C Std Lib: UTF-8 string support

Best supplied by external libraries.

Thanks for the suggestions.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Olivier Hamel
In reply to this post by steve donovan
steve donovan wrote:
> On Wed, Jun 10, 2009 at 12:02 PM, Olivier Hamel<[hidden email]> wrote:
>  
> It does this already, last time I checked (-3 secs ago) Are you
> thinking of hex string literals?
>  
Oops, yah. My mistake, sorry!

> As operators? I think most of us would live with a set of 'blessed'
> functions to do this.
That could work, I just think it'd be/feel more elegant/neater to make
them ops, then perhaps we can meta-overload them as well... ?
> The thing, we're used to the rule that multiple args only get expanded
> at the end of a table ctor. Maybe an explicit 'explode' function, but
> keeping the default behaviour? Changes like this can break lots of
> code.
>  
That will not be an issue, Roberto has already publicly confirmed he
will be break everyone's code anyways:
"Lua 5.2 is allowed to make design changes that break full
compatibility." :p

But I do get your point, but the problem is that such an explode
function would also be under the restrictions as the original function
unless it were hacked deep into Lua, something I doubt would be popular
with Roberto + others (including me). Perhaps some sort of lexer marker
instead?
> OK, so like __setindex if the key is nil, but works even otherwise.
> You can then override '=' for keys basically.  But there are tricks
> you can use already to get this effect, e.g. the key is actually
> called '_a' but use __setindex so that 'A.a = 2' updates _a, etc.
>  
No, no, I mean, if it's NOT nil then the metamethod get's called, it
would allow you to create enforced single-assignment lists for example,
or prevent overriding of a meta-method in the metatable. To prevent a
new method from being inserted into the host table would require a
__setindex sort of scheme, though with __setindex you could check for
the current value of the key to check if it were nil. So __setindex
solves both aspects! :)
(Correct me if I'm wrong, but __setindex doesn't sound like any vanilla
meta-method I know of. Am I wrong?)

Olivier Hamel

Reply | Threaded
Open this post in threaded view
|

RE: Next Version of Lua?

John Hind
In reply to this post by Olivier Hamel
If this were a democracy (which it isn't probably explaining why we do not
have a 'Swiss Army Chainsaw'), I'd vote for a '__iter' metamethod so you
could provide a customised iterator factory for an object class. This would
allow syntax:

for k,v in obj do ... end

rather than the present (and in my no doubt controversial view, ugly and
error-prone):

for k,v in pairs(obj) do ... end

As a side note, I 'bodge' this using the '__call' metamethod in my own
object classes so I can write:

for k,v in obj() do ... end

Which is close, but not ideal particularly if you want to use '__call' for
something else as well. However it is sometimes neat to be able to
parameterise the iterator factory as you can with a '__call' override, for
example to specify iteration over a sub-list. It would be neat if this could
be allowed with '__iter', but you should be able to omit empty parenthesis
in this case.

> Metamethods:
> * VM: Add support for __ne, __gt, and __ge (not equal, greater than,
> greater than or equal to); Would this impact performance in any
> significant way?
> * 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)
> * VM: Add support for __finalize (do-able? or would it drive the
> collector insane?)
>

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (again, \x## notation)

Ico Doornekamp
In reply to this post by Luiz Henrique de Figueiredo
* On 2009-06-10 Luiz Henrique de Figueiredo <[hidden email]> wrote  :

> > * Lexer Only: Hex format definition (you know, 0x00000000, 0x0F001CE0,
>
> You can do that already in 5.1.

Indeed. But you still can not do "foo\x0f\x00\x1c\xe0bar".

I am the original poster of the '\x## notation' thread which has been
getting attention every now and then over the past weeks. A lot of
people have participated in this thread, and a lot of different opinions
were given, although most of those seem to be in favour of this future.

I am still very curious to hear if the Lua developers have managed to
form an official opinion on wether this is a feature likely to be added
to future Lua versions ?


--
:wq
^X^Cy^K^X^C^C^C^C
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

steve donovan
In reply to this post by Olivier Hamel
On Wed, Jun 10, 2009 at 12:57 PM, John Hind<[hidden email]> wrote:
> If this were a democracy (which it isn't probably explaining why we do not
> have a 'Swiss Army Chainsaw'), I'd vote for a '__iter' metamethod so you
> could provide a customised iterator factory for an object class. This would
> allow syntax:
>
> for k,v in obj do ... end
>
> rather than the present (and in my no doubt controversial view, ugly and
> error-prone):

I've missed that since 5.0, but I understand the rationale, in the
_absence_ of __iter!

I've found myself wishing I could iterate over my list objects with
'for v in l do..end', which would be a piece of cake with __iter.

steve d.

PS. An excellent comment on our gentle dictatorship. Gave me a laugh:

http://lua-users.org/lists/lua-l/2009-03/msg00202.html
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (again, \x## notation)

Olivier Hamel
In reply to this post by Ico Doornekamp
Ico wrote:

> * On 2009-06-10 Luiz Henrique de Figueiredo <[hidden email]> wrote  :
>
>  
>>> * Lexer Only: Hex format definition (you know, 0x00000000, 0x0F001CE0,
>>>      
>> You can do that already in 5.1.
>>    
>
> Indeed. But you still can not do "foo\x0f\x00\x1c\xe0bar".
>
> I am the original poster of the '\x## notation' thread which has been
> getting attention every now and then over the past weeks. A lot of
> people have participated in this thread, and a lot of different opinions
> were given, although most of those seem to be in favour of this future.
>
> I am still very curious to hear if the Lua developers have managed to
> form an official opinion on wether this is a feature likely to be added
> to future Lua versions ?
>  
I see nothing wrong with it, but worse comes to worse I'm sure someone
will churn out a power patch for it eventually. (We hope.) There's a
reason why we get Source access, though contrary to what the media would
have you believe developers don't release source code because they want
users to have full power, they release source code because they can then
tell you to stop whining and add it yourself (or at least that's what I
do, unless it's a really really good idea). :-p

Slightly off topic:
Would it be possible some more documentation in-code? So far the only
comments I've really found are the copyright notices and a bunch of
artistically placed notes-to-self-this-is-what-I-did with some
semi-cryptic (totally cryptic in worse cases, and not at all in best,
but there are few best cases) one or two liners. Would it be possible to
add some more explanations for those less enlightened such as myself?
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Shmuel Zeigerman
In reply to this post by steve donovan
steve donovan wrote:
> On Wed, Jun 10, 2009 at 12:02 PM, Olivier Hamel<[hidden email]> wrote:
[...]
>> * C Std Lib: More powerful support for format/additional functions like
>> string split/explode (Only if there is enough interest? Is anyone interested
>> in that anyways?)
>
> They're very useful, but pure Lua implementations are usually fast enough.

Once lrexlib had rex.gsub implemented in Lua (with internal
concatenation of string pieces via table.concat). Reimplementing
rex.gsub in C made it about 20 times faster.

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

Re: Next Version of Lua? (again, \x## notation)

Patrick Donnelly
In reply to this post by Olivier Hamel
Hi Olivier,

On Wed, Jun 10, 2009 at 5:24 AM, Olivier Hamel<[hidden email]> wrote:
> Slightly off topic:
> Would it be possible some more documentation in-code? So far the only
> comments I've really found are the copyright notices and a bunch of
> artistically placed notes-to-self-this-is-what-I-did with some semi-cryptic
> (totally cryptic in worse cases, and not at all in best, but there are few
> best cases) one or two liners. Would it be possible to add some more
> explanations for those less enlightened such as myself?

Here is a start: http://lua-users.org/wiki/LuaSource

--
-Patrick Donnelly

"Let all men know thee, but no man know thee thoroughly: Men freely
ford that see the shallows."

- Benjamin Franklin
1234 ... 8