Re: Adding Unicode operators to D [use cases]

[Don]

Andrei Alexandrescu wrote:

Sergey Gromov wrote:

Don wrote:

If you could completely ignore keyboard and display issues, and use any
unicode character as an operator, which ones would you actually use?


I'd use dot ⋅ and cross × products for 3D, union ∪ and
intersection ∩, subset ⊂ and superset ⊃ and their negative forms.
 I don't think I'd use anything else.

Well, comparisons look better when converted into appropriate unicode.


In my opinion, a workable feature is this:

* Functions can be defined with a leading backspace. They will be usable 
with the infix notation.


* There is a way of specifying that precedence of a function defined as 
above is the same as precedence of a built-in operator.


Do we really need to do that? How many Unicode binary operators are there?

This list of symbols which work in web browsers is very short.
http://en.wikipedia.org/wiki/Wikipedia:Mathematical_symbols

The interesting thing about this second list is just how short it is, 
and how many of the items in it are comparison operators.
Any of the unicode comparison operators could be given the same 
precedence as , and 'in'.

Cross should be given the same precedence as opMul and opDiv.
That just leaves oplus, otimes, which probably the same precedence as 
plus and mul.


You can do the same thing with this list:
http://en.wikipedia.org/wiki/Unicode_Mathematical_Operators
And you find that the precedence of almost everything is easy to 
determine. Seems like 90% of them are relational operators.


Specifying the precedence of each unicode operator (eg by a lookup 
table) would be adequate for any use case I can imagine, and it wouldn't 
make syntactic analysis any more ambiguous.


* Functions of which name is the same as an HTML entity name for a 
symbol can be replaced with the actual symbol.

Re: Adding Unicode operators to D [use cases]

[Walter Bright]

Andrei Alexandrescu wrote:
* There is a way of specifying that precedence of a function defined as 
above is the same as precedence of a built-in operator.


That throws out the ability to parse without semantic analysis. It's not 
worth it.

Re: Adding Unicode operators to D [use cases]

[Andrei Alexandrescu]

Walter Bright wrote:

Andrei Alexandrescu wrote:
* There is a way of specifying that precedence of a function defined 
as above is the same as precedence of a built-in operator.


That throws out the ability to parse without semantic analysis. It's not 
worth it.


It doesn't per a previous post of mine, but I agree it's still not worth it.

Andrei

Re: Adding Unicode operators to D [use cases]

[Sergey Gromov]

Don wrote:
 If you could completely ignore keyboard and display issues, and use any
 unicode character as an operator, which ones would you actually use?

I'd use dot ⋅ and cross × products for 3D, union ∪ and
intersection ∩, subset ⊂ and superset ⊃ and their negative forms.
 I don't think I'd use anything else.

Well, comparisons look better when converted into appropriate unicode.

Re: Adding Unicode operators to D [use cases]

[bearophile]

Sergey Gromov:
 I'd use dot ⋅ and cross × products for 3D, union ∪ and
 intersection ∩, subset ⊂ and superset ⊃ and their negative forms.
  I don't think I'd use anything else.

I just want to note that the whole thread is almost unreadable on the 
digitalmars.com/webnews/, because it doesn't digest unicode chars at all. So 
adding unicode to D will give problems to show code.

Unrelated to the unicode, but related on those opSubset, opSuperset, etc:
while implementing a set() class with the same API of the Python sets, I have 
seen there are the following operators/methods too:

issubset(other) 
set = other 
Test whether every element in the set is in other.

set  other 
Test whether the set is a true subset of other, that is, set = other and set 
!= other.

issuperset(other) 
set = other 
Test whether every element in other is in the set.

set  other 
Test whether the set is a true superset of other, that is, set = other and set 
!= other.

A full opCmp can't be defined on sets, so I think in D1 we can't overload = = 
among sets... I think this is a problem has to be solved in D2, because sets 
are important enough.

Bye,
bearophile

Re: Adding Unicode operators to D [use cases]

[Bill Baxter]

On Wed, Oct 29, 2008 at 4:12 AM, Andrei Alexandrescu
[EMAIL PROTECTED] wrote:
 Sergey Gromov wrote:

 Don wrote:

 If you could completely ignore keyboard and display issues, and use any
 unicode character as an operator, which ones would you actually use?

 I'd use dot ⋅ and cross × products for 3D, union ∪ and
 intersection ∩, subset ⊂ and superset ⊃ and their negative forms.
  I don't think I'd use anything else.

 Well, comparisons look better when converted into appropriate unicode.

 In my opinion, a workable feature is this:

 * Functions can be defined with a leading backspace. They will be usable
 with the infix notation.

Did you mean backslash?  I hope you're not suggesting we write
^HinfixOperator. :-)

 * There is a way of specifying that precedence of a function defined as
 above is the same as precedence of a built-in operator.

Workable, but it ain't what Walter calls parsing.

 * Functions of which name is the same as an HTML entity name for a symbol
 can be replaced with the actual symbol.

--bb