Operator overloading in D is straightforward and sensible.

I think there is an opportunity for D to do better with some very small changes.

I propose including additional Unicode mathematical symbols as recognized operators for opBinary. All that would be required is to extend the lexer to recognize the symbols as binary operators.

For example, in vector arithmetic there are two different products defined -- the dot product and the cross product. Most implementations I've seen overload '*' for the inner product, but omit operator for the cross product. In UTF-8 the "middle dot", ('•', \u00B7) and "multiplication sign", ('×', \u00D7), correspond to the more usual mathematical notation for the dot and cross products, respectively.

UTF-16 has many more mathematical symbols, particularly on the 2200-22FF and 2A00-2AFF code pages. \u2207 is a wedge, commonly used for outer products. The circled plus (u\2A01) and circled times sign (\2A02) are defined for some mathematical operations. \u2A33 is the "smash product" symbol, which I've never heard of before but it sounds cool.

I am NOT suggesting that we include ALL these mathematical symbols as operators. If it was up to me I'd include just the middle dot, the cross product and the wedge product, but YMMV.

These new operators would need a precedence. Since most of these are product operators the precedence should be the same as '*' or "/".

Pros:
1. Extends the capability to define mathematical operators for user-defined types
2. Shouldn't break any existing code since the symbols aren't valid chars in identifiers (as far as I can tell) and aren't being used elsewhere.
3. Takes advantage of the existing opBinary overloading so implementation should be straightforward.

Cons:
1. They are hard to type or otherwise enter in to a text file.
2. They may not display correctly in some output forms.
3. They could be confusing to someone unfamiliar with the concept.

With regard to the difficulty of entering or displaying these characters, I think that is largely because modern computer languages only give lip service to Unicode -- code is almost exclusively written in ASCII. I have seen one instance where a certain mathematical constant was named 'π', but the author was an iconoclast and pariah.

Paul D. Anderson:

> I am NOT suggesting that we include ALL these mathematical symbols as operators. If it was up to me I'd include just the middle dot, the cross product and the wedge product, but YMMV.

If you want to introduce new standard operators, I suggest to keep their number very low. And I suggest to avoid Unicode symbols.

The operators I find useful for me are one more product operator, a max infix operator and a min infix operator.

Maybe #* #max #min? (Also usable with a "=" prefix, #=* #=max #=min).

Bye,
bearophile

On 03/01/2013 01:51 PM, Paul D. Anderson wrote:

> In UTF-8 the "middle dot", ('•', \u00B7) and
> "multiplication sign", ('×', \u00D7)

[...]

> UTF-16 has many more mathematical symbols

Sorry to pick on this unrelated issue but UTF-8 and UTF-16 are just Unicode encodings. Unicode itself defines all of those characters and they can all be represented in any encoding.

Ali

On Friday, 1 March 2013 at 22:09:15 UTC, Ali Çehreli wrote:
> On 03/01/2013 01:51 PM, Paul D. Anderson wrote:
>
> > In UTF-8 the "middle dot", ('•', \u00B7) and
> > "multiplication sign", ('×', \u00D7)
>
> [...]
>
> > UTF-16 has many more mathematical symbols
>
> Sorry to pick on this unrelated issue but UTF-8 and UTF-16 are just Unicode encodings. Unicode itself defines all of those characters and they can all be represented in any encoding.
>
> Ali

Yes, you are correct.

On Friday, 1 March 2013 at 21:52:00 UTC, Paul D. Anderson wrote:
> Operator overloading in D is straightforward and sensible.
>
> I think there is an opportunity for D to do better with some very small changes.
>
> I propose including additional Unicode mathematical symbols as recognized operators for opBinary. All that would be required is to extend the lexer to recognize the symbols as binary operators.
>
> For example, in vector arithmetic there are two different products defined -- the dot product and the cross product. Most implementations I've seen overload '*' for the inner product, but omit operator for the cross product. In UTF-8 the "middle dot", ('•', \u00B7) and "multiplication sign", ('×', \u00D7), correspond to the more usual mathematical notation for the dot and cross products, respectively.
>
> UTF-16 has many more mathematical symbols, particularly on the 2200-22FF and 2A00-2AFF code pages. \u2207 is a wedge, commonly used for outer products. The circled plus (u\2A01) and circled times sign (\2A02) are defined for some mathematical operations. \u2A33 is the "smash product" symbol, which I've never heard of before but it sounds cool.

