More unicode alternatives for ASCII operators?

Unfortunately Scala does not allow user-defined operator precedence. I
don't see a way of working around this, do you?

toolbear74 wrote:
>
> I was pleased to see unicode alternatives built into the language:
>
> The Unicode operators \u21D2 |⇒| and \u2190 |←|, which have the
> ASCII equivalents |=>| and |<-|, are also reserved.
>
> Soon after using them I wondered why limit it to so few? Why doesn't
> Scala have unicode alternatives for all the ASCII operators that are
> obvious approximations of real symbols?
>
> I thought I discovered the answer. Operator overloading plus the
> pimp-my-library pattern allows you to define them yourself. I tried
> this myself
>
> and also learned that Scalaz adds many unicode alternatives. But these
> are less than complete, namely in terms of operator precedence.
>
> The following table shows operators that are obvious ASCII
> approximations (e.g. they are effectively ASCII art renderings of real
> symbols):
>
> |=> ⇒ // implemented
> <- ← // implemented
> -> → // implemented
> == ⩵
> >> ≫
> << ≪
> >>> ⋙
> >= ≥
> <= ≤
> :: ∷
> |
>
> The following are more debatable. The ASCII characters aren't
> graphical approximations, but instead are idiomatic equivalents to
> their mathematical symobols:
>
> |* × multiplication // this one's probably an ASCII approximation
> / ÷ division
> ! ¬ logical negation
> ^ ⊕ exclusive or
> != ≠ not equal
> |
>
> Are |⇒| and |←| the first wave of more unicode alternatives such as
> the above? Or would a patch implementing the above equivalents be
> rejected on principle?
>
> Cheers,
> Tim
>
>
> ------------------------------------------------------------------------
> View this message in context: More unicode alternatives for ASCII
> operators?
>
> Sent from the Scala - Debate mailing list archive
> at Nabble.com.

Tony Morris-4 wrote:
>
> Unfortunately Scala does not allow user-defined operator precedence. I
> don't see a way of working around this, do you?
>

Correct. I see no work around. My question isn't about patching Scalaz, but
about patching Scala.

You mean, allowing user-defined precedence into the language?

toolbear74 wrote:
> Tony Morris-4 wrote:
>
>> Unfortunately Scala does not allow user-defined operator precedence. I
>> don't see a way of working around this, do you?
>>
>>
>
> Correct. I see no work around. My question isn't about patching Scalaz, but
> about patching Scala.
>

On Thu, Dec 31, 2009 at 2:36 AM, toolbear74 <nabble [at] tool-man [dot] org> wrote:

Why doesn't Scala have unicode alternatives for all the ASCII operators that are obvious approximations of real symbols?

Actually, why stop at simple unicode alternatives. Wouldn't it be nice if we could have more elaborate rendering alternatives? Subscripts, superscripts, tables and so forth.
I wonder how how one could represent a fold with more syntactic freedom.
In either case, what I'm getting at is that maybe operations shouldn't have different names in the actual namespace, but rather just have different renderings. Instead of
 def /:[B](z: B)(op: (B, A) => B): B = foldLeft(z)(op)
Maybe it should be part of foldLefts definition that it can be represented by /: or even some more elaborate rendering.
Take a look at some fortress example to see what it might look like: http://projectfortress.sun.com/Projects/Community/wiki/FortressByExample
BR,John

Tony Morris wrote:
> toolbear74 wrote:
>> Tony Morris wrote:
>>> Unfortunately Scala does not allow user-defined operator precedence. I
>>> don't see a way of working around this, do you?
>> Correct. I see no work around. My question isn't about patching Scalaz, but
>> about patching Scala.
> You mean, allowing user-defined precedence into the language?

I understood Tim's suggestion to either mean

* hardwire the Unicode operators into the grammar as simple aliases
for their ASCII counterparts (basically creating the exact same
tokens / AST nodes) or
* leave them as user-definable operators (as they are now) but add
them to the precedence table at the same level as their ASCII
counterparts.

