Brent Roman wrote:

>> But if it's already so hard to find support for the relatively simple 
>> and straight-forward patch from earlier, how are you going to get 
>> support for this? Note that I'm not entirely against this, but I think 
>> \3/2\r is a bit too complex for the simple number literal cases.
>>
>> Somehow I have the feeling that what you want to do could be 
>> accomplished with String suffixes. (Though I do not need this.)
>>
> By "String suffixes" I assume you mean numeric literal suffixes 
> implemented in Peter's patch.  Correct?

Incorrect, I was referring to something like "foobar"Q which could work 
similar to Peter's Patch. But as noted above: I'm happy with Number 
suffixes and would like to see those implemented; I'm neutral about 
this, however.

> I'd prefer to see a general mechanism incorporated rather than a patch
> for constrained cases.  My clunky \3/2\r could be streamlined by making
> this simple numeric case a special shortcut that does not require the
> delimiters.  [Much as simple arguments to outer method calls can omit
> parentheses.]  Seeing a token that begins with a digit, the lexer would
> continue until the next character that is not a \.|digit|alpha.  So,
> 
>   3/2r+2  would be syntactically equivalent to  3/\2\r+2
> 
> both evaluate as:
> 
>     3 / Kernel::Literal::Suffix.r('2') + 2

This seems to be compatible with the patch from Peter. While I dislike 
the \...\ syntax I would not need to use this. So if matz and the 
community are okay with this I'm not going to complain.

> I'm not concerned about the details of how a user defined literal 
> facility is implemented.  Just so long as it does not increase the size 
> of the core significantly and it allows arbitrary strings to function as 
> Object literals.  The above was just an example to show what I was after.
> 
> Am I the only one interested in such a facility?

I don't need the arbitrary character part, but I guess my goals are 
mostly a subset of yours.

It seems I have a hard time finding support for Numeric literals because 
most people are not using the Number classes of the standard library. 
But having a simpler way of using them would lead to them being used 
more frequently, I think. It seems to be sort of a circular problem...