Re: syntaxic shugar proposition : generic do block

[Mark Hamburg <mhamburg@...>]

on 12/4/06 9:54 AM, Fabien at fleutot+lua@gmail.com wrote:

>> garbage collection or some form of reference counting
> 
> AFAIK, reference counting has terrible performances... And even if closures
> tend to hurt performances, follow the no-premature-optimization path:
> - write it the way you'd like to read it if it was someone else's code
> - profile the bottlenecks
> - optimize these bottlenecks, possibly by getting rid of nice looking but
> inefficient idioms, possibly by putting these bits in C.

Storage allocation inside of inner loops is fairly well known as a
performance problem. I've seen plenty of cases where it helps to simply
allocate a single instance and use it repeatedly rather than allocating
items that need to be cleaned up later.

One benefit to the existing syntax is that writing "function() ... end"
potentially encourages one to think about the fact that storage is being
allocated. Certainly more so than "do ... end" since while loops which use
essentially the same syntax don't allocate storage.

So, either one wants to worry about how to make the common cases for storage
allocation and reclamation cheaper or one wants to make sure that allocation
is at least obvious to the programmer. Since the "do ... end" syntax works
counter to the former, it creates pressure to look for ways to do the
former.

I turn periodically to the question of how to do the former, but I don't
have specific recommendations at this time. A system that could reclaim and
recycle essentially stack scoped values, however, could be a big boon to
performance for operations involving closures (however they get created) or
table-based parameters.

One of the things I always liked about Oberon was that it provided a fairly
straightforward yet safe way to balance between garbage collection for the
complicated cases and stack allocation for the easy cases. We're unlikely to
get the direct control in Lua to support something like that -- and adding
it to the language would corrupt the simplicity of the language -- but
trying to capture at least some of the benefits of stack-based allocation
seems useful.

Mark