[prev in list] [next in list] [prev in thread] [next in thread]
List: ruby-talk
Subject: Re: ANN: Free-form-operators patch
From: Charles Hixson <charleshixsn () earthlink ! net>
Date: 2004-10-14 19:09:52
Message-ID: 416ECDF3.8000301 () earthlink ! net
[Download RAW message or body]
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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic