On Sun, 2004-10-10 at 09:28, Randy W. Sims wrote:
> On 10/10/2004 11:51 AM, Markus wrote:
> > 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))
> 
> This is potentially still a problem area since Ruby allows reopening 
> builtin classes. Particularly, I worry about the number classes and String.

     I'm not sure what the problem is.  Or rather, if there is a
problem, what it has to do with operators.  I could write:

    class String
        def length
            rand(super*2)
            end
        end

right now, and I assume all havoc would ensue.  Should we then make
length a reserved word?  For that matter, should we make it so the user
can't defined there own '+', etc. (which they can now) because it might
cause something bad to happen?

     In any case, I don't see how this is a "namespace problem"; it
looks like maybe you'd like to finalize the core classes?  There are
ways to do this, from preventing any modification to warning when it
happens.  They would also catch operator definitions, since operators
are just methods.

> >       * 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)
> 
> First, I'll admit that I haven't taken the time to examine the diff. But 
> I'm concerned with the types of changes that must be necessary to the 
> lexer that might reduce Ruby's ability to catch errors or potential 
> errors when scanning the source. I'm also still not convinced that it 
> can deal with gracefully with ambiguity.

     In a sense you are correct; things that would have been errors
before might now be meaningful, and thus not caught.  This is the same
sort of thing that would happen if we only allowed /[a-z][0-9]?/
variable names and then decided that /[_a-z0-9]+/ was better: "x_axis",
which would have been an error, is now valid.
     It may also be true in another, more troubling sense: some
combination of operators which was meaningful BP (before the patch) may
be meaningful in two distinct ways AP (after the patch).  So how is the
compiler to decide?  My answer (which so far seems to work) is to treat
all such cases as they would have been treated BP, but generate a
warning suggesting the use of space to eliminate the ambiguity  Is that
sufficiently graceful?

> >>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).
> 
> I found the paper at:
> <http://www.research.att.com/~bs/whitespace98.pdf>

    Thanks, I'll take a look at it.

> I was hoping it might be taken as a hint. ;-) Actually, I don't see why 
> there should be any objections to using unicode characters as operators: 
> There are no conficts with the existing language. There are symbols 
> available that have obvious semantics. I can't think of any objections 
> as long as you limit the symbols that can be used so that only symbols 
> and not any "letters" are used.

     Over the years I have leaned that _anything_ can raise objections. 
In my first language (late 1970's) I had to provide two trig libraries
because correcting a typo in the taylor series coefficients (a bug fix
if ever there was one) broke a customer's must-match-exactly test
suite.  I had to support it through two releases (though it seemed much
longer) until they had a recertification and could accept the correct
answers.
 
> >>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?
> 
> Perl is known as a write only language because of it's heavy use of 
> symbols. That really refers more to the special variables $_, $@, $!, 
> etc., but it's very much the same concept. They have no obvious semantics.

     If things had obvious semantics, we'd all be out of jobs.

     But seriously, does '=>' have obvious semantics?  Why are they so
different from "<="?  Or how about the Range#member? vs. Range#include?
debate that's been going on for over a week now.

     Programming is hard because it is easy to write things badly and
hard to write things beautifully.  But languages with no operators are
as hard or harder to read (remember COBOL?) than languages with only
operators (remember APL?).  Somewhere in the middle is the sweet spot,
and it varies from program to program.  I can imagine cases that would
be much clearer with lots of operators, just as I can imagine cases that
would be clearer with lots of identifiers.

     Again, unless we are going to restrict the language to something
that is useless, we will just have to trust the programmer to do the
right thing (or join a mailing list and razz them until they do).

> I don't trust programmers. ;-)

     *smile*  Then you should lobby to outlaw computers.

    -- Markus