On 26 August 2015 at 21:35, Soni L. <fakedme@gmail.com> wrote:
On 26/08/15 08:53 PM, Hisham wrote:
On 26 August 2015 at 16:27, Soni L. <fakedme@gmail.com> wrote:
On 26/08/15 04:24 PM, Dirk Laurie wrote:
2015-08-24 18:07 GMT+02:00 steve donovan <steve.j.donovan@gmail.com>:
On Fri, Aug 21, 2015 at 4:04 PM, Coda Highland <chighland@gmail.com>
wrote:
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
works.
...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