I can also see a third (possibly intermediate) solution: a
pretty-printer similar to Emacs' pretty-lambda[1] which leaves the
source files as-is, but displays the operators pretty-printed in IDEs,
text editors, source listings, slides and so on.

The ultimate solution would of course be user-defined precedence or
even greater syntactic freedom. But then again, Scala is neither
Fortress nor Perl6 nor Ioke nor Lisp.

jwm

[1]

My post is part suggestion, part question.

The question: why did Scala stop at implementing just some unicode
equivalents? Would adding more equivalents (with proper precedence, etc.) be
a welcome addition if implemented well?

The suggestion: support more unicode operators, particularly when the ASCII
operator is a clear approximation of a symbol available in unicode.
Implementation should hold to the principle of least astonishment, so as has
already been suggested, the unicode operator should have the same precedence
as its ASCII equivalent. I'm not married to the exact mappings I proposed,
though I'm particularly fond of ×, ÷, ≤, ≥, ¬, ⊕ and ≠.

@Tony, not necessarily user-definable precedence. More below.

@Jörg, changing the precedence table is what I was thinking. An
implementation that maximizes acceptance is what I would shoot for.
User-definable precedence seems the least practical and most invasive;
unless there is already an intention to add that to Scala.

@John, I stop at simple unicode alternatives because it is simple. Source
code isn't rich text. Linking my suggestion to an implementation that would
require rich text source code would be an excellent way to ensure it was
never implemented or accepted any time soon ;)

- Tim

Emacs does this at the editor/syntax level.  Any regexp pattern matching group of characters can be mapped to  char/symbol etc..
In the editor I see the unicode character/symbol/arrow but the compiler sees the normal ascii sequence unadulterated.  I loved this in scheme days long ago.  "define" was lower case "delta" etc.  I pretty much redefined scheme into an APL like alphabet of single character key works.
For Scala I have been experimenting with ending all class, traits, objects with either the capital Greek letter XI, DELTA or PHI.  This is inspired from the same symbols used to decorate schema's in the Zed specification language.  By simply glancing at the symbol ending the name I know if a class is a mutates internal state or honors immutable semantics by copy on modification for example.
Ray


On Wed, Dec 30, 2009 at 8:36 PM, toolbear74 <nabble [at] tool-man [dot] org> wrote:

I was pleased to see unicode alternatives built into the language:

The Unicode operators \u21D2 ⇒ and \u2190 ←, which have the ASCII equivalents => and <-, are also reserved.

Soon after using them I wondered why limit it to so few? Why doesn't Scala have unicode alternatives for all the ASCII operators that are obvious approximations of real symbols?

I thought I discovered the answer. Operator overloading plus the pimp-my-library pattern allows you to define them yourself. I tried this myself and also learned that Scalaz adds many unicode alternatives. But these are less than complete, namely in terms of operator precedence.

The following table shows operators that are obvious ASCII approximations (e.g. they are effectively ASCII art renderings of real symbols):

=>  ⇒   // implemented
<-  ←   // implemented
->  →   // implemented
==  ⩵
>>  ≫
<<  ≪
>>> ⋙
>=  ≥
<=  ≤
::  ∷

The following are more debatable. The ASCII characters aren't graphical approximations, but instead are idiomatic equivalents to their mathematical symobols:

*   ×   multiplication  // this one's probably an ASCII approximation
/   ÷   division
!   ¬   logical negation
^   ⊕   exclusive or
!=  ≠   not equal

Are ⇒ and ← the first wave of more unicode alternatives such as the above? Or would a patch implementing the above equivalents be rejected on principle?

Cheers,
Tim

View this message in context: More unicode alternatives for ASCII operators?
Sent from the Scala - Debate mailing list archive at Nabble.com.

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius

Perhaps one could experiment with precedence specced with annotations?

On Dec 31, 2009 3:13 PM, "Ray Racine" <ray [dot] racine [at] gmail [dot] com> wrote:

