"davidl" wrote >? Thu, 23 Oct 2008 09:36:29 +0800,Steven Schveighoffer ><[EMAIL PROTECTED]> ??: > >> "Andrei Alexandrescu" wrote >>> Correx: >>> >>> http://www.reddit.com/r/programming/comments/78rmc/allowing_unicode_operators_in_d_similarly_to/ >>> >>> Andrei >>> >> >> No thanks. Please let's only use operators that are on the keys of my >> keyboard. I don't fancy having to type key digraphs or trigraphs to try >> and >> write code. >> >> I understand that others already have this problem, but I don't. This >> would >> be a huge detractor from D for me. I'd definitely support a language >> fork >> at that point, or at least refuse to deal with any code that has unicode >> operators. I think you'd find others feel the same way. >> >> Why can't the emacs module solution work that was used for the cheverons? >> That is, when emacs sees: >> >> x opCross(y); >> >> display it as >> >> x x y >> >> (of course, assume the middle x is the cross symbol, I have no idea how >> to >> type it). >> >> And upon save, regenerate the correct code. >> >> I see no issue with something like that. This is all the compiler is >> doing >> anyways... >> > > Everything you worry about is just poor editor. Why do you think an editor > can affect the language?
All that is being proposed right now is syntax sugar. Cross product, dot product, union, etc. All of these will map to a function, so there is no reason to require compiler support (that is, they don't translate directly to assembly/machine code). I'm proposing the editor be used to do the sugar instead of the compiler. Right now Unicode is not universally accepted by all editors, ASCII is. Right now, I don't have cross product symbol on my keyboard, all currently supported symbols I do have. Why should my experience with D be severely affected by your desire for syntax sugar? > And It complexes the language, if it's not priorly converted by the > programmer. Also it possibly sets up > future restrictions of extending the language in the correct direction! Today, I can call opX functions instead of using the appropriate operator. This is no different. > In your case: x opCross(y) , why identifier opCross(identifier) is > considered as identifier x identifier? > So would the typical operator overload function declaration should be > considered that way? > > x opCross(y) > { > } > > x x y > { > } > > or even > > x opCross(y, m){} > > ---> > > x x y, m {} > > also consider a template declaration > > Matrix opCross(T)(T a) > { > } > > should it be considered as Matrix x T (T a)? > > If not , how do you distinguish in all those circumstances(and not all > possible "shouldn't be" situations are listed here) The editor module would have to be (and can be) smarter than that. -Steve