Re: about the new version

[Edgar Toernig <froese@...>]

Luiz Henrique de Figueiredo wrote:
> 
> >From: Edgar Toernig <froese@gmx.de>
> >
> >But to have two different kind of "repeat" statements makes it harder.
> 
> You have a point.
> However, "while 1 do" is not easy to optimize away, for technical reasons.
> We replaced an optimization of "repeat ... until 1" with "repeat .. end"
> because it made the code generation simpler.

You've got a really bad peephole optimizer if it can't reduce the
"while 1 do" ;)


> >My suggestion: "break [<level>]"  where <level> is a number > 0 with
> >a default of 1.
> 
> This makes it very error prone to put a new loop around an existing loop,
> because you have to correct all levels.

Breaking multiple levels isn't anything you do very often.  Normally only
in some more or less complicated algorithms.  And adding an intermediate
loop to an algorithm (the only way to have the break levels change) is
_very_ unlikely.  (I'm still thinking for an example where this may happen).

Reading your answer again, maybe you misunderstood me.  Just to be clear:
A "break 1" will not leave the topmost loop but the innermost one.  A 
"break 2" the two innermost, ...

A "break [<label>]" sounds more like a "goto" in disguise ;).


> >Bad examples ;)  What you really want is:
> >
> >  local line
> >  while line = read() do
> 
> Ooo, let's not get into that :-)

;-(  But the two examples were crying for that answer ;)
And it seems, I'm not the only person who addresses this.

> >How about something else?  Have an additional flag beside "marked", say
> >"destroyed".
> 
> We discussed this alternative and decided againt it because it would double
> the memory requirements of large programs (which are the ones that use GC),
> as you mentioned.

You could collect objects without GC methods immediately...


> >Maybe I've missed something but IMO this sounds much better then just removing
> >the whole stuff *g*
> 
> The move was towards more safety of Lua programs.

Yeah, castration is pretty safe *g*

> Programs that need fine control of memory allocation should then write these
> critical routines in C,

It's not about fine control of memory allocation but about destructors for
structures created within Lua.


> >Wow, that's encouraging :)  So here's another wish: Upvalues should be
> >allowed as l-values (ie %foo = %foo + 1).  That way you have "static locals"
> >for each instance of a function.  Afaics it shouldn't be that hard to
> >implement... (I'll try if the code comes out.)
> 
> This will not happen :-)
> Upvalues are for writing closures (mostly). Functions that use upvalues may be
> called after the "enclosing" function has already finished, and so the locals
> are not longer alive.

Maybe I worded it wrong.  I don't want to change the local of the upper function
but the upvalue itself (in Closure.consts[]).  See my other posting for an
example.

> You can simulate this by using tables as upvalues and modifying fields in
> the tables. The table itself is constant, but its fields are writable.

That's what I do.

> >I would even drop the requirement for the '%'.  It makes the code ugly *g*
> >(look at Perl!)
> 
> Matter of taste, really. I think that '%' marks the place of "constant" values
> and so is useful.

I never though of upvalues as constants but a special syntax to access outer
locals.  Seeing them as constants makes the '%' more reasonable.



Something else:  I realize - and accept - that backward compatibility is your
main design criteria.  I'm just wondering what you would change/do different
if you could do to the language what you want.  Lua is a fine language but I
guess that even you sometime wish that you could break compatibility.


Ciao, ET.