Emacs does this at the editor/syntax level.  Any regexp pattern matching group of characters can be mapped to  char/symbol etc..
In the editor I see the unicode character/symbol/arrow but the compiler sees the normal ascii sequence unadulterated.  I loved this in scheme days long ago.  "define" was lower case "delta" etc.  I pretty much redefined scheme into an APL like alphabet of single character key works.
For Scala I have been experimenting with ending all class, traits, objects with either the capital Greek letter XI, DELTA or PHI.  This is inspired from the same symbols used to decorate schema's in the Zed specification language.  By simply glancing at the symbol ending the name I know if a class is a mutates internal state or honors immutable semantics by copy on modification for example.
Ray

On Wed, Dec 30, 2009 at 8:36 PM, toolbear74 <nabble [at] tool-man [dot] org> wrote: > > I was pleased to see ...

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius

=> and <- are keywords, none of the others are keywords. The others are library-defined.

It would have a lot of merit to have unicode equivalents to mathematical and logical operators have proper precedence. 
That might include new precedence priorities, such as exponentiation. It might even include right-associativity for something other than colon-terminated operators, though that would certainly be a tougher pill.
Once precedence is available, then compiler-support ceases to be an issue.
So, Tony, Tim... why don't you come up with a revised table of precedence including unicode characters? I think such an enhancement proposal would be relatively easy to pass, and I, myself, would fully endorse it.
On Wed, Dec 30, 2009 at 11:36 PM, toolbear74 <nabble [at] tool-man [dot] org> wrote:
>
> I was pleased to see unicode alternatives built into the language:
>
> The Unicode operators \u21D2 ⇒ and \u2190 ←, which have the ASCII equivalents => and <-, are also reserved.
>
> Soon after using them I wondered why limit it to so few? Why doesn't Scala have unicode alternatives for all the ASCII operators that are obvious approximations of real symbols?
>
> I thought I discovered the answer. Operator overloading plus the pimp-my-library pattern allows you to define them yourself. I tried this myself and also learned that Scalaz adds many unicode alternatives. But these are less than complete, namely in terms of operator precedence.
>
> The following table shows operators that are obvious ASCII approximations (e.g. they are effectively ASCII art renderings of real symbols):
>
> =>  ⇒   // implemented
> <-  ←   // implemented
> ->  →   // implemented
> ==  ⩵
> >>  ≫
> <<  ≪
> >>> ⋙
> >=  ≥
> <=  ≤
> ::  ∷
>
> The following are more debatable. The ASCII characters aren't graphical approximations, but instead are idiomatic equivalents to their mathematical symobols:
>
> *   ×   multiplication  // this one's probably an ASCII approximation
> /   ÷   division
> !   ¬   logical negation
> ^   ⊕   exclusive or
> !=  ≠   not equal
>
> Are ⇒ and ← the first wave of more unicode alternatives such as the above? Or would a patch implementing the above equivalents be rejected on principle?
>
> Cheers,
> Tim
>
> ________________________________
> View this message in context: More unicode alternatives for ASCII operators?
> Sent from the Scala - Debate mailing list archive at Nabble.com.



--
Daniel C. Sobral

I travel to the future all the time.

+1
I don't think we have any precedents here with existing projects needing existing unicode precedence rules.
Scalaz may suffer briefly, but it also stands to gain the most from firmly establishing such rules before they'll risk breaking a much larger established codebase.


2009/12/31 Daniel Sobral <dcsobral [at] gmail [dot] com>

=> and <- are keywords, none of the others are keywords. The others are library-defined.

