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.

Also, the only cases of capitalized methodnames are
converters/constructors: Array(), Float(), Integer(), String(),
Rational(), Complex(). I also see a DelegatorClass(), and I dunno what it
is, but it's IRB-only anyway.

Conflict with capitalized method-names are nearly impossible due to two
things:

  1. the above four all have at least one arg, which syntactically
     disambiguates from constants and localvars.

  2. the convention above, contrasted with the almost-ubiquitous
     convention that methods are named_like_this and NotLikeThis.
     almost all dissidents doItLikeThis, with leading lowercase.

Therefore I can only agree with your opinion if you send me a registered
cheque with enough digits on it.

Next,

> 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:

> > 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).

So I have found that this is not a good solution either. Furthermore,
something I haven't said (but thought) is that allowing all bases from 2
to 36 (pretending any chars were left as suffixes...) doesn't even give
you a shorthand for Rational(1,37) !!! This is what I am talking
about. Therefore:

	Allowing a single letter suffix is never sufficient to allow
	rational literals in the general 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)

My conclusion is that if you want to support rational literals you will
have to upgrade your plan to include letter _infixes_ such as 1r3 for
one-third, and although 0.123R is shorter than 123r1000, your R suffix
only applies to special cases that are rare.

_____________________________________________________________________
Mathieu Bouchard -=- MontrñÂl QC Canada -=- http://artengine.ca/matju