Hal E. Fulton wrote:

>>I would like to know...
>>
>>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. Why is not "=" a method ?
>>    
>>
>
>Here is one way to look at it. A variable is essentially a reference
>to an object. A method is invoked on an object. An object never 
>changes class (perhaps it can in Smalltalk?).
>
>If I say:  x = "hello"
>then what is the receiver for the method call "="? You can't say it's
>x, because x is not an object.
>
>On the other hand, the number 5 is an object. If I say:  5 = "hello"
>does that mean that every reference to the number 4 is now a reference
>to the string "hello"?
>  
>
In Smalltalk is the same as in Ruby, a variable is a reference, a 
variable can change the object it references, but the object never 
changes (morphs), there are one exception, when an object morphs, it's 
destroyed and changed by a new one pointed by the same reference.

>> 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. 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).
>>    
>>
>
>I can't speak for Matz, but I have NEVER seen him make a design decision
>because it made life easier for the designer rather than the programmer.
>
>I have seen him make compromises for clarity or efficiency, however. I
>suspect that these fall into these categories somewhere.
>
>As for simplifying the parser: I think you will agree it is better to 
>have a readable, usable language than a simple parser.
>
>Sometimes languages that are very powerful have difficult syntax (LISP,
>Smalltalk, etc.). LISP is arguably the most powerful language in the
>world, but people find it difficult to learn and use. Ruby is full of
>compromises in its design.
>  
>
I don't know a lot of Lisp, but everything I can do in Lisp I can do in 
Smalltalk also and is much more readable.

I think that the parser is dificult because you just need to look at how 
the language are defined, a pseudo-BNC notation, this is the think that 
makes me thing that the language has a complicated parser.

>>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. 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'm not sure about everything you're asking here. But you can in fact
>change the behavior of the standard classes, since the classes are "open."
>There are many examples of this in TRW.
>  
>
Yes, you can redefine any method, the alias directive helps here but I 
would like to have a String.rb file instead of a String.c like I have a 
Matrix.rb.

>>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. 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.
>>    
>>
>
>In Ruby, a += b means a = a + b ALWAYS, without fail. This means that you
>get += "for free" when you define +, and you are spared having to write
>both. If you want += to have some other meaning, I would have to ask "Why?"
>It seems logical to me to tie the meaning of += to + (unlike C++).
>  
>
OK, if you have a
def += (anArgument)
  return (self + anArgument)
end

You will have exactly the same behaviour you have know, whitout any trick

>As for ++ and --, these are impossible in Ruby for much the same reason
>I mentioned before. They are operations on variables, whereas Ruby methods
>and operators work on objects. If I say:  x++  I am trying to increment
>the OBJECT that x refers to. Does this mean that every variable with the
>same value should be changed also? For that matter, what should 5++ mean?
>  
>
Equally, you could define a

def Object::++(anArgument)   # Yes, the sintaxis is bad, I try to 
explain my point of view
  return anArgument + 1
end

AND

def Integer::++
  return self + 1
end

And you have NOW for free a pre-increment and a post increment.
This tries to explain the POWER of the every call is a method

>>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.
>>    
>>
>
>If you use it on the right hand side, it will be an error.
>
>It was difficult for me to get used to a language without variable 
>declarations. But it seems to be a thing which Matz always insists on.
>And I got used to it, and now I like it.
>  
>
it will be an error because some method will fail, but and undefined 
variable is nil, so it's a valid object. This is something that IMHO is 
an error.

>>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 was never intuitive for me either.
>  
>
Thanks, at least I'm not the only one

>>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.
>>    
>>
>
>This is planned. Matz wants to add bytecodes to 2.0 I think (which is 
>still vaporware). In addition, Parrot is being designed not just with 
>Perl in mind but Python and Ruby as well. So it should be possible to 
>write a Parrotized version as well (though it has not been done yet).
>
>There is also JRuby, which strives for interoperation with Java. I have
>not played with it yet.
>  
>

I've taked a look at parrot, and it seems to be an interesting project,

>>Don't get me wrong, I understand that Ruby is a young language that 
>>needs some maturing, and I love how easy is to learn, it's dinamicity 
>>and the fact that is a kind of mix between my loved Smalltalk, Self and 
>>other languages. In fact I'm writing this because I want to understand 
>>Ruby better and becasue I want to make some suggestions for future 
>>releases, maybe Mr. Matsumoto would like to consider some of them
>>    
>>
>
>My advice is to wait 90 days before suggesting language changes. :)
>Every newbie makes these suggestions (as I guess I did too). But most
>of them have been thought of before (as a search of the list archives
>will show). Some are under consideration, some are planned for the
>future, and some have been rejected by Matz.
>  
>
My comments appeared, becasue Ruby is really very similar to Smalltalk, 
just the small diferences makes Ruby less powerfull that it can be.

Just as an example, the closures are not objects, yes you can 
"objectify" a closure, but closures seems to be a patch to the language 
instead of an extension of it.

>>There are more things that I see as strange in Ruby, but this is enought 
>>for now .....
>>
>>Please if I've make any inaccuracy , don't be too rude with me, I'm 
>>still learning, and I've a loooong way before understand everyting. I'm 
>>just looking for answers.
>>    
>>
>
>I hope no one here is rude to you. If someone is, we will
>come to your defense... :)
>  
>
Thanks, if someone bothers me, I will tell you , so you can defend me 
.,.,.. :-)

Enric