From: Markus <markus@...>
Date: 2004-10-10T02:16:39+09:00
Subject: Re: ANN: Free-form-operators patch

On Sat, 2004-10-09 at 07:20, David A. Black wrote:
> Just so Hal doesn't feel all alone, I'll put in a note of skepticism
> :-)  I'm not eager for Ruby to have, in essence, no fixed syntax.  I
> think Ruby's strength lies largely in its specificity as a language --
> a language that is good at domain-specific things, but still a
> particular language -- and if it were turned into a kind of
> proto-language, I would feel a sense of loss.  Also, I don't want to
> have to learn new syntactic rules every time I want to read a program
> or use a library.  

     I think you are grossly misunderstanding what the patch does.  It
does not make ruby's syntax more complicated or more variable; in fact,
part of the goal (see the thread about a month back on Hash,
Association, & the => construct) is to make the syntax simpler and more
consistent.

     At present, if you see a concatenation of operator-characters you
have to wonder: is that an operator?  Is that a build in part of the
syntax?  Is it an error?  Or maybe it's two or more operators run
together...I wonder where the breaks should be.

     If this change were made standard (and it is no where near ready
for that at this moment) you would simply say "ah, that's an operator"
in the same way that you can now say "ah, that's a method call" or "ah,
that's an integer."

> I know the argument gets made a lot that it can't hurt to have this
> feature, that feature, etc., because no one has to use them.  I think
> that misses the point, though.  It's like saying: a flute should have
> strings like a violin, in case someone wants it to be a violin.  What
> you end up with, eventually, is not a musical instrument but a kind of
> buffet of characteristics, adding up to nothing.  I consider Ruby not
> only an instrument, but a work of art, like a flute or violin.

     Ultimately, this patch would involve simplifying the parser,
removing parts rather than adding them.

> The idea of something being treated as either a flute or a violin
> sounds like duck typing :-)  What I'm saying, in those terms, is that
> I don't consider Ruby itself to be a Ruby object.  It's
> interesting....  I've thought for a long time that the flexibility and
> dynamism of Ruby objects sometimes rubs off on people's views of the
> language itself, so that the perception, expectation, or desire is for
> Ruby itself to be untyped, open, malleable, and so forth.  (Or is that
> 'mallardeable'? :-)  I tend to think of Ruby, instead, as a quite
> stable and distinctive thing whose stability supports the dynamism of
> the objects.  

     "mallardeable: able to be duck typed"!  I like that! 

> But at that level it's fine to agree to disagree; there is of course
> nothing whatsoever wrong with experimentation.  I guess my more
> concrete fear -- and I tend to feel this way about all interpreter
> patches -- is that people will start releasing programs that depend on
> the patch.  At that point, it would be better to do an outright fork
> of Ruby.  But hopefully that won't be an issue.  Mainly I just tend to
> agree with Hal that this particular change affects the whole profile
> and identity of the language.  

     1) I have no intention of forking, 2) I have no intention of
releasing programs that depend on this (though I may show samples of how
it could be used).  3) You guys are way overestimating the significance
and impact of this patch.  All I'm ultimately doing is cleaning up some
special cases in the syntax, making it so that things work consistently.

     I'd rather see potential language ideas floated as patches so that
people can try them and see if they like them before they get stuck with
them, but that's just the form my change adversity takes.

-- Markus