From: Austin Ziegler <austin@...>
Date: 2002-11-03T14:56:27+09:00
Subject: Re: Thoughts on Ruby

On Sun, 3 Nov 2002 10:57:29 +0900, Enric Lafont wrote:
> Why does common operators like "=" , "and", " .." , "or" etc ...
> can not be overloaded or redefined ?, maybe the complexity of the
> Ruby parser comes from the fact that everything is ALMOST an
> object or a method.

I don't actually see this (that everything is "almost" an object).
Personally, I think that matz has made the right choice in making
boolean operations (and, &&, or, ||) invariant in the language. You
can, by the way, redefine the bit operators (& and |). There's
nothing worse than a language which doesn't do what you expect it to
do with conditionals, and it does so on the whim of another
programmer.

> Why is not "=" a method?

Because it's not something done to objects, but to reference
variables that we use to manipulate objects. I'm really curious as
to why one would want to redefine assignment in the first place. I
mean, seriously. It's not like this is C++ where you have to
reinvent everything every time you work with the bloody language.

> Same question for "and" and the rest of operators that can not be
> redefined, Does the actual implementation make life easier for the
> designer ? I say so because for me is more natural when everything
> is an object (without exceptions, here Ruby follows the rule
> pretty well) and a method is a method ever, not sometimes.

This is just MNSHO, but again I don't see why one would want to
allow such basic constructs to be redefined. IMO, you can redefine
everything except boolean tests and still have a useful -- if obtuse
-- language; if you try to redefine those, you're not going to be
able to have any determinacy with the programs that are written.

> Some methods are keywords, and some other are not v.g. loop vs.
> while. The every call is a method could simplify greatly the
> sintax parser (look at the Smalltalk parser).

while is a boolean test as much as a loop construct.

> Why primitives are hidden ? In smalltalk you can call a primitive
> every time you want with a <primitive: aNumber> , this way the
> implementation of native methods, and in some way native Classes
> like String are not hidden from the programmer, freeing the
> programmer to change the behaviour if needed.

Why is it necessary to access the primitives? IMO, Java's biggest
problem is that it makes the primitives available. In Ruby, by the
way, I can still change the behaviour of String -- this is where
Ruby differs from every other language that I've ever used: it's
dynamic. If I need a new function on String, I can add it whenever I
need. I'm looking at extending the functionality of a library that
I've ported so that it can optionally extend String and Array to
include this library as methods on String and Array instead of as
something else to operate on a String or an Array.

> Yes you can have the "required" clause and use binary libraries,
> but would not be much more "natural" to have a "require string"
> when you want to invoque string libraries instead of having them
> loaded all the time ?. I want to say here that the "primitive"
> keyword frees the language from it's implementation. This favours
> the everything is a module aproach.

I disagree -- allowing access to the primitives ties the developer
very tightly to the local implemententation of the language. I don't
particularly care whether or not my integers are 32-bit or 64-bit or
even larger -- I just expect them to do what they should do (and
that means possibly upclassing to a BigNum class if I exceed the
word size). I think that the only thing that I'd like to see in this
regard is for Ruby to take a page from Ada and allow me to define
ranges as types (that is, I want to be able to automatically define
a class UInt64 < Integer [(-2**64) .. (2**64 - 1)] and have it do
the Right Thing).

It would NOT be much more natural to require every bloody module I
need every time I need it. A language -- especially a language like
Ruby, where Strings are fundamental to everything -- isn't useful
without certain defaults. Would it not make equal sense to "require
integer" when I need to use integers, or are you suggesting that
those are fundamentals and are always included? Strings are part of
what makes Ruby useful immediately (the same applies to Files)
because it's a scrpiting language.

> Sintax Sugar (SS), other thing difficult to understand for me, the
> question here is why ? Everything has exceptions very few things
> are orthogonal with the principe that must drive it, you can wite
> a.+(3) or a + 3 or a.+ 3 or a hundred other ways to write the same
> thing, yes, this gives you freedom, but a bad deserved (not
> needed) one. I use one form, but when I read programs from other
> persons the code seems strange and somewhat dificult to read.

I'm sorry, but I don't understand what you're getting at here. The
three examples you gave:

  a.+(3)
  a.+ 3
  a + 3

are actually the only ways to express that thought (without getting
silly wrt parenthesis). Ruby explicitly makes parentheses optional
on method calls. Parentheses make complex operations easier to read,
certainly, and can prevent confusion for the interpreter and
programmer, as when you have:

  a b, c d
    // Is this a(b, c(d)) -- OR
    //         a(b), c(d)

This means only that "a + 3" is syntactic sugar for "a.+(3)" because
it is fundamentally more natural for most people to write "a + 3"
than either "a.+(3)" or even RPN "a 3 +". Again, matz has made the
proper choice -- it keeps the language easily accessible.

> Sometimes SS is right, v.g. x +=1, but the every call is a method
> aproach could give you the same results without trouble, in this
> case += could be a method. As could be "++" or others.

Actually, it can't give you the same results without trouble. C++
*is* trouble because it allows the definition of:

  a = a + b     // a.=(a.+(b))

to be different from:

  a += b        // a.+=(b)

If the result of the first call isn't the same as the result of the
second call, then there's a disconnect which has to be documented.
Matz made the right choice here, I think, because it prevents this
sort of stupidity that C++ allows. (And this isn't 'prevention' in
the way that I think GvR was beyond silly to require indentation for
block definition in Python.)

> Undeclared variables, I don't know other people but I do fast
> typing and writing "aVariable" and "aVariabel" is a mistake that I
> can do very easily. Yes you can say, type more slowly, but this is
> not a solution, I would like to have a way to force the compiler
> to generate a warning when I use a non pre-declared (or pre
> asigned) variable.

The interpreter will warn you of this, to some degree. If I try to
use an undefined variable, it will complain (at least with 1.7)
because the value is unknown (it's not even properly 'nil'). This
won't help, however, if you have two similarly named variables.

> Why are Strings arrays of integers ? aString[0] is an integer,
> yes, it's the way it is, but I would like to have String as an
> array of chars, and char if you want as a descendant of Integer
> (nice election because a Unicode String is and array of double
> chars i.e. integer), I don't know you, but for me aString[i].chr
> =='x' is somewhat unnatural, because it breaks the semantic of a
> String, so it's not intuitive for me.

This one is easy: because it was a design decision made earlier. A
new version of String is being worked on, to the best of my
knowledge, that will deal with characters -- but this leaves the
problem of existing code which will break because it uses the
current implementation.

> Why is Ruby an interpreter ? Yes the less traditional bytecode
> aproach, can be harder (or not), but enables external
> optimizations more easily (JIT and similars) because the language
> are separated from the implementation, enables reduced footprint
> and gives faster execution times, yes, look at how Self executes
> programs, it's amazingly fast (and incredibly complex also), but a
> separated implementation could help develop better Ruby-engines.

A bytecode system is being worked on, to the best of my knowledge.

-austin
-- Austin Ziegler, austin@halostatue.ca on 2002.11.03 at 00.12.35