lua-users home
lua-l archive

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

On 26/08/15 10:22 PM, Hisham wrote:
On 26 August 2015 at 21:35, Soni L. <> wrote:

On 26/08/15 08:53 PM, Hisham wrote:
On 26 August 2015 at 16:27, Soni L. <> wrote:

On 26/08/15 04:24 PM, Dirk Laurie wrote:
2015-08-24 18:07 GMT+02:00 steve donovan <>:
On Fri, Aug 21, 2015 at 4:04 PM, Coda Highland <>
I think C++11's way of defining new literals is pretty reasonable. You
define a suffix operator (which must start with _) and when literals
appear with that suffix, it's translated at compile time (in Lua's
case, bytecode generation time) to a call to that function
But (and this is crucial) any resulting object creation is not hoisted
out. For instance, in languages with regexp literals /.../, the
literal is replaced with a reference to a compiled regexp object.
They effectively become constants.  If I see a 'date literal' like
D'2015-08-24' in Lua I know that this string will be parsed _each
time_ - it isn't really a literal.

Code generation for true custom literals would get pretty involved.  I
don't think the prettiness is worth the bother.
Not at all, assuming that Roberto's suggestion of per-value
metatables gets implemented. A user-defined literal would
be implemented as a string with a metatable. It could work
this way:
I'd rather have multiple levels of metatables.

Value level
Scope level
Function level
Module level
Global level

Including for tables so that you can t = {} t:insert(v) and it just
...until you do something like

     users[name] = data

where name happens to be "insert"...

-- Hisham

Don't you have that caveat with the current metatable system, anyway?
No because the global `table` table is not used as the metatable for
tables, so usage such as t:insert(v) is not promoted. With the current
system you'd have to explicitly shoot yourself in the foot to get
that; with your proposal, you get a shorthand syntax like that of
strings that works for tables... except for tables used as maps with
arbitrary string keys (an amazingly common use case). So, while I'd
love to be able to write t:insert(v), I know I can't really have that
as long as it clashes with t["insert"] = v.

-- Hisham

Isn't that the same as saying "The caveat isn't there unless you explicitly enable it"?

Because I never talked about setting the global table metatable to `table` by default.

The only difference is that you'd enable it at the start of the module and it'd be available for all tables used within that module, instead of having to manually add it to every single table (and have the metatable leak to the outside of the module).

Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.