From: Markus <markus@...>
Date: 2004-10-11T00:51:04+09:00
Subject: Re: ANN: Free-form-operators patch

On Sun, 2004-10-10 at 07:55, Randy W. Sims wrote:
> Actually, this is the wrong argument. I don't think anyone is against 
> change. But some of us feel that there are some potential problems or 
> dangers associated with this particular change.

     Exactly why I value this discussion.  I am very interested in
"potential problems" (as opposed to misunderstandings or groundless
fears).  What, in particular, are people worried about?  I've already
heard:

      * Will break existing code (consequence: as a goal, the patch will
        not be considered successful if it breaks _any_ existing code. 
        I even handled "proc {|x,*|x}" which I consider a bug).
      * Will lead to namespace conflicts (consequence: I've tried to
        clarify that this is not the case, since operators are
        dispatched in the same way methods are (to the receiver))
      * Will change the syntax of ruby, or turn it into "syntax soup"
        (consequence: I've tried to clarify that this is not the case a
        free posts back in this thread)

     But I'm very interested in any specific problems you (or anyone
else) can see with the idea.  I use ruby in production; I WANT IT TO BE
STABLE.  The whole goal here is to remove the pressure to change the
semantics of core classes by letting people write their own versions
without being relegated to a syntactic ghetto.  So I am as concerned as
anyone (maybe more; how many of you support over 20,000 lines of ruby
code in production use); I honestly want to know if there are any actual
problems with this, and what they are, in detail.

> A long time ago I was reading one of Bjarne Stroustrup's books or on his 
> website where he proposed user defined operators. At the time I was 
> excited about it and looked forward to it. Unicode provides lots of neat 
> symbols that would make meaningful operators. If this patch allowed 
> that, I might be more inclined to agree with it.

    Great idea.  I'll look into it.  (Though I suspect that that too may
raise some people's ire).

> But that's the heart of the problem: assigning meaning to an arbitrary 
> combination of symbols makes the resulting code hard to interpret. Among 
> the objections listed, I think this is the hardest to overcome. 

     Harder for the compiler?  Not really.  Harder for humans?  Perhaps,
if done poorly.  But that depends on the choices the programmer makes. 
You can write obsfucated code in any language, or even by misusing any
feature of any language.  That doesn't mean that we shouldn't allow
languages to have features in general, does it?

> Some have compared operators to methods, but that comparison doesn't 
> really hold. IMO the only comparison there is if you used method names 
> like 'sdkjfo' - arbitrary combinations of characters with no inherant 
> semantics.

     This is a case of "trust the programmer"; people could in fact use
sdkjfo as an identifier (presumably to hold the software developers kit
java kernel object), but we trust them to be judicious.

     For that matter, it may be _much_easier_ for most of the world's
population to interpret code written with a judicious choice of
user-defined operators than with clear and simple identifiers in a
language they don't speak fluently.  I suspect we are all grateful that
matz didn't restrict identifiers to properly formed japanese phrases (to
prevent confusion of course), aren't we?

    -- Markus