Re: A few Wild and Wooly Proposals, while we're here (was Re: Feature request: userdata slice)

[Hisham <h@...>]

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