www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Unicode operators

reply Moritz Warning <moritzwarning web.de> writes:
Unicode operators would be nice addition to D.

Since it's common to have opFooBar style operators overloads in D,
I would like to rise the question what unicode operators do users need 
(most) or would like to have?

opDotProduct and opCrossProduct would be definitely cool.
Oct 22 2008
next sibling parent reply Thomas Moran <no spam.plx> writes:
I usually lurk here but I wanted to weigh in and say I think this would 
be a great thing. It's depressing to see people worrying about whether 
"." or "!" is more appropriate for a particular operator when the real 
problem is that a different symbol is required. Mathematicians have no 
qualms about using 5 different alphabets and 10 kinds of brackets to 
describe things, and there's no fundamental reason computer programs 
should be any different, except for the fact that entering the symbols 
is awkward. Hopefully that will change. I know there's been at least one 
font in Windows since win2k that has glyphs for the whole Basic 
Multilingual Plane, and there are a lot more that support at least the 
greek alphabet and some extended punctuation. I'm sure the situation is 
similar in Linux.

Since C++ permits unicode identifiers I actually did some experiments a 
few months ago to see what the compiler support was like. The conclusion 
was that only MSVC9 can deal with them, GCC4 and ICC10 (EDG I suppose) 
both choked. You can actually call a variable "αβγ" in VC9 and the 
program compiles. There's unfortunately some confusion over whether 
UTF-8 encoded files should have a BOM - MSVC doesn't parse them properly 
if they don't, but GCC chokes on the BOM. I think this would have to be 
either specified or handled flexibly in D front ends.
Oct 22 2008
next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
T24gV2VkLCBPY3QgMjIsIDIwMDggYXQgOTowMSBQTSwgVGhvbWFzIE1vcmFuIDxub0BzcGFtLnBs
eD4gd3JvdGU6Cj4gU2luY2UgQysrIHBlcm1pdHMgdW5pY29kZSBpZGVudGlmaWVycyBJIGFjdHVh
bGx5IGRpZCBzb21lIGV4cGVyaW1lbnRzIGEgZmV3Cj4gbW9udGhzIGFnbyB0byBzZWUgd2hhdCB0
aGUgY29tcGlsZXIgc3VwcG9ydCB3YXMgbGlrZS4gVGhlIGNvbmNsdXNpb24gd2FzCj4gdGhhdCBv
bmx5IE1TVkM5IGNhbiBkZWFsIHdpdGggdGhlbSwgR0NDNCBhbmQgSUNDMTAgKEVERyBJIHN1cHBv
c2UpIGJvdGgKPiBjaG9rZWQuIFlvdSBjYW4gYWN0dWFsbHkgY2FsbCBhIHZhcmlhYmxlICLh4uMi
IGluIFZDOSBhbmQgdGhlIHByb2dyYW0KPiBjb21waWxlcy4gVGhlcmUncyB1bmZvcnR1bmF0ZWx5
IHNvbWUgY29uZnVzaW9uIG92ZXIgd2hldGhlciBVVEYtOCBlbmNvZGVkCj4gZmlsZXMgc2hvdWxk
IGhhdmUgYSBCT00gLSBNU1ZDIGRvZXNuJ3QgcGFyc2UgdGhlbSBwcm9wZXJseSBpZiB0aGV5IGRv
bid0LAo+IGJ1dCBHQ0MgY2hva2VzIG9uIHRoZSBCT00uIEkgdGhpbmsgdGhpcyB3b3VsZCBoYXZl
IHRvIGJlIGVpdGhlciBzcGVjaWZpZWQgb3IKPiBoYW5kbGVkIGZsZXhpYmx5IGluIEQgZnJvbnQg
ZW5kcy4KClRoZSBEIHNwZWMgYWxyZWFkeSBkZWZpbmVzIGNvbXBpbGVyIGJlaGF2aW9yIGluIHJl
c3BlY3QgdG8gQk9NcyBvciB0aGUKbGFjayB0aGVyZW9mLgo=
Oct 22 2008
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Thomas Moran wrote:
 Since C++ permits unicode identifiers I actually did some experiments a 
 few months ago to see what the compiler support was like. The conclusion 
 was that only MSVC9 can deal with them, GCC4 and ICC10 (EDG I suppose) 
 both choked. You can actually call a variable "αβγ" in VC9 and the 
 program compiles. There's unfortunately some confusion over whether 
 UTF-8 encoded files should have a BOM - MSVC doesn't parse them properly 
 if they don't, but GCC chokes on the BOM. I think this would have to be 
 either specified or handled flexibly in D front ends.
