From: "Florian Groß" <florgro@...>
Date: 2005-01-05T03:28:23+09:00
Subject: Re: Allowing custom number literal suffixes?

Mathieu Bouchard wrote:

> On Tue, 4 Jan 2005, Florian Gro� wrote:
> 
>>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.
> 
> limiting? how so? can you elaborate on this?

I think an "i" suffix is more natural for imaginary numbers than "I", 
for example. But I have to admit that this is not all that important.

I guess my hesitancy to using regular Kernel methods is mostly based on 
other factors. While you were able to omit the parentheses in some of 
your examples rendering the syntax as  R"0.5"  which is already quite 
acceptable that will not work in general, R"0.5" + 0.5 would not work, 
for example and R("0.5") is and looks like a global method call.

I'm not feeling well about having these functions that would only be 
used for number literal like usage anyway in the Kernel where they would 
appear in line with other methods like "puts" and "caller". Don't you 
feel bad explaining to a newcomer that that R() method that is reachable 
from all Objects is something the standard library defines to allow for 
easier constructing of Rationals? I'm certain that lots of Ruby's users 
would not be willing to do that for the sake of less typing. And while I 
can not say that "number_literal_R" is immediately obvious it explains 
its purpose already way better than a single letter method name ever 
could. I think it would also be a good idea to move it to 
Numeric.literal_R just so it does not clobber up all Objects.

Peter, in case you are still listening, what do you think about that change?

I also have a hard time seeing the syntax pollution you talked about in 
on of your earlier postings. I can not quite see how this syntax would 
be used for something that could not be implemented in terms of the 
callback function. I'm not sure about complexity being raised much 
either -- after all the patch from above was fairly self contained. 
While I'm not sure if it handles all the cases it seems to integrate 
well with how parse.y already used to work so I'm optimistic that it 
would not cause trouble.

>>using 1/3R where appropriate. (Which would still be parsed as 1/(3R) so 
>>it is *not* a special case.)
> 
> OH ok, i thought that, by "rational literal" I thought you meant
> excluding that 1/(3R) trick.

I'm okay with using 1/3R etc. where it makes sense. It's still nice that 
you can do 0.5R instead of 1/2R (that makes it easier to replace 
floating point literals with Rationals). It's also quite useful for the 
BigDecimal support.

I just wonder why you seem to be against this so intensively -- is it 
the "Say no by default" mentality to avoid unnecessary language 
complexity or are there other reasons?