From: Charles Hixson <charleshixsn@...>
Date: 2004-10-10T04:19:30+09:00
Subject: Re: ANN: Free-form-operators patch

gabriele renzi wrote:

> Markus ha scritto:
>
>> On Fri, 2004-10-08 at 12:43, Hal Fulton wrote:
>>
>>> This is just my opinion, so don't take it the wrong way. And don't 
>>> stop your
>>> experimentation.  ;)
>>
>> ...
>
>
> the problem I can see is: +,*,- have a ,more or less obvious semantic. 
> You can expect them to be implemented to be similar things in 
> diffenret domains.
> The problem is: given that -> is not a standard operator, what could 
> happen if Angelina and Joe Automator implement themselve it for 
> different things?
>
> I mean, one could intend it as  a function definition operator, while 
> the other could use it to indicate movements of an hunter in the usual 
> wumpus labyrinth. then their two library would be completely 
> incompatible.
>
> Maybe we could be happy if standard operators such as
> += or != could be overriden, and everything could become prefix.
>  I guess this could be enough power.

This is a real problem.  Mutual dialects can diverge sufficiently to be 
mutually unintelligible.  BUT that won't happen to any significant 
degree unless each one is sufficiently useful in some problem domain 
area.  It's already possible to write unintelligible code in Ruby.  
(Certainly to write code that *I* can't understand.)  This doesn't mean 
that I feel that certain features which some people find very powerful 
and valuable should be removed from the language.  It means that I 
haven't yet bothered to learn how to use that part of the language.

Similarly, if user defineable operators become a part of the language, 
nobody will be required to use them.  And presumably people usually 
WON'T use them.  They'll only be (commonly) used where their use 
improves the code.  There will, of course, be experiments by J. Random 
Hacker, but so what?  If it doesn't do anything important, it will be 
forgotten.  If it does, then those who find it important will learn how 
to use that feature.  And if someone wants to use two mutually 
incompatible dialects, then they will need to come up with a way to 
harmonize them.  Exactly as is done with libraries of functions.

Every objection that I've heard to user defined operators would apply 
with equal vigor to user defined functions, if the language didn't 
already include them.

OTOH, if the argument is made that these techniques should be 
implemented as libraries that one needs to require... that has a lot of 
validity.  They should only be included in the core language if that 
would significantly improve the core itself.  The only other argument 
for including them in the core is if they can't be done any other way, 
and in that case it would probably be better for there to be an 
experimental fork of the code that included them.  (Undesireable, but 
better that including experimental features in the core.)

It shouldn't, and doesn't have to be, an all or nothing kind of thing.  
It should be a"Use however much you want, and don't complain bitterly if 
you cut your finger on the bleeding edge.  You were warned." kind of 
thing.  Naturally exotic features will have less support.  If they were 
in common use, they wouldn't be exotic.  And there should be a path into 
learning Ruby that's no steeper than the current path.  Currently one 
can learn enough to start being productive in a couple of hours.  And 
one can study for years, and still encounter new things.  This is an 
important characteristic!