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.

>       * 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.

>      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).

I found the paper at:
<http://www.research.att.com/~bs/whitespace98.pdf>

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.

>>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.

>>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.

I don't trust programmers. ;-)

>      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

Randy.