Markus wrote:

>On Wed, 2004-10-13 at 13:13, Charles Hixson wrote:
>  
>
>>Yukihiro Matsumoto wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>In message "Re: ANN: Free-form-operators patch"
>>>   on Mon, 11 Oct 2004 17:38:39 +0900, Yukihiro Matsumoto <matz / ruby-lang.org> writes:
>>>...
>>>
>>One way to handle that (changing the patch a bit) is to require all user 
>>defined operators to be of the form \|.*\| e.g., |+|, or |-|.  That 
>>would allow all user defined operators to be easily distinguished from 
>>the built-ins.  This would allow any desired builtins to be added later, 
>>and also make the user defined operators readily recognizable.
>>    
>>
>
>     That should be a trivial patch to the patch, if that seems to
>increase the net happiness of the world.  If others speak in favor of
>the idea I'll work it up (*smile* or you are of course free to try your
>hand at it if you prefer).  
>
>    -- Markus
>
>P.S. I am taking the "." in your regexp to mean "any operator character"
>and not "any character" as the later would lead to untold complications.
>  
>
That's the way I was thinking of it.  It I meant something closer to 
"anything", I'd need to have specified an explicit leading and trailing 
space as a (shareable) part of the operator.  Which would have meant 
puntuation around parenthetical expressions would be QUITE unexpected.

OTOH, it would, occasionally, be nice to have a |CrossProduct| operator :-).

More seriously, so many people object to operators being ambiguous, or 
not self-identifying, that I can see a good argument for allowing such, 
provided it was clearly demarkated.  But that also strikes me as a bit 
too far from the normal way that Ruby does things, so I'm sure not going 
to push for it.

OTOH, were I designing a language from scratch, I would make spaces much 
more syntactically necessary than Ruby does.  Ruby, in fact, prohibits 
spaces in many places where I find them esthetically desireable (say in 
function expressions, after the function name and before the opening 
parenthesis of the argument).  And I would allow operators to be 
syntactially marked variable names.  In fact, for procedures with 
arguments of the form (in, in, out) or (in, out) in any permutation, I 
would allow the procedure name to be automatically converted into an 
operator (possibly by enclosing it in vertical bars.  But that's just my 
esthetic, which I know to be quite different from those of many another.

For that matter, I'd go out of my way to make the language easily 
parseable, and also to have a large subset that was readily compileable  
(with easy linkage between the full language that required an 
interpreter and the subset that was compileable.)

OTOH...I haven't built a language since college, and don't seem to have 
any strong inclinations in that direction, so my choices aren't that 
significant.