> Similarly, if user defineable operators become a part of the language,
> nobody will be required to use them.
However, ISTM that what's being described here is a substantially different
language to Ruby.
Again, I think you are grossly overestimating what this patch does.
* Ruby already has a number of user definable operators, all
pulled from a set of operators characters.
* Ruby already gives users the ability to define any identifier
they want, by combining identifier characters in any order they
want, provided they don't conflict with a fixed set of keywords.
At it's core, all this patch does is remove the asymmetry in how
operator tokens are defined (to include any combination of operator
characters, using a simplified for of the code for identifiers).
* 90% of the change is in the lexer (which defines the composition
of symbols).
* The only reason the parser (which defines the syntax of ruby) is
touched at all is to simplify prevention of conflicts with
existing code & simplify the generation of meaningful error
messages. All of the changes in the parser consist of
duplicating a rule under a different name, which DOES NOT CHANGE
THE SYNTAX at all.
Not only is the language not "substantially different" it isn't
technically different at all.
However, Matz has been doing the language-design exercise for more than 10
years, and most of us are very happy with what he's produced. This idea has
probably been floated and considered in the past. If it's not in the
language, probably it doesn't fit his overall world view of what the
language should look like. Draw your own conclusions from his silence on
this thread, and on the likelihood of this feature ever making it into the
core.
Oh, that's just silly.
First of all, as I have made clear every time it came up, I am not
proposing (and will not propose) this for inclusion in the language
until/unless it can be shown to work in a way that does not break any
existing code, etc. We're not there yet.
Second, I have always found matz very open and able to perfectly
express himself. I don't need to "draw conclusions from his silence"
since I'll have ample opportunity to draw conclusions from whatever he
says if and when he says anything.
If I were to guess, I'd guess that he's waiting to see if I can
even make it work; he certainly knows how tricky even small changes can
be to get just right, and has seen several example of my C-skills (or
relative lack there of) over the last five years. If I can't make it
work, why bother arguing it (present company excepted of course)?
Third, I would never want the users of any of my software to assume
that missing features are missing because they don't fit my overall
world view. Nor would I want them to assume that bugs were there
intentionally, or read my silence as criticism. I'm pretty sure from
past interactions with him matz fells the same way.
Matz is a nice, reasonable, and very intelligent guy. If (and the
jury is still out) I can make this work and suggested it for actuall
use, but do so in a way that is incompatible with the big picture, I'm
sure he'll point it out to me himself.
> If it doesn't do anything important, it will be
> forgotten.
If it doesn't do anything important, then it shouldn't have been added in
the first place. ISTM that user-defined operators are nothing more than
syntactic sugar, which Ruby has plenty of already, and add nothing that
can't be done with a handful more keystrokes. I'd rather see discussion on
language semantics, which can make life substantially easier or harder when
programming.
There is a very specific need for the patch, as discussed earlier
on this list.
People (~five cases in the last two months) are arguing for changes
in the semantics of core classes because (and often only because) they
can't duplicate the functionality and/or subclass/modify it to suit
their needs.
One of the main strengths of ruby is that if I want a class that is
kind of like Array, but has slightly different semantics, I can subclass
it, or build my own class and delegate, or just reimplement it from
scratch. I can to do this with almost any class.
But there are a few classes (Hash & Range are the most current
examples) where "special syntax" is used, so I can't reimplement them to
suit. More to the point, no one can. This leads to long discussion
about how some core class "ought to work" when in fact 99% of the people
would be perfectly happy if they could roll their own versions as they
can with all the other classes.
Ultimately, my goal is to provide a way to _increase_ the stability
of the core language (compiler + base classes) by reducing the pressure
for changes.
> 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.
Or just use a different language in the first place, which is more suitable
to their particular problem domain.
Exactly the same problem arises with identifiers. Why aren't you
calling for a limit on user defined method names?
"Personally I see Ruby as a stable platform to do real work on, not an
experimental platform for wannabe language designers."
But then I realised it sounded bitchy as hell. No offence is intended to
anyone, so please substitute a less inflammatory statement of your choosing.
No offence taken. In the (yikes!) twenty six years since I was
first paid to design and implement a language I've been called things a
lot worse. "Wannabe language designer" sounds a lot fresher and more
optimistic (i.e. younger) that "crotchity semi-retired language
designer," so it's sort of a complement.
Now if people would only take me for a kid in person as readily as
they do on-line. *sigh*
-- Markus
···
On Sun, 2004-10-10 at 02:48, Brian Candler wrote:
On Sun, Oct 10, 2004 at 04:19:30AM +0900, Charles Hixson wrote:
I think yours