> Can you give an example in a database context where Lua is more
> expression than JavaScript?

I'll try to make-up some real-life examples on a next post.

> I care a great deal less about extensibility than I do about actual
> built-in features.

What's the difference *how* you achieve those features? Extensibility
is just a *means* to achieve what you want. I think you're missing the
point. There's no difference on how a feature gets into the language,
whether it is built-in or coded-in. And that is only true for
extensible languages. Hope I'm not repeating myself too loud here.

> Not necessarily. There is nothing in my list of requirements that
> dictates a dynamic language. In fact, I'd go so far as to say that

the

> efficiency requirements argue against a dynamic language.
>
> The advantage of a dynamic language is that the "compilation" (or

lack

> thereof) is cheap, though you pay for it at execution. Java, for
> example, is more efficient that JavaScript, is cheap to instantiate,

has

> no issues with threads, etc. The cost of compilation, hassles with
> class files, and strong typing make it much less attractive.
>

I think you should set this straight and reach a conclusion about
this. IMO there's absolutely nothing to worry speed-wise about a
dynamic language.

Sure if you are *that* pretentious (which I think you're not), a
"hello world" in Lua takes ~3ms on my PC. Good luck getting there with
any Javascript implementation. So again, with Lua at least,
instantiation time is close to none. Besides, sql calls will be far
more expensive than anything else.

> Traditional database languages are cheaper to instantiate than Java,

but

> lack complex data structures necessary to return complex results.

What are those complex data structures you're keep talking about?
Isn't the table enough? I mean, if everything is a first-class object
and can be stored in any cell of that table, that is.

> As a ResultSet with a method "next" to fetch the next row returning
> whether or not there was one, and a property for each column in the
> select list:
>
> var results = connection.execute("select first_name, last_name

from

> people where town=?", "Manchester");
>
> while (results.next())
> doSomething(results.first_name, results.last_name);
>
> delete results;
>
> Simple enough?

Simple enough to be a dead end (i.e. can only be used imperatively).
What manipulation functions could possibly be built upon a cursor
without iterating the whole set every time? You worry about dynamic
languages being slow accessing object attributes, but the programmer
must iterate result sets to do *anything*.

Here's how I see it: The result set should be fully-stored into one
single data structure so you can use the *fast* and *memory-
conservative* built-in manipulation functions on that result set. For
this you would need such a data structure (which AFAIK javascript
doesn't have) and the built-in functions to give it life.

That's what I meant with impedance matching between relational and Lua
tables. Sure if you want to implement rowsets as cursors, then they
are equivalent (heck even simple arrays are enough), but is not what I
was having in mind. I want to sort, sum, use co-routines, etc. on
rowsets. With a cursor I'm stuck to the old C/Delphi way of doing
things.