It would have a lot of merit to have unicode equivalents to mathematical and logical operators have proper precedence. 
That might include new precedence priorities, such as exponentiation. It might even include right-associativity for something other than colon-terminated operators, though that would certainly be a tougher pill.
Once precedence is available, then compiler-support ceases to be an issue.
So, Tony, Tim... why don't you come up with a revised table of precedence including unicode characters? I think such an enhancement proposal would be relatively easy to pass, and I, myself, would fully endorse it.
On Wed, Dec 30, 2009 at 11:36 PM, toolbear74 <nabble [at] tool-man [dot] org> wrote:
>
> I was pleased to see unicode alternatives built into the language:
>
> The Unicode operators \u21D2 ⇒ and \u2190 ←, which have the ASCII equivalents => and <-, are also reserved.
>
> Soon after using them I wondered why limit it to so few? Why doesn't Scala have unicode alternatives for all the ASCII operators that are obvious approximations of real symbols?
>
> I thought I discovered the answer. Operator overloading plus the pimp-my-library pattern allows you to define them yourself. I tried this myself and also learned that Scalaz adds many unicode alternatives. But these are less than complete, namely in terms of operator precedence.
>
> The following table shows operators that are obvious ASCII approximations (e.g. they are effectively ASCII art renderings of real symbols):
>
> =>  ⇒   // implemented
> <-  ←   // implemented
> ->  →   // implemented
> ==  ⩵
> >>  ≫
> <<  ≪
> >>> ⋙
> >=  ≥
> <=  ≤
> ::  ∷
>
> The following are more debatable. The ASCII characters aren't graphical approximations, but instead are idiomatic equivalents to their mathematical symobols:
>
> *   ×   multiplication  // this one's probably an ASCII approximation
> /   ÷   division
> !   ¬   logical negation
> ^   ⊕   exclusive or
> !=  ≠   not equal
>
> Are ⇒ and ← the first wave of more unicode alternatives such as the above? Or would a patch implementing the above equivalents be rejected on principle?
>
> Cheers,
> Tim
>
> ________________________________
> View this message in context: More unicode alternatives for ASCII operators?
> Sent from the Scala - Debate mailing list archive at Nabble.com.



--
Daniel C. Sobral

I travel to the future all the time.

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

There are two possible changes. I'm pretty sure you're proposing the first only.

1. Adjusting the precedence and fixity rules to allow the unicode
alternatives to associate in the same manner as there ASCII
fore-fathers.
2. Adding synonyms through the core types and standard libraries, e.g. Any.≠

Scalaz would benefit moderately from #1 and would suffer heavily from #2.

From the original list, I suggest to remove ⋙ and to add ≟

I'm not sure you could do a general enough job with the boolean
operators based on the first character.

For example, if you assigned precedences:
¬ <==> !
∨ <==> ||

You would have surprising precedence for:

a ¬∨ b ∨ c // gives: a ¬∨ (b ∨ c)

-jason

http://unicode.org/charts/PDF/U2200.pdf

-jason

On Thu, Dec 31, 2009 at 4:27 PM, Kevin Wright
wrote:
> +1
> I don't think we have any precedents here with existing projects needing
> existing unicode precedence rules.
> Scalaz may suffer briefly, but it also stands to gain the most from firmly
> establishing such rules before they'll risk breaking a much larger
> established codebase.

On Thu, Dec 31, 2009 at 11:22 AM, Jason Zaugg <jzaugg [at] gmail [dot] com> wrote:

For example, if you assigned precedences:
¬   <==> !
∨  <==> ||

You would have surprising precedence for:

a ¬∨ b ∨ c  // gives: a ¬∨ (b ∨ c)

I thought the down-arrow was standard logic notation for nor.  Surely you can find *some* standard notation that doesn't glue the two operators together.  You'd have the same problem with !||.

  --Rex
 

I'd simply allow user-defined precedence and not just for unicode
identifiers.

Daniel Sobral wrote:
> => and <- are keywords, none of the others are keywords. The others
> are library-defined.
>
> It would have a lot of merit to have unicode equivalents to
> mathematical and logical operators have /proper precedence/.
>
> That might include new precedence priorities, such as exponentiation.
> It might even include right-associativity for something other than
> colon-terminated operators, though that would certainly be a tougher pill.
>
> Once precedence is available, then compiler-support ceases to be an issue.
>
> So, Tony, Tim... why don't you come up with a revised table of
> precedence including unicode characters? I think such an enhancement
> proposal would be relatively easy to pass, and I, myself, would fully
> endorse it.
>
> On Wed, Dec 30, 2009 at 11:36 PM, toolbear74 > wrote:
> >
> > I was pleased to see unicode alternatives built into the language:
> >
> > The Unicode operators \u21D2 ⇒ and \u2190 ←, which have the ASCII
> equivalents => and <-, are also reserved.
> >
> > Soon after using them I wondered why limit it to so few? Why doesn't
> Scala have unicode alternatives for all the ASCII operators that are
> obvious approximations of real symbols?
> >
> > I thought I discovered the answer. Operator overloading plus the
> pimp-my-library pattern allows you to define them yourself. I tried
> this myself and also learned that Scalaz adds many unicode
> alternatives. But these are less than complete, namely in terms of
> operator precedence.
> >
> > The following table shows operators that are obvious ASCII
> approximations (e.g. they are effectively ASCII art renderings of real
> symbols):
> >
> > => ⇒ // implemented
> > <- ← // implemented
> > -> → // implemented
> > == ⩵
> > >> ≫
> > << ≪
> > >>> ⋙
> > >= ≥
> > <= ≤
> > :: ∷
> >
> > The following are more debatable. The ASCII characters aren't
> graphical approximations, but instead are idiomatic equivalents to
> their mathematical symobols:
> >
> > * × multiplication // this one's probably an ASCII approximation
> > / ÷ division
> > ! ¬ logical negation
> > ^ ⊕ exclusive or
> > != ≠ not equal
> >
> > Are ⇒ and ← the first wave of more unicode alternatives such as the
> above? Or would a patch implementing the above equivalents be rejected
> on principle?
> >
> > Cheers,
> > Tim
> >
> > ________________________________
> > View this message in context: More unicode alternatives for ASCII
> operators?
> > Sent from the Scala - Debate mailing list archive at Nabble.com.
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.

On Thu, Dec 31, 2009 at 10:32 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:

I'd simply allow user-defined precedence and not just for unicode
identifiers.

*GASP*
You're agreeing with me...
Hell just froze! :-D
 

Daniel Sobral wrote:
> => and <- are keywords, none of the others are keywords. The others
> are library-defined.
>
> It would have a lot of merit to have unicode equivalents to
> mathematical and logical operators have /proper precedence/.
>
> That might include new precedence priorities, such as exponentiation.
> It might even include right-associativity for something other than
> colon-terminated operators, though that would certainly be a tougher pill.
>
> Once precedence is available, then compiler-support ceases to be an issue.
>
> So, Tony, Tim... why don't you come up with a revised table of
> precedence including unicode characters? I think such an enhancement
> proposal would be relatively easy to pass, and I, myself, would fully
> endorse it.
>
> On Wed, Dec 30, 2009 at 11:36 PM, toolbear74 <nabble [at] tool-man [dot] org
> <mailto:nabble [at] tool-man [dot] org>> wrote:
> >
> > I was pleased to see unicode alternatives built into the language:
> >
> > The Unicode operators \u21D2 ⇒ and \u2190 ←, which have the ASCII
> equivalents => and <-, are also reserved.
> >
> > Soon after using them I wondered why limit it to so few? Why doesn't
> Scala have unicode alternatives for all the ASCII operators that are
> obvious approximations of real symbols?
> >
> > I thought I discovered the answer. Operator overloading plus the
> pimp-my-library pattern allows you to define them yourself. I tried
> this myself and also learned that Scalaz adds many unicode
> alternatives. But these are less than complete, namely in terms of
> operator precedence.
> >
> > The following table shows operators that are obvious ASCII
> approximations (e.g. they are effectively ASCII art renderings of real
> symbols):
> >
> > =>  ⇒   // implemented
> > <-  ←   // implemented
> > ->  →   // implemented
> > ==  ⩵
> > >>  ≫
> > <<  ≪
> > >>> ⋙
> > >=  ≥
> > <=  ≤
> > ::  ∷
> >
> > The following are more debatable. The ASCII characters aren't
> graphical approximations, but instead are idiomatic equivalents to
> their mathematical symobols:
> >
> > *   ×   multiplication  // this one's probably an ASCII approximation
> > /   ÷   division
> > !   ¬   logical negation
> > ^   ⊕   exclusive or
> > !=  ≠   not equal
> >
> > Are ⇒ and ← the first wave of more unicode alternatives such as the
> above? Or would a patch implementing the above equivalents be rejected
> on principle?
> >
> > Cheers,
> > Tim
> >
> > ________________________________
> > View this message in context: More unicode alternatives for ASCII
> operators?
> > Sent from the Scala - Debate mailing list archive at Nabble.com.
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.

--
Tony Morris
http://tmorris.net/

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

Great idea!! We could also have an import statement that puts in scope
the required precedence rules, just in case 2 libraries define
conflicting rules:

import _precedence_.foo.GoodRules
import _precedence_.bar.{BadRules => _}

2009/12/31 Tony Morris :
> I'd simply allow user-defined precedence and not just for unicode
> identifiers.
>
> Daniel Sobral wrote:
>> => and <- are keywords, none of the others are keywords. The others
>> are library-defined.
>>
>> It would have a lot of merit to have unicode equivalents to
>> mathematical and logical operators have /proper precedence/.
>>
>> That might include new precedence priorities, such as exponentiation.
>> It might even include right-associativity for something other than
>> colon-terminated operators, though that would certainly be a tougher pill.
>>
>> Once precedence is available, then compiler-support ceases to be an issue.
>>
>> So, Tony, Tim... why don't you come up with a revised table of
>> precedence including unicode characters? I think such an enhancement
>> proposal would be relatively easy to pass, and I, myself, would fully
>> endorse it.
>>
>> On Wed, Dec 30, 2009 at 11:36 PM, toolbear74 > > wrote:
>> >
>> > I was pleased to see unicode alternatives built into the language:
>> >
>> > The Unicode operators \u21D2 ⇒ and \u2190 ←, which have the ASCII
>> equivalents => and <-, are also reserved.
>> >
>> > Soon after using them I wondered why limit it to so few? Why doesn't
>> Scala have unicode alternatives for all the ASCII operators that are
>> obvious approximations of real symbols?
>> >
>> > I thought I discovered the answer. Operator overloading plus the
>> pimp-my-library pattern allows you to define them yourself. I tried
>> this myself and also learned that Scalaz adds many unicode
>> alternatives. But these are less than complete, namely in terms of
>> operator precedence.
>> >
>> > The following table shows operators that are obvious ASCII
>> approximations (e.g. they are effectively ASCII art renderings of real
>> symbols):
>> >
>> > =>  ⇒   // implemented
>> > <-  ←   // implemented
>> > ->  →   // implemented
>> > ==  ⩵
>> > >>  ≫
>> > <<  ≪
>> > >>> ⋙
>> > >=  ≥
>> > <=  ≤
>> > ::  ∷
>> >
>> > The following are more debatable. The ASCII characters aren't
>> graphical approximations, but instead are idiomatic equivalents to
>> their mathematical symobols:
>> >
>> > *   ×   multiplication  // this one's probably an ASCII approximation
>> > /   ÷   division
>> > !   ¬   logical negation
>> > ^   ⊕   exclusive or
>> > !=  ≠   not equal
>> >
>> > Are ⇒ and ← the first wave of more unicode alternatives such as the
>> above? Or would a patch implementing the above equivalents be rejected
>> on principle?
>> >
>> > Cheers,
>> > Tim
>> >
>> > ________________________________
>> > View this message in context: More unicode alternatives for ASCII
>> operators?
>> > Sent from the Scala - Debate mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>