Re: Allowing custom number literal suffixes?

On Fri, 7 Jan 2005, Florian Growrote:
> 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.

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

Yes, that's right. This has to be replaced by either B("0.5")+x or
(B"0.5")+x or maybe x+B"0.5". So this is a case where the suffix notation
would fare better.

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

good grief.

> Mix-In is a form of adding methods to Objects that works different
> than Inheritance.

There are other programming languages that support exactly that thing and
call it inheritance/subclassing.

> They do not have some of the multiple inheritance problems like the
> diamond inheritance problem because of that.

Woh. They also have some more problems wrt the diamond inheritance
problem. The weak spots are merely moved around. What matters is where one
prefers the weak spots to be, I guess...

> I would like to see the two roles (namespaces, mix-ins) separated.

I too have the feeling that a Module has too many aspects clustered
together.

Btw, do you think it's right that foo.extend(bar) is any different from
class<<foo;extend bar end ?... and don't you have the feeling that extend
should be called something else, as well as that something else should be
called extend ? Either that or the same about include... I don't feel like
the difference (and similarities) between behaviour of "extend" and
"include" is reflected in their naming...

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

Well, frankly, I also think that it doesn't increase it too much, but
there are many things like that, that wouldn't increase complexity too
much, and once you've added only half of them, it's already too late, and
the result looks like Perl6 or something.

btw, i think this is funny (or tragic... whatever)

  http://www.ozonehouse.com/mark/blog/code/PeriodicTable.pdf
  (yes, there are _182_ operators...)

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