It already is handled properly in D. Try it out!
Oct 23 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Thomas Moran wrote:
 Mathematicians have no 
 qualms about using 5 different alphabets and 10 kinds of brackets to 
 describe things, and there's no fundamental reason computer programs 
 should be any different, except for the fact that entering the symbols 
 is awkward.
Given the fact that most languages popular with mathematicians and physicists (Fortran, Matlab, APL) are little, if not scarcely, popular among the general software programming crowd, I would say having mathematicians ideas be the lead for language design is a bad ideia. Software engineering is much more than that. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 24 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
Some random thoughts:

I agree it would be cool to be able to write  a =D7 b and get a cross produ=
ct.

But it would be uncool if every Unicode operator meant adding new
special opFoo and opFooAssign methods.  So this is connected to the
operator overloading overhaul.

Also cross product is rather specialized.  In all of math the cross
product operator only has meaning for 2-d and 3-d vectors as far as I
know.   The dot is used a little more widely.

The ability to define new infix operators would be generally useful
quite apart from discussions of Unicode.
If I could say    A dot B and A cross B instead of dot(A,B) that would
already be quite cool.  Uh oh, here comes Downs!  [ducks]

The classic problem with new infix operators is defining precedence.
Without precedence you can't decide what
  A op1 B op2 C
is supposed to equal.
I think it was Ocaml or something allows you to declare new infix
operators with precedence based on other operators.  So with that you
can kind of create a "subclass" of the multiply operator, that has
similar precedence.  That seems elegant to me.

--bb

On Thu, Oct 23, 2008 at 8:57 AM, Moritz Warning <moritzwarning web.de> wrot=
e:
 Unicode operators would be nice addition to D.

 Since it's common to have opFooBar style operators overloads in D,
 I would like to rise the question what unicode operators do users need
 (most) or would like to have?

 opDotProduct and opCrossProduct would be definitely cool.
Oct 22 2008
next sibling parent Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
Bill Baxter Wrote:

 Some random thoughts:
 
 I agree it would be cool to be able to write  a × b and get a cross product.
 
 But it would be uncool if every Unicode operator meant adding new
 special opFoo and opFooAssign methods.  So this is connected to the
 operator overloading overhaul.
 
 Also cross product is rather specialized.  In all of math the cross
 product operator only has meaning for 2-d and 3-d vectors as far as I
 know.   The dot is used a little more widely.
 
 The ability to define new infix operators would be generally useful
 quite apart from discussions of Unicode.
 If I could say    A dot B and A cross B instead of dot(A,B) that would
 already be quite cool.  Uh oh, here comes Downs!  [ducks]
 
 The classic problem with new infix operators is defining precedence.
 Without precedence you can't decide what
   A op1 B op2 C
 is supposed to equal.
 I think it was Ocaml or something allows you to declare new infix
 operators with precedence based on other operators.  So with that you
 can kind of create a "subclass" of the multiply operator, that has
 similar precedence.  That seems elegant to me.
 
 --bb
 
 On Thu, Oct 23, 2008 at 8:57 AM, Moritz Warning <moritzwarning web.de> wrote:
 Unicode operators would be nice addition to D.

 Since it's common to have opFooBar style operators overloads in D,
 I would like to rise the question what unicode operators do users need
 (most) or would like to have?

 opDotProduct and opCrossProduct would be definitely cool.
