Re: Allowing custom number literal suffixes?

Mathieu Bouchard wrote:

>>I think an "i" suffix is more natural for imaginary numbers than "I", 
>>for example.
> 
> Mathematica uses uppercase I for imaginary [snip]
>>But I have to admit that this is not all that important.
> 
> But it's important to realise that it's not important, which is why I take
> the time to write about it! :-)

So maybe it is hard to come up with a case where Syntax would be 
important -- as long as something can be expressed at all it is not much 
of a difference of how it is done. Except for convenience, I think.

>>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.
> 
> Using my example's notation it would be Q(1,2), where Q is exactly just an
> alias for Rational, and so it accepts only a pair of Integers, and not a
> stringified float, for two reasons:
> 
>   Using double-quotes is useless and cumbersome for cases where
>   the unquoted syntax is already valid (such as writing 1, writing 2,
>   and writing 0.5)
> 
>   Using float syntax for rationals is ugly and borders on nonsense...
>   (and i repeat myself)

As previously said: I think it can make sense when you are replacing 
floating point literals with Rationals.

> So the example R"0.5" + 0.5 is not appropriate. Please find another
> example instead...

That's right. Maybe  x = B"0.3"; B"0.5" + x  would have been a better 
one. (B being BigDecimal)

>>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".
> 
> Well, then, define them in another module and include that module
> whereever you need it!!! You know, if my solutions look bad to you, but
> have obvious fixes, you don't need to concentrate on my bad solutions, you
> can improve my solutions and make them your own!

Hm, I think the problem is that I'm trying to find a solution that is 
both convenient and that would not cause name conflicts with existing 
code. Having to include a separate module per method whenever I use them 
would not work for me.

>>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?
> 
> No, because by then, I would have made it clear that I do not endorse all
> of Ruby's features, and that I use Ruby for its advantages, not its
> inconvenients. If I wanted a programming language that is free of
> inconvenients or embarrassments, I would not use Ruby.

But why should I ask the standard library developers to add support for 
features which I myself find inconvenient and embarrassing?

> I wouldn't feel bad explaining R() to a newcomer. I would downplay the
> importance of that fact, because I think it would be a fact that deserves
> to be downplayed. However the two things I have terrible trouble
> explaining to newcomers and/or outsiders, are:
> 
>   a Module is the same as a Class, except when it's not.
>   Multiple inheritance is not called multiple, and several
>   words are used just to avoid saying "inherit from".

A module is a collection of methods. It can be used as a namespace by 
using module_functions or as a Mix-In via include and extend. Mix-In is 
a form of adding methods to Objects that works different than 
Inheritance. They do not have some of the multiple inheritance problems 
like the diamond inheritance problem because of that.

I would like to see the two roles (namespaces, mix-ins) separated. It is 
inconvenient to use module_function or extend(self) for doing 
namespaces. Maybe this will be added along with selector namespaces, I'm 
not sure.

>   there are things (blocks) that are 100% like Procs except
>   they are not objects (blocks). The & argument of a method is magical
>   and can only contain either a proc or nil. You can only have one
>   block in a call, so that if you want more, you have to use procs
>   instead, with a different syntax.

This is an interesting problem. I wonder how it would work out to make 
x = { puts "Hello" }  a valid syntax. Going the other way (replacing all 
blocks with lambdas) would loose some of the ease with that blocks can 
be used in Ruby IMHO.

>>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.
> 
> That's because you inserted the comment inside the method name. I won't be
> fooled by this one. What you want to do is use the parser so that you can
> have a long, descriptive method-name in the def but a short one (the
> suffix) when making a call.

Exactly.

>>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.
> 
> You mean "clutter" and not "clobber".

Ah, you are right of course.

>>I also have a hard time seeing the syntax pollution you talked about
>>in on of your earlier postings.
> 
> [...]
> 
>>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?
> 
> Well, yeah, it's just that i'd rather not add any more rules to Ruby's
> syntax, as it's already quite complex as it is, especially if there are
> already good enough solutions elsewhere. Of course, solutions good enough
> for me are not necessarily so for other people. :-/

Yup, I guess it depends a lot on personal opinions. And while I seem to 
have a different one than you in some points I still think that you have 
a point. And it is good to get feedback on this.

My opinion is that while it is not necessary to add a new syntax to this 
it would still be nicer to use 1/2R or 0.5B than Rational(1,2), 
BigDecimal("0.5") or the one-character short forms. I see the problem of 
too much complexity, but think that this does not increase it too much.