[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua 5.2 custom array demo
- From: Mark Hamburg <mark@...>
- Date: Sat, 9 Jan 2010 09:53:55 -0800
On Jan 9, 2010, at 9:37 AM, David Kastrup wrote:
> steve donovan <firstname.lastname@example.org> writes:
>> On Sat, Jan 9, 2010 at 6:27 PM, David Manura <email@example.com> wrote:
>>> where "::" is basically like a "function()" but allows omitting
>>> parenthesis in the call.
>> Such a bit of sugar would also be useful with pcall.
>> Actually, there's no reason to use rawget/rawset, instead just:
>> function s.__newindex(t,i,val) t.store[i] = val end
>> and so forth. Then t.store could be userdata.
>> Now, it would be cool if table.concat was intelligent enough to
>> understand such proxy arrays (i.e. use the overloadable ipairs, and
>> use tostring where applicable) without much performance cost.
> The art of getting a computer language off the ground, with all due
> respect to Douglas Adams, should not be hurling it towards C++ and
> The increasing "wouldn't it be cool if we could write one thing and let
> it mean something almost, but not quite, entirely unlike what it looks
> like" chants start worrying me. Should every sufficiently advanced
> computer language be doomed to have its programs become
> indistinguishable from magic?
I appreciate the desire to avoid magic and C++. On the other hand, I think there are reasonable questions about what the core mechanisms and abstractions are in Lua and whether they are consistently and fully exploited.
So, for example, "use proxy tables" is a fairly common refrain when asking how to do things in Lua, but then we look at various pieces of the standard library and find that they don't actually work that well with proxy tables. __pairs and __ipairs are a step in the right direction, but table.insert still uses raw access and hence won't work with proxies (and will barf on userdata based proxies).