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

[Coda Highland <chighland@...>]

On Wed, Aug 26, 2015 at 6:22 PM, Hisham <h@hisham.hm> 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
>

There's always proxy tables. >.>

/s/ Adam