> Pros:
> 1. Extends the capability to define mathematical operators for user-defined types
> 2. Shouldn't break any existing code since the symbols aren't valid chars in identifiers (as far as I can tell) and aren't being used elsewhere.
> 3. Takes advantage of the existing opBinary overloading so implementation should be straightforward.
>
> Cons:
> 1. They are hard to type or otherwise enter in to a text file.
> 2. They may not display correctly in some output forms.
> 3. They could be confusing to someone unfamiliar with the concept.

 In windows (x86, could include dos & linux?) you can hold down the alt key and manually type in the value of the character; But it seems to truncated to 8 bits so Alt+321 = 65 which is A, so likely unless you're copy/pasting the symbols it probably won't work.

>
> With regard to the difficulty of entering or displaying these characters, I think that is largely because modern computer languages only give lip service to Unicode -- code is almost exclusively written in ASCII. I have seen one instance where a certain mathematical constant was named '?', but the author was an iconoclast and pariah.

 Those operators seem more useful for scientific math. I wouldn't want them added to to the core language though.

 ASCII can be typed with (almost) any keyboard and use any editor (new or old); You can still read source code if outputted to a dumb terminal rather than getting odd symbols (whitespace as well) and may be tearing your hair out wondering what this UTF-8 symbol is or what it means.

On 2013-03-01 23:56, Era Scarecrow wrote:
>   Those operators seem more useful for scientific math. I wouldn't want them
> added to to the core language though.
>
>   ASCII can be typed with (almost) any keyboard and use any editor (new or old);
> You can still read source code if outputted to a dumb terminal rather than
> getting odd symbols (whitespace as well) and may be tearing your hair out
> wondering what this UTF-8 symbol is or what it means.

Gotta grab that old APL keyboard from the attic...

On Friday, 1 March 2013 at 22:56:27 UTC, Era Scarecrow wrote:
>
>  Those operators seem more useful for scientific math. I wouldn't want them added to to the core language though.
>

I agree that they are not going to be used by most programmers. This is true for a lot of Phobos, which is sensible because modules can be imported or not, as need be.

My bottom line is the need to define at least one more product operator. I only propose adding it to the core language because I can't find a way to make it happen in a library. I am open to suggestions.

> Maybe #* #max #min? (Also usable with a "=" prefix, #=* #=max #=min).

Sorry, I meant postfix:

#*= #max= #min=

So instead of:

foo = min(foo, bar);
foo = foo.min(bar);

You write:

foo #min= bar;

(This syntax is generalizable to any diadic function. But I don't think D has to go there.)


An alternative syntax:

@* @max @min @*= @max= @min=

Another alternative syntax for the second multiplication operator:

auto M3 = M1 ^* M2;

Having all future D scientific libraries use the same nice and clean standard operator has some advantages.

Bye,
bearophile

On Friday, 1 March 2013 at 23:29:43 UTC, Paul D. Anderson wrote:
>
> My bottom line is the need to define at least one more product operator. I only propose adding it to the core language because I can't find a way to make it happen in a library. I am open to suggestions.

 I'd say a DSL for the scientific library would be best, likely as a mixin, then the text could be processed and use it's own rules and replace symbols with function calls?

  //can mix regular operations and utf extras
  a = scientificCalc!"(s * 4) × 4"(s);      //possible call formats?
  mixin(scientificCalc("a = (s * 4) × 4"));

On Sat, Mar 02, 2013 at 01:31:19AM +0100, Era Scarecrow wrote:
> On Friday, 1 March 2013 at 23:29:43 UTC, Paul D. Anderson wrote:
> >
> >My bottom line is the need to define at least one more product operator. I only propose adding it to the core language because I can't find a way to make it happen in a library. I am open to suggestions.
> 
>  I'd say a DSL for the scientific library would be best, likely as a
> mixin, then the text could be processed and use it's own rules and
> replace symbols with function calls?
> 
>   //can mix regular operations and utf extras
>   a = scientificCalc!"(s * 4) × 4"(s);      //possible call formats?
>   mixin(scientificCalc("a = (s * 4) × 4"));

+1. With D's compile-time capabilities, DSLs give you arbitrarily complex custom syntax at essentially zero runtime cost. You can even implement compile-time DSL optimizers that produce optimized code like no overloaded operator ever can.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??