Re: Allowing custom number literal suffixes?

Mathieu Bouchard wrote:

> On Tue, 4 Jan 2005, Florian Growrote:
> 
>>Mathieu Bouchard wrote:
>>
>>>Hahaha, so you prefer to pollute the Ruby grammar instead?
>>
>>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.
> 
> methods of Kernel sometimes enter in conflict with other things, and it
> doesn't depend on whether they're single-letter or not. The only two cases
> that got taken care of are #send and #id, which were given underscorish
> aliases. For the rest, everyone's on his/her own, including about the
> one-letter Kernel#p.

Using single-letter names make the chances for conflict even more 
likely. We should try to avoid conflicts. While this might not be much 
of a problem when you restrict yourself to upper-case I'm not sure if 
that's not a bit limiting.

>>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.
> 
> I think you missed my point, especially because you seem to keep believing
> that the 0.5R syntax is acceptable. Well, the reason I mentioned
> non-base-10 radixes is because, and I quote myself,
> 
>>>a better reason against the 0.5R syntax is that it can only
>>>represent rationals that have denominators that divide a power
>>>of ten.
> 
> I am pointing out an apparent [inacceptable] drawback of the 0.5R syntax;
> so I am looking for extensions to it that may alleviate the issue, such
> as:

using 1/3R where appropriate. (Which would still be parsed as 1/(3R) so 
it is *not* a special case.)

> Then Brent mentions multiletter literals. This makes just more possible
> suffixes. My above argument doesn't use the fact that there would be 26 or
> 52 possible suffixes with a single letter, therefore it is valid for any
> suffix length. (if suffixes can be parametrized instead of taken as a
> whole, then they should be called infixes or multifixes)

While it can make sense in the C++ world to have multi-character 
suffixes (like UL for unsigned longs) I think we have simpler needs.