Jump to page: 1 2
Thread overview
Unicode operators
Oct 22, 2008
Moritz Warning
Oct 23, 2008
Thomas Moran
Oct 24, 2008
Walter Bright
Oct 24, 2008
Bruno Medeiros
Oct 23, 2008
Bill Baxter
Re: Unicode operators (OT)
Oct 23, 2008
Paul D. Anderson
Oct 24, 2008
Walter Bright
Oct 27, 2008
Bent Rasmussen
Oct 27, 2008
Bill Baxter
Oct 27, 2008
Bill Baxter
Oct 27, 2008
Bent Rasmussen
Oct 27, 2008
KennyTM~
Oct 27, 2008
Robert Fraser
Oct 27, 2008
Bent Rasmussen
Oct 27, 2008
Robert Fraser
Oct 27, 2008
Ary Borenszweig
Oct 27, 2008
Bent Rasmussen
October 22, 2008
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.
October 23, 2008
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.
October 23, 2008
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.
>
October 23, 2008
On Wed, Oct 22, 2008 at 9:01 PM, Thomas Moran <no@spam.plx> 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.

The D spec already defines compiler behavior in respect to BOMs or the lack thereof.

October 23, 2008
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


October 24, 2008
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!
October 24, 2008
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.
October 24, 2008
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
October 27, 2008
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. 

October 27, 2008
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
« First   ‹ Prev
1 2