在 Thu, 23 Oct 2008 21:55:19 +0800，Steven Schveighoffer <[EMAIL PROTECTED]> 写道:
> "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 > > > If your editor doesn't really translate those sugar to real binary, the compiler will need to be that smart enough to distinguish all those possibilities. If you meant editor should translate those sugar to real unicode operators, we're done here. DavidLeon