The cross product, according to Wikipedia anyway, is also defined for 7-d vectors. (I did not know that. I'm not sure I know it now.) But the cross product generalizes to an 'exterior' or 'wedge' product, defined in spaces of any dimension. However it no longer uses an 'x' symbol but replaces it with a wedge-shaped symbol (looks like a Greek lambda). This is a useful symbol, in its place, but I can't imagine it being useful in computing applications short of the Mathematica level. Paul
Oct 22 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 I think it was Ocaml or something allows you to declare new infix
 operators with precedence based on other operators.  So with that you
 can kind of create a "subclass" of the multiply operator, that has
 similar precedence.  That seems elegant to me.
That goes against a design principle of D, that it must be parsable without semantic analysis.
Oct 23 2008
prev sibling parent reply "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
Agreed.

As an example: what domain does not include boolean expressions? And how 
many domains include vector and matrix operations? Quite many.

It would be a massive boost for readability in those domains (and in all 
domains, with boolean expressions).

The problem is not the operators themselves; a language does not loose 
anything by extension, it is how exactly to best arrive at the goal of 
having the code look nice and readable with those operators.

- Bent

Hm, anyone fancy the |> operator?


"Moritz Warning" <moritzwarning web.de> skrev i meddelelsen 
news:gdoekc$1f5o$4 digitalmars.com...
 Unicode operators would be nice addition to D.

 Since it's common to have opFooBar style operators overloads in D,
 I would like to rise the question what unicode operators do users need
 (most) or would like to have?

 opDotProduct and opCrossProduct would be definitely cool. 
Oct 26 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Oct 27, 2008 at 10:16 AM, Bent Rasmussen
<IncredibleShrinkingSphere gmail.com> wrote:
 Agreed.

 As an example: what domain does not include boolean expressions? And how
 many domains include vector and matrix operations? Quite many.
 It would be a massive boost for readability in those domains (and in all
 domains, with boolean expressions).
I don't know about you, but to me 'and' and 'or' make for much more readable boolean expressions than the standard mathematical symbols ^ and v. Heck, && and || are more readable to me than the math symbols.
 The problem is not the operators themselves; a language does not loose
 anything by extension, it is how exactly to best arrive at the goal of
 having the code look nice and readable with those operators.

 - Bent

 Hm, anyone fancy the |> operator?
What would that mean? --bb
Oct 26 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Mon, Oct 27, 2008 at 10:16 AM, Bent Rasmussen
 <IncredibleShrinkingSphere gmail.com> wrote:
 Agreed.

 As an example: what domain does not include boolean expressions? And how
 many domains include vector and matrix operations? Quite many.
 It would be a massive boost for readability in those domains (and in all
 domains, with boolean expressions).
I don't know about you, but to me 'and' and 'or' make for much more readable boolean expressions than the standard mathematical symbols ^ and v. Heck, && and || are more readable to me than the math symbols.
Hm, in my experimental emacs shenanigans I had && displayed as a wedge and || displayed as a vee and heck do they look good.
 The problem is not the operators themselves; a language does not loose
 anything by extension, it is how exactly to best arrive at the goal of
 having the code look nice and readable with those operators.

 - Bent

 Hm, anyone fancy the |> operator?
What would that mean?
Ironic smile with eyes closed. Andrei
Oct 26 2008
next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Oct 27, 2008 at 11:46 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Mon, Oct 27, 2008 at 10:16 AM, Bent Rasmussen
 <IncredibleShrinkingSphere gmail.com> wrote:
 Agreed.

 As an example: what domain does not include boolean expressions? And how
 many domains include vector and matrix operations? Quite many.
 It would be a massive boost for readability in those domains (and in all
 domains, with boolean expressions).
I don't know about you, but to me 'and' and 'or' make for much more readable boolean expressions than the standard mathematical symbols ^ and v. Heck, && and || are more readable to me than the math symbols.
Hm, in my experimental emacs shenanigans I had && displayed as a wedge and || displayed as a vee and heck do they look good.
Hmm. I guess it's just because I've spent a lot more time looking at the C operators than the math ones. --bb
Oct 26 2008
prev sibling next sibling parent reply "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
Not quite

http://blogs.msdn.com/dsyme/archive/2008/09/01/the-f-operators-and-basic-functions.aspx

|> is pipelining
 is function composition
- Bent "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> skrev i meddelelsen news:ge3a2o$2i0k$2 digitalmars.com...
 Bill Baxter wrote:
 On Mon, Oct 27, 2008 at 10:16 AM, Bent Rasmussen
 <IncredibleShrinkingSphere gmail.com> wrote:
 Agreed.

 As an example: what domain does not include boolean expressions? And how
 many domains include vector and matrix operations? Quite many.
 It would be a massive boost for readability in those domains (and in all
 domains, with boolean expressions).
I don't know about you, but to me 'and' and 'or' make for much more readable boolean expressions than the standard mathematical symbols ^ and v. Heck, && and || are more readable to me than the math symbols.
Hm, in my experimental emacs shenanigans I had && displayed as a wedge and || displayed as a vee and heck do they look good.
 The problem is not the operators themselves; a language does not loose
 anything by extension, it is how exactly to best arrive at the goal of
 having the code look nice and readable with those operators.

 - Bent

 Hm, anyone fancy the |> operator?
What would that mean?
Ironic smile with eyes closed. Andrei
Oct 26 2008
next sibling parent KennyTM~ <kennytm gmail.com> writes:
Bent Rasmussen wrote:
 Not quite
 
 http://blogs.msdn.com/dsyme/archive/2008/09/01/the-f-operators-and-
asic-functions.aspx 
 
 
 |> is pipelining
 is function composition
- Bent "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> skrev i meddelelsen news:ge3a2o$2i0k$2 digitalmars.com...
 Bill Baxter wrote:
 On Mon, Oct 27, 2008 at 10:16 AM, Bent Rasmussen
 <IncredibleShrinkingSphere gmail.com> wrote:
 Agreed.

 As an example: what domain does not include boolean expressions? And 
 how
 many domains include vector and matrix operations? Quite many.
 It would be a massive boost for readability in those domains (and in 
 all
 domains, with boolean expressions).
I don't know about you, but to me 'and' and 'or' make for much more readable boolean expressions than the standard mathematical symbols ^ and v. Heck, && and || are more readable to me than the math symbols.
Hm, in my experimental emacs shenanigans I had && displayed as a wedge and || displayed as a vee and heck do they look good.
 The problem is not the operators themselves; a language does not loose
 anything by extension, it is how exactly to best arrive at the goal of
 having the code look nice and readable with those operators.

 - Bent

 Hm, anyone fancy the |> operator?
What would that mean?
Ironic smile with eyes closed. Andrei
I thought |> is a ket vector in quantum mechanics. <ϕ|A|ψ> := ∫ ϕ(x)* A ψ(x) dx
Oct 26 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Bent Rasmussen wrote:
 http://blogs.msdn.com/dsyme/archive/2008/09/01/the-f-operators-and-
asic-functions.aspx 
 
 
 |> is pipelining
 is function composition
So what's the difference? That is to say, what would tolower(trim(str)) translate to?
Oct 26 2008
parent reply "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> skrev i meddelelsen 
news:ge3mit$i33$1 digitalmars.com...
 So what's the difference? That is to say, what would tolower(trim(str)) 
 translate to?
It would translate to something like val x = str |> trim |> tolower; So it looks like a pipeline. And to construct such a function, you'd define it as val f = trim >> tolower; val x = str |> f; - Bent
Oct 27 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bent Rasmussen wrote:
 "Robert Fraser" <fraserofthenight gmail.com> skrev i meddelelsen 
 news:ge3mit$i33$1 digitalmars.com...
 So what's the difference? That is to say, what would 
 tolower(trim(str)) translate to?
It would translate to something like val x = str |> trim |> tolower; So it looks like a pipeline. And to construct such a function, you'd define it as val f = trim >> tolower; val x = str |> f;
BTW, incidentally std.functional defines both operators in prefix form: auto x = pipe!(trim, tolower)(str); or auto x = compose!(tolower, trim)(str); Andrei
Oct 27 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:
 I don't know about you, but to me 'and' and 'or' make for much more
 readable boolean expressions than the standard mathematical symbols ^
 and v.  Heck, && and || are more readable to me than the math symbols.
Hm, in my experimental emacs shenanigans I had && displayed as a wedge and || displayed as a vee and heck do they look good.
I'm sure it has to do with what you're used to looking at. I forget which one is which (heck, I was forgetting which was which even when I was taking a logic class). However, & for "and" has a precedent in natural language. | for "or" is a bit out there, but at least it looks significantly different than &, which cannot be said about ^/v.
Oct 26 2008
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser escribió:
 Andrei Alexandrescu wrote:
 I don't know about you, but to me 'and' and 'or' make for much more
 readable boolean expressions than the standard mathematical symbols ^
 and v.  Heck, && and || are more readable to me than the math symbols.
Hm, in my experimental emacs shenanigans I had && displayed as a wedge and || displayed as a vee and heck do they look good.
I'm sure it has to do with what you're used to looking at. I forget which one is which (heck, I was forgetting which was which even when I was taking a logic class). However, & for "and" has a precedent in natural language. | for "or" is a bit out there, but at least it looks significantly different than &, which cannot be said about ^/v.
You can remember those symbols by remembering that U is Union, and "inverted U" is intersection. Now U points to the same place as v, and "inverted U" points to the same place as ^, and "union/or", "intersection/and" are similar concepts.
Oct 27 2008
prev sibling parent "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
This is a matter of taste and habbit, but my preference is

(A1) ¬(p ʌ q)

(A2) not (p and q)

(A3) !(p && q)

Eiffel also uses (A2) and it looks much better than (A3).

Still, in my oppinion your preference is still better than the status quo. 
Also, consider

(B1) p ≠ (d ≤ q)

Relational operators also look much better and look more homogeneous and 
consistent with logical operators in (A1).

- Bent

"Bill Baxter" <wbaxter gmail.com> skrev i meddelelsen 
news:mailman.289.1225071455.3087.digitalmars-d puremagic.com...
 On Mon, Oct 27, 2008 at 10:16 AM, Bent Rasmussen
 <IncredibleShrinkingSphere gmail.com> wrote:
 Agreed.

 As an example: what domain does not include boolean expressions? And how
 many domains include vector and matrix operations? Quite many.
 It would be a massive boost for readability in those domains (and in all
 domains, with boolean expressions).
I don't know about you, but to me 'and' and 'or' make for much more readable boolean expressions than the standard mathematical symbols ^ and v. Heck, && and || are more readable to me than the math symbols.
 The problem is not the operators themselves; a language does not loose
 anything by extension, it is how exactly to best arrive at the goal of
 having the code look nice and readable with those operators.

 - Bent

 Hm, anyone fancy the |> operator?
What would that mean? --bb
Oct 26 2008