Re: Allowing custom number literal suffixes?

I'm not sure I would advocate making Ruby's grammar even more
byzantine (e.g. where, exactly, are parenthesis required vs. optional?)
but, "wenn schon, denn schon":

The "number_literal_r" is too restrictive.  Even lowly 'C' has
constants like "100ul" and "100bL"  The last character
is not all that is needed to determine a constant's type.

Why not add something more similar to obj.method_missing for 
unrecognized numeric literals?  If a token begins with a digit and 
cannot be parsed into a number, Ruby calls

   Kernel.unrecognized_numeric_literal (tokenString)

if it is defined, otherwise raises a parse error as before.

A common Ruby library should define an base unrecognized_numeric_literal
method that manages multiple hooks similar to the way that at_exit does.
This would let each class that wishes to parse a strange new numeric
literal register a method do so without stomping on others. If the hook 
method returns nil, the class does not understand the literal. Anything 
else is interpreted to mean that the hook parsed the literal into the 
object returned. It may be a good idea to call all the hooks even after 
one of them returns non-nil so that one can detect an ambiguous numeric 
literal string.

This approach keeps most of the idiosyncratic logic in Ruby scripts
and adds only one simple method to the Kernel module.

I don't think it corrupts the grammar.  We're
not changing the lexical rules Ruby currently uses to
parse numeric literals.  As a consequence, _really_ useful
literals like:

   4:30:19AM  or  122.45'23"N

will never work. Well, maybe one could allow:

   4.30.19A

but that isn't very friendly to folks in North America.
(and, I don't think the repeated '.' would be accepted anyway)

- brent



> Mathieu Bouchard wrote:
> 
>> On Tue, 4 Jan 2005, Florian Growrote:
>>
>>> While this is a nice idea I don't feel sure about polluting the global method space with one-character names.
>>
>>
>> Hahaha, so you prefer to pollute the Ruby grammar instead?
>>
>> What's that aversion for the global namespace, that is so great that
>> instead it is preferred to instead add things to the _grammar_ ???
> 
> 
> I prefer not having global methods with one-character names as those might already be used for something else. Just think about 'p' or the common variable names 'i', 'j', 'x', 'y' and so on.
> 
> The collision chance with something like 'number_literal_r' is way lower and that particular grammar was until now invalid meaning it will not cause incompatibilities either. If you think the decision to add this is to arbitrary please note that the feature is also present in other languages meaning it would already be familiar to users who are already used these kind of suffixes in Java, C#, C++ or Python.
> 
>>> And I think it would not cause many problems to make an yet unused
>>> syntax do something meaningful.
>>
>> The syntax of Ruby is already complicated enough, imho, but a better
>> reason against the 0.5R syntax is that it can only represent rationals
>> that have denominators that divide a power of ten. If you allow the use of
>> 0,0b,0x prefixes it doesn't change because those notations allow even less
>> denominators (only powers of two). However I recall some languages use a
>> notation like 2r3 to mean specifically Q(2,3), while 2/3 means something
>> else (usually the float 0.666... or the 0 integer).
> 
> 
> Actually I'm hesitant to add the suffixes for non-base-10 radixes as that would complicate all this quite a lot -- it would be hard to specify a suffix for hex literals, for example. I hope that is not too much of a limit for you.
> 
>> While we're at it, why not adding such syntax:
>>
>>  * while Complex===3i with a lowercase i, the uppercase I,J,K suffixes
>>    would be of class Quaternion.
>>
>>  * 7m9 would be a literal meaning the set of all 9*m+7 numbers,
>>    which is an object of class ModuloInteger.
>>
>> (just kidding!)
> 
> 
> Please note that I am not proposing hard-coding these literals. I have suggested to use callbacks instead as the R => Rational association does not belong into the core language. It belongs into the Rational library.
>