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

[Coda Highland <chighland@...>]

On Fri, Aug 21, 2015 at 12:10 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>> 2) Allow a method to create new literals.  Here me out.  If we do this, and
>> set up some way of writing code to understand literals, then we can pull
>> strings out of the core and into an actual module.  Really, the only
>> difference between a string and a userdata is that there's support for
>> string literals in core.
>
> +0.5 to this one, i.e +1 for this half of it only. It can be implemented
> in a less revolutionary way than suggested in the other half.
>
> Use sharp brackets as delimiters for a string that will be
> tested in order against already-defined patterns until one
> matches, creating a table with a metatable which has been
> associated with that pattern.
>
> new_literal("(%d+)%-(%d+)%-(%d+)",ymd_meta)
> date = <2015-08-21>
> date.year --> 2015
> new_literal("(%d+)%:(%d+)%:(%d+)",time_meta)
> -- you get the drift

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 receiving
the literal as a string, long int, or double (depending on how you
defined it). You could therefore, if you wanted, have "2015/08/01"_ymd
be syntactic sugar for Date(2015, 08, 01).

But the thing is, if THAT'S what you want, Lua already has it!

ymd_"2015/08/01" is, by Lua's standard parsing rules, equivalent to
ymd_("2015/08/01").

Therefore -1 from me to user-defined literals in Lua. The ONLY benefit
to it is pulling strings out of core, and I don't see that as being a
significant benefit.

/s/ Adam