Re: Adding Unicode operators to D
KennyTM~ wrote: Bruno Medeiros wrote: Simen Kjaeraas wrote: As an example, while I'd enjoy seeing code like this, I'm not sure I'd enjoy writing it (Note that I am prone to exaggerations): int a = ∅; //empty set, same as = void int[] b = [1,2,3,4,5,6]; a = readInt(); Hum, interesting example, it actually made me realize that 'null' would be an ideal candidate for having a Unicode symbol of it's own. Does anyone have suggestions for a possible one? Preferably somewhat circle-shaped. auto Ø = null; // \Oslash; I assume you're not serious... It's an interesting and effective way to save some typing, and it might be even more readable (but with a symbol other than Ø). But I probably would not use it anyway, since I like to write very standardized code, that other people can easily recognize and read. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Re: Adding Unicode operators to D
Bruno Medeiros wrote: Andrei Alexandrescu wrote: Spacen Jasset wrote: Bill Baxter wrote: On Thu, Oct 23, 2008 at 7:27 AM, Andrei Alexandrescu [EMAIL PROTECTED] wrote: Please vote up before the haters take it down, and discuss: http://www.reddit.com/r/programming/comments/78rjk/allowing_unicode_operators_in_d_similarly_to/ (My comment cross posted here from reddit) I think the right way to do it is not to make everything Unicode. All the pressure on the existing symbols would be dramatically relieved by the addition of just a handful of new symbols. The truth is keyboards aren't very good for inputting Unicode. That isn't likely to change. Yes they've dealt with the problem in Asian languages by using IMEs but in my opinion IMEs are horrible to use. Some people seem to argue it's a waste to go to Unicode only for a few symbols. If you're going to go Unicode, you should go whole hog. I'd argue the exact opposite. If you're going to go Unicode, it should be done in moderation. Use as little Unicode as necessary and no more. As for how to input unicode -- Microsoft Word solved that problem ages ago, assuming we're talking about small numbers of special characters. It's called AutoCorrect. You just register your unicode symbol as a misspelling for (X) or something unique like that and then every time you type (X) a funky unicode character instantly replaces those chars. Yeh, not many editors support such a feature. But it's very easy to implement. And with that one generic mechanism, your editor is ready to support input of Unicode chars in any language just by adding the right definitions. --bb I am not entirely sure that 30 or (x amount) of new operators would be a good thing anyway. How hard is it to say m3 = m1.crossProduct(m2) ? vs m3 = m1 X m2 ? and how often will that happen? It's also going to make the language more difficult to learn and understand. I have noticed that in pretty much all scientific code, the f(a, b) and a.f(b) notations fall off a readability cliff when the number of operators grows only to a handful. Lured by simple examples like yours, people don't see that as a problem until they actually have to read or write such code. Adding temporaries and such is not that great because it further takes the algorithm away from its mathematical form just for serving a notation that was the problem in the first place. But what operators would be added? Some mathematician programmers might want vector and matrix operators, others set operators, others still derivation/integration operators, and so on. Where would we stop? I don't deny it might be useful for them, but it does seem like too specific a need to integrate in the language. Composition may be useful for functional programming (I've never used any functional programming paradigm except reduce.) Matrix operations: + - * .tr() .inv() .det() etc are already sufficient for most jobs. Vector operations: Maybe an operator for cross product. Set operators: Just use + - * (| ~ ) instead like Pascal. So only 2 Unicode operators I see are really useful and the replacements are ugly: Composition (o) and cross product (×).
Re: Adding Unicode operators to D
Andrei Alexandrescu wrote: Bruno Medeiros wrote: Andrei Alexandrescu wrote: Spacen Jasset wrote: Bill Baxter wrote: On Thu, Oct 23, 2008 at 7:27 AM, Andrei Alexandrescu [EMAIL PROTECTED] wrote: Please vote up before the haters take it down, and discuss: http://www.reddit.com/r/programming/comments/78rjk/allowing_unicode_operators_in_d_similarly_to/ (My comment cross posted here from reddit) I think the right way to do it is not to make everything Unicode. All the pressure on the existing symbols would be dramatically relieved by the addition of just a handful of new symbols. The truth is keyboards aren't very good for inputting Unicode. That isn't likely to change. Yes they've dealt with the problem in Asian languages by using IMEs but in my opinion IMEs are horrible to use. Some people seem to argue it's a waste to go to Unicode only for a few symbols. If you're going to go Unicode, you should go whole hog. I'd argue the exact opposite. If you're going to go Unicode, it should be done in moderation. Use as little Unicode as necessary and no more. As for how to input unicode -- Microsoft Word solved that problem ages ago, assuming we're talking about small numbers of special characters. It's called AutoCorrect. You just register your unicode symbol as a misspelling for (X) or something unique like that and then every time you type (X) a funky unicode character instantly replaces those chars. Yeh, not many editors support such a feature. But it's very easy to implement. And with that one generic mechanism, your editor is ready to support input of Unicode chars in any language just by adding the right definitions. --bb I am not entirely sure that 30 or (x amount) of new operators would be a good thing anyway. How hard is it to say m3 = m1.crossProduct(m2) ? vs m3 = m1 X m2 ? and how often will that happen? It's also going to make the language more difficult to learn and understand. I have noticed that in pretty much all scientific code, the f(a, b) and a.f(b) notations fall off a readability cliff when the number of operators grows only to a handful. Lured by simple examples like yours, people don't see that as a problem until they actually have to read or write such code. Adding temporaries and such is not that great because it further takes the algorithm away from its mathematical form just for serving a notation that was the problem in the first place. But what operators would be added? Some mathematician programmers might want vector and matrix operators, others set operators, others still derivation/integration operators, and so on. Where would we stop? I don't deny it might be useful for them, but it does seem like too specific a need to integrate in the language. I was thinking of allowing a general way of defining one Unicode character to stand in as one operator, and then have libraries implement the actual operators. There's the remaining problem of different libraries defining the same character to mean different operators. This may not be huge as math subdomains tend to be rather consistent in their use of operators. Across math subdomains, types and overloading can take care of things. Also, ascii representation should be allowed for operators, and one nice thing about Unicode characters is that many have HTML ascii and human-readable names, see http://www.fileformat.info/format/w3c/htmlentity.htm. So \unicodecharname may be a good alternate way to enter these operators. For example, the empty set could be \empty, and the cross-product could be written as \times. So c = a \times b; doesn't quite look bad to me. One nice thing about this is that we don't need to pore over naming and such, we just use stuff that others (creators and users alike) have already pored over. Saves on documentation writing too :o). Andrei LaTeX in D? :p Anyway we already have \times; and \empty; so we could reuse them in source code level as I've described somewhere in this thread. auto torque = position \times; force; This is uglier than auto torque = position \times force; but it gives a uniform syntax between escape sequences inside and outside strings. The problem is you may have to invent some names, i.e. the composition operator ∘ (U+2218 ring operator) has no name in SGML entities. In LaTeX it is represented as \circ but \circ; is already taken by ˆ (U+02C6 modifier letter circumflex accent). And you'll need to predefine the associativity and operation precedence too. ;) See my other entry in this thread.
Re: Adding Unicode operators to D
On Mon, 27 Oct 2008 00:41:26 +0100, Bill Baxter [EMAIL PROTECTED] wrote: Same thing goes for downs' in-fix operators. I think his syntax is /infix/ which means that his ops always have the same precedence as division. I'm guessing this Python Cookbook recipe is very similar to Downs' technique. It discusses pros and cons and such. http://code.activestate.com/recipes/384122/ --bb An interesting read, though I have looked at downs' code before. It occured to me now that this could sorta have been fixed with a preprocessor, just define an operator to have the same precedence as an already existing operator, define an alias that gets replaced with /foo/, +foo+, or whatever operator you chose. I guess we're stuck waiting for macros in the meantime. -- Simen
Re: Adding Unicode operators to D
On Mon, Oct 27, 2008 at 9:04 AM, Andrei Alexandrescu [EMAIL PROTECTED] wrote: What's the precedence of your user-defined in-fix operator? --bb Yup, I realized this myself as well. Seemed like such a great idea when I only thought of it for three seconds. :p An operator could always be defined to have the same precedent as an existing operator, which it has to specify. Walter said in a previous post a few days ago when I suggested it that that would kill D's easy parsability. You say no? I'm no parser expert, so hard for me to say. --bb
Re: Adding Unicode operators to D
Bill Baxter wrote: On Mon, Oct 27, 2008 at 11:43 AM, Andrei Alexandrescu [EMAIL PROTECTED] wrote: Bill Baxter wrote: On Mon, Oct 27, 2008 at 9:04 AM, Andrei Alexandrescu [EMAIL PROTECTED] wrote: What's the precedence of your user-defined in-fix operator? --bb Yup, I realized this myself as well. Seemed like such a great idea when I only thought of it for three seconds. :p An operator could always be defined to have the same precedent as an existing operator, which it has to specify. Walter said in a previous post a few days ago when I suggested it that that would kill D's easy parsability. You say no? I'm no parser expert, so hard for me to say. It can be done, but it's kinda involved. You define a grammar in which all operators have the same precedence. Consequently you compile any expression into a list of operands and operators. That makes the language parsable without semanting info. Then the semantic stage transforms the list into a tree. Cecil does that. I see. So the price you pay is that you defer more decisions till semantic stage. I.e. a b c d e is allowed to parse into an amorphous list, then in the semantic pass you decide if 'b' and 'd' are actually legal operators or not. Yah. Something tells me Walter won't embark on that soon. Andrei
Re: Statistics library
Reply to dsimcha, Yes, I realize that it's best to do things like this off the newsgroup, but your email address doesn't seem to work. Sorry. I figure I get enough SPAM as it is. Besides, there are about 2 dozen other ways to get it if you are persistent enough Oh. Your in, have fun (I really ought to make up some boiler plate like this: http://en.wikipedia.org/wiki/Sudo#Design ;)
