Re: Adding Unicode operators to D
Andrei Alexandrescu wrote: Yah. Something tells me Walter won't embark on that soon. Not a chance . Producing an amorphous list of tokens isn't what I'd call "parsing".
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 ;)
Re: Adding Unicode operators to D
Simen Kjaeraas wrote: So, anyone knows if it is possible on Windows (I believe in Unix it is) to configure your keyboard mapping with custom settings? For example, if I press AltGr-O, it inputs some Unicode character of my choosing? I'd guess this oughtta do it: http://www.microsoft.com/globaldev/tools/msklc.mspx I remember this same question being asked on a Microsoft DL when I was working there, and all the answers given were for third-party tools like KeyTweak ( http://webpages.charter.net/krumsick/ ) ;-P . Good to know there's an MS one.
Re: [OT] Windows Console
On Mon, Oct 27, 2008 at 1:52 PM, Robert Fraser <[EMAIL PROTECTED]> wrote: > torhu wrote: >> >> Bill Baxter wrote: >>> >>> On Mon, Oct 27, 2008 at 1:51 AM, torhu <[EMAIL PROTECTED]> wrote: Robert Fraser wrote: > > It uses the same console application to do the displaying/execution. > And, > yes, this application sucks (ever done any serious copy/paste in it?) That works fine for me if I enable Quick edit mode in the options. Then the right mouse button will do both copy and paste. >>> >>> Except it only does block-oriented rectangular selection, which is odd >>> for something that is primarily line-oriented. >> >> Yeah, that's true. Pretty stupid. > > My main problem is that you can't do it just with the keyboard, which is my > standard method. I also take issue with the fact you can't copy more than is > visible on a single screen, which goes along with the block selection mode. > By the way I tried running powershell as a tab inside the Console2 prog I mentioned before and it does work fine. --bb
Re: [OT] Windows Console
torhu wrote: Bill Baxter wrote: On Mon, Oct 27, 2008 at 1:51 AM, torhu <[EMAIL PROTECTED]> wrote: Robert Fraser wrote: It uses the same console application to do the displaying/execution. And, yes, this application sucks (ever done any serious copy/paste in it?) That works fine for me if I enable Quick edit mode in the options. Then the right mouse button will do both copy and paste. Except it only does block-oriented rectangular selection, which is odd for something that is primarily line-oriented. Yeah, that's true. Pretty stupid. My main problem is that you can't do it just with the keyboard, which is my standard method. I also take issue with the fact you can't copy more than is visible on a single screen, which goes along with the block selection mode.
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: Adding Unicode operators to D
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. --bb
Re: Adding Unicode operators to D
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. Andrei
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
Simen Kjaeraas wrote:
On Sun, 26 Oct 2008 22:28:16 +0100, Bill Baxter <[EMAIL PROTECTED]> wrote:
On Sun, Oct 26, 2008 at 11:02 PM, Simen Kjaeraas
<[EMAIL PROTECTED]> wrote:
On Sat, 25 Oct 2008 12:14:47 +0200, Spacen Jasset
<[EMAIL PROTECTED]>
wrote:
Why unicode anyway? In the same way that editor support is required to
actually type them in, why not let the editor render them. So
instead of
symbol 'x' in the source code, say:
m3 = m1 cross_product m2
as an infix notatation in a similar way to the (uniary) sizeof
operator.
While cross_product is a bit long and unwieldy any editor capable can
replace the rendition of that keyword with a symbol for it. But in
editors
that don't it means that it still can be typed in and/or displayed
easily.
Another option includes providing cross_product as an 'alias' and 'X'
aswell.
Which then leads on to the introduction of a facility to add arbitary
operators, which could be interesting becuase you can supply any
operator
you see fit for the domains that you use that require it. -- This
provide
exactly the right solution though as all the additions would be 'non
standard' and I can see books in the future recommending people not use
unicode operators, becuase editors don't have support for them.
This made me think. What if we /could/ define arbitrary infix
operators in
D? I'm thinking something along the lines of:
operator cross_product(T, U)
{
static if (T.opCross)
{
T.opCross(T)
}
else static if (U.opCross)
{
U.opCross_r(T);
}
else
{
static assert(false, "Operator not applicable to operands.");
}
}
alias cross_product ×;
I'm not sure if this is possible, but it sure would please downs. :P
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.
Andrei
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 8:23 AM, Simen Kjaeraas <[EMAIL PROTECTED]> wrote:
> On Sun, 26 Oct 2008 22:28:16 +0100, Bill Baxter <[EMAIL PROTECTED]> wrote:
>
>> On Sun, Oct 26, 2008 at 11:02 PM, Simen Kjaeraas <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On Sat, 25 Oct 2008 12:14:47 +0200, Spacen Jasset
>>> <[EMAIL PROTECTED]>
>>> wrote:
>>>
Why unicode anyway? In the same way that editor support is required to
actually type them in, why not let the editor render them. So instead of
symbol 'x' in the source code, say:
m3 = m1 cross_product m2
as an infix notatation in a similar way to the (uniary) sizeof operator.
While cross_product is a bit long and unwieldy any editor capable can
replace the rendition of that keyword with a symbol for it. But in
editors
that don't it means that it still can be typed in and/or displayed
easily.
Another option includes providing cross_product as an 'alias' and 'X'
aswell.
Which then leads on to the introduction of a facility to add arbitary
operators, which could be interesting becuase you can supply any
operator
you see fit for the domains that you use that require it. -- This
provide
exactly the right solution though as all the additions would be 'non
standard' and I can see books in the future recommending people not use
unicode operators, becuase editors don't have support for them.
>>>
>>> This made me think. What if we /could/ define arbitrary infix operators
>>> in
>>> D? I'm thinking something along the lines of:
>>>
>>>
>>> operator cross_product(T, U)
>>> {
>>> static if (T.opCross)
>>> {
>>> T.opCross(T)
>>> }
>>> else static if (U.opCross)
>>> {
>>> U.opCross_r(T);
>>> }
>>> else
>>> {
>>> static assert(false, "Operator not applicable to operands.");
>>> }
>>> }
>>>
>>> alias cross_product ×;
>>>
>>>
>>> I'm not sure if this is possible, but it sure would please downs. :P
>>
>> 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
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
Re: Adding Unicode operators to D
On Sun, 26 Oct 2008 22:28:16 +0100, Bill Baxter <[EMAIL PROTECTED]> wrote:
On Sun, Oct 26, 2008 at 11:02 PM, Simen Kjaeraas
<[EMAIL PROTECTED]> wrote:
On Sat, 25 Oct 2008 12:14:47 +0200, Spacen Jasset
<[EMAIL PROTECTED]>
wrote:
Why unicode anyway? In the same way that editor support is required to
actually type them in, why not let the editor render them. So instead
of
symbol 'x' in the source code, say:
m3 = m1 cross_product m2
as an infix notatation in a similar way to the (uniary) sizeof
operator.
While cross_product is a bit long and unwieldy any editor capable can
replace the rendition of that keyword with a symbol for it. But in
editors
that don't it means that it still can be typed in and/or displayed
easily.
Another option includes providing cross_product as an 'alias' and 'X'
aswell.
Which then leads on to the introduction of a facility to add arbitary
operators, which could be interesting becuase you can supply any
operator
you see fit for the domains that you use that require it. -- This
provide
exactly the right solution though as all the additions would be 'non
standard' and I can see books in the future recommending people not use
unicode operators, becuase editors don't have support for them.
This made me think. What if we /could/ define arbitrary infix operators
in
D? I'm thinking something along the lines of:
operator cross_product(T, U)
{
static if (T.opCross)
{
T.opCross(T)
}
else static if (U.opCross)
{
U.opCross_r(T);
}
else
{
static assert(false, "Operator not applicable to operands.");
}
}
alias cross_product ×;
I'm not sure if this is possible, but it sure would please downs. :P
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
--
Simen
Re: Adding Unicode operators to D
On Sun, Oct 26, 2008 at 11:02 PM, Simen Kjaeraas <[EMAIL PROTECTED]> wrote:
> On Sat, 25 Oct 2008 12:14:47 +0200, Spacen Jasset <[EMAIL PROTECTED]>
> wrote:
>
>> Why unicode anyway? In the same way that editor support is required to
>> actually type them in, why not let the editor render them. So instead of
>> symbol 'x' in the source code, say:
>>
>> m3 = m1 cross_product m2
>>
>> as an infix notatation in a similar way to the (uniary) sizeof operator.
>>
>>
>> While cross_product is a bit long and unwieldy any editor capable can
>> replace the rendition of that keyword with a symbol for it. But in editors
>> that don't it means that it still can be typed in and/or displayed easily.
>>
>> Another option includes providing cross_product as an 'alias' and 'X'
>> aswell.
>>
>> Which then leads on to the introduction of a facility to add arbitary
>> operators, which could be interesting becuase you can supply any operator
>> you see fit for the domains that you use that require it. -- This provide
>> exactly the right solution though as all the additions would be 'non
>> standard' and I can see books in the future recommending people not use
>> unicode operators, becuase editors don't have support for them.
>
> This made me think. What if we /could/ define arbitrary infix operators in
> D? I'm thinking something along the lines of:
>
>
> operator cross_product(T, U)
> {
> static if (T.opCross)
> {
>T.opCross(T)
> }
> else static if (U.opCross)
> {
>U.opCross_r(T);
> }
> else
> {
>static assert(false, "Operator not applicable to operands.");
> }
> }
>
> alias cross_product ×;
>
>
> I'm not sure if this is possible, but it sure would please downs. :P
What's the precedence of your user-defined in-fix operator?
--bb
Re: [OT] Windows Console
Bill Baxter wrote: On Mon, Oct 27, 2008 at 1:51 AM, torhu <[EMAIL PROTECTED]> wrote: Robert Fraser wrote: It uses the same console application to do the displaying/execution. And, yes, this application sucks (ever done any serious copy/paste in it?) That works fine for me if I enable Quick edit mode in the options. Then the right mouse button will do both copy and paste. Except it only does block-oriented rectangular selection, which is odd for something that is primarily line-oriented. Yeah, that's true. Pretty stupid.
Re: [OT] Windows Console
On Mon, Oct 27, 2008 at 1:51 AM, torhu <[EMAIL PROTECTED]> wrote: > Robert Fraser wrote: >> >> It uses the same console application to do the displaying/execution. And, >> yes, this application sucks (ever done any serious copy/paste in it?) > > That works fine for me if I enable Quick edit mode in the options. Then the > right mouse button will do both copy and paste. Except it only does block-oriented rectangular selection, which is odd for something that is primarily line-oriented. --bb
Re: Delight
Thomas Leonard: > Having 'function' or 'delegate' come first makes parsing easier (e.g. for > syntax highlighters, etc). A syntax like C# lambdas looks better, but I understand your points. func o fun or def may be used as shorter form of function. Bye, bearophile
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. Perhaps what needs to be added is a syntax for defining character to function correspondence? That way people could define the binary functions that they need, and then define a corresponding character string that represented it. I once recommended that Eiffel include a means of defining user operators (i.e., binary functions that sit between the terms on which the operate) using the name syntax thusly: Starts and ends with '|' and doesn't contain any whitespace. Must be surrounded by whitespace when used. I.e. 1 |X|-3 would be forbidden, as there is no whitespace following the |X| operator. That still seems like a good rule to me. If you want to include unicode, that's no problem. And the function could also be used as: X(1, -3) with identical meaning. I.e., marking a function as an operator by surrounding it with pipes would be purely syntax sugar. Note that such operators would have a precedence higher than assignment, but lower than everything else, so in practice the choice would be between writing: X (1, -3) and writing: (1 |X| -3) unless all one were doing is making an assignment. This is analogous to the class member variable in object methods, or the class name in class methods, except that that is often understood. OTOH, I'm not certain how much such syntax buys you. P.S.: another possibility, which is more in line with current D syntax requires an assignment of the operator character to a function that starts with op. As in '+' is associated with opAdd. However even though this is more in line with current D syntax, it seems to buy you a lot less. And it seems to require that the operator be a single character. This appears to me to be more work than it's worth for the return. Even the approach that I suggested is probably marginal. P.P.S: Any system that requires that a specific IDE or editor be used is no going to work. Not unless the IDE were provided with the language, and even then the most successful examples I can thing of are EMACS and Smalltalk. (I'm excluding programs that don't run on Linux, as I have no familiarity with either how they function or how popular they are. Probably, though, one could include Visual Basic and maybe some other
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 \× and \∅ so we could reuse them in source code level as I've described somewhere in this thread. auto torque = position \× 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 \ˆ 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
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
[OT] Windows Console
Robert Fraser wrote: It uses the same console application to do the displaying/execution. And, yes, this application sucks (ever done any serious copy/paste in it?) That works fine for me if I enable Quick edit mode in the options. Then the right mouse button will do both copy and paste.
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
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; // \Ø 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: Delight
On Sun, 12 Oct 2008 09:56:56 -0400, bearophile wrote:
> More things from the site:
> Thomas Leonard:
>>- anonymous functions work ("function(int x): x + 1"). This is like
> lambda in Python.<
>
> Note that D1 and D2 already support this syntax: (int x, float y) {
> return x+y; }
Unfortunately, the corresponding syntax is ambiguous:
while 1 + (something): ...
Is something an expression or a list of arguments? D just looks after the
closing ) and sees that the next character is a block start, but that
only works because it always has an extra outer pair of ().
We could do something like:
map( (int x) -> x + 1, [1,2,3])
But I don't really like having to look ahead to work out what it is.
Having 'function' or 'delegate' come first makes parsing easier (e.g. for
syntax highlighters, etc).
>>- any object can be implicitly cast to Object (D doesn't allow this)<
>
> Is this good? (just asking)
I've now adding a 'linkage' field to interfaces. You can cast any
interface to Object iff it has D linkage. So COM objects can't be
accidentally treated as D objects again, but it's still convenient
in the common case.
I don't use COM, but I needed this when adding GObject linkage:
http://delight.sourceforge.net/gtk.html
>>Statements end at the end of a line. Semi-colons are not required.<
>
> Is the \ syntax possible for too much long lines, as in Python?
Currently you need some kind of brackets, but I'll add \ at some point.
Re: Adding Unicode operators to D
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. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Re: Adding Unicode operators to D
Simen Kjaeraas wrote: On Fri, 24 Oct 2008 18:28:51 +0200, Bruno Medeiros <[EMAIL PROTECTED]> wrote: Andrei Alexandrescu 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/ Andrei I'm unsure about this idea. I don't know if it would be worthwhile, but I would say there are two aspects that likely would need to be observed for this to work out favorably: * Having non-unicode versions of the symbols/keywords available in Unicode, such that non-Uunicode editing and viewing is always possible as a fallback. This has some important consequences though, such as making Unicode-symbol-usage unable to solve the shortage of brackets for, for example, the template instantiation syntax (because an alternative ASCII notation would still be necessary). * Having a way to directly input the Unicode symbols in the keyboard. One reason is because of typing succinctness, and another, is because I find the alternative (have the editor/IDE automatically change an ASCII character sequence into a Unicode symbol) to have several disadvantages: First is that it doesn't work outside the editors/IDEs configured to do so, (which is a bummer, there is actually plenty of code written outside that: newsgroups, articles, forums, bug reports, IRC, etc.). Second, I personally like that the editor always require exactly N backspaces to erase N typed characters[*]. So, anyone knows if it is possible on Windows (I believe in Unix it is) to configure your keyboard mapping with custom settings? For example, if I press AltGr-O, it inputs some Unicode character of my choosing? I'd guess this oughtta do it: http://www.microsoft.com/globaldev/tools/msklc.mspx Yes, exactly that! I had the impression there was such a program for Windows, but couldn't remember the name. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Re: Adding Unicode operators to D
Steven Schveighoffer Wrote: > The responsible party for displaying UTF properly is the console, not the > shell. > One important feature of legacy technology is it must not change for compatibility with legacy code, stdout is just an oblique pipe and one has no means to specify text encoding and legacy applications write OCP-encoded text to stdout, that's why console expects OCP output and breaking this convention will break legacy applications, piping etc, etc. BTW, cmd.exe can in fact produce utf-16 output.
Re: Adding Unicode operators to D
On Sat, 25 Oct 2008 12:14:47 +0200, Spacen Jasset
<[EMAIL PROTECTED]> wrote:
Why unicode anyway? In the same way that editor support is required to
actually type them in, why not let the editor render them. So instead of
symbol 'x' in the source code, say:
m3 = m1 cross_product m2
as an infix notatation in a similar way to the (uniary) sizeof operator.
While cross_product is a bit long and unwieldy any editor capable can
replace the rendition of that keyword with a symbol for it. But in
editors that don't it means that it still can be typed in and/or
displayed easily.
Another option includes providing cross_product as an 'alias' and 'X'
aswell.
Which then leads on to the introduction of a facility to add arbitary
operators, which could be interesting becuase you can supply any
operator you see fit for the domains that you use that require it. --
This provide exactly the right solution though as all the additions
would be 'non standard' and I can see books in the future recommending
people not use unicode operators, becuase editors don't have support for
them.
This made me think. What if we /could/ define arbitrary infix operators in
D? I'm thinking something along the lines of:
operator cross_product(T, U)
{
static if (T.opCross)
{
T.opCross(T)
}
else static if (U.opCross)
{
U.opCross_r(T);
}
else
{
static assert(false, "Operator not applicable to operands.");
}
}
alias cross_product ×;
I'm not sure if this is possible, but it sure would please downs. :P
--
Simen
Re: Adding Unicode operators to D
Andrei Alexandrescu 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/ Andrei I've been following this thread without really having an opinion to offer, but I just had a thought... We already know that D's CTFE and templates can be used together to parse DSLs (matrix ops, regular expressions and IIRC Scheme too) and turn them into optimal native code. That suggests to me that it is already possible to write D code that can turn an expression written in established mathematic/scientific notation (complete with unicode symbols) into either conventional D code, or machine code. What I am not sure of is whether is would be possible to make it general enough to work with all mathmatical dialects (I seem to remember some overlapping in ways that might be problematic). A complete solution would have to be able to define new operatos (including thier associativity and precidence) in such a way that they can be looked up by the templates that evaluate the expresion. Another related thought I had: Would it be possible to write a compile-time parser that turned MathML into code? I'm not even sure if MathML is structured enough to represent the undelying meaning of an expression rather than just its graphical form. Perhaps it would be more interesting to write the code that did the tranformation in the opposite direction, turning expressions written in D into MathML ^^ A...
