[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lua-l
Subject:    Re: A few Wild and Wooly Proposals, while we're here (was Re: Feature request: userdata slice)
From:       "Soni L." <fakedme () gmail ! com>
Date:       2015-08-27 9:25:50
Message-ID: 55DED79E.6090003 () gmail ! com
[Download RAW message or body]



On 26/08/15 10:22 PM, Hisham wrote:
> 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
> 
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.


[prev in list] [next in list] [prev in thread] [next in thread]