On Sun, 2004-10-10 at 02:48, Brian Candler wrote: > On Sun, Oct 10, 2004 at 04:19:30AM +0900, Charles Hixson wrote: > > 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