lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 9/1/05, Rici Lake <> wrote:
> Let's trust the implementers to worry about
> the low-level stuff, and get it right. We can just think about the
> semantics, and how to write beautiful programs with that.

Agreeing wholeheartedly, may I pick a nit?  Aren't there some
high-level semantics that can be derailed when the programmer has no
option but to work too close to the details?  A simple example is
testing for an empty table.

The application of testing for an empty table is very common -- an
empty table conveys an empty set, or a null return value, or an
exhausted collection, etc.  But in Lua a higher level thinker has to
resort to lower-level constructs to make this test.  I can use the
next() function or, where applicable, I can use the table.getn()
function.  But is the next() function "faster", or is getn() "better"?
 Of course making that choice shouldn't concern me; those are
implementation details from the view of testing for table emptiness.

To get my head out of these low-level details I need a level of
interaction with the language that provides this decoupling.  Wouldn't
something like table.isempty() do the trick of decoupling my
higher-level thinking from the implementation details?  With such an
interface between higher-level semantics and lower-level details I can
safely assume that table.isempty() is the "best" implementation for
its purpose and I can confidently leave the details to the

Just rambling,