Quantcast

More unicode alternatives for ASCII operators?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

More unicode alternatives for ASCII operators?

toolbear74

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

Tony Morris
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
> <http://old.nabble.com/Aliasing-%3C%3D-method-to-%E2%89%A4-%28%5Cu2264%29-for-all-Ordered-T--ts26951441.html>
> 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?
> <http://old.nabble.com/More-unicode-alternatives-for-ASCII-operators--tp26974335p26974335.html>
> Sent from the Scala - Debate mailing list archive
> <http://old.nabble.com/Scala---Debate-f30218.html> at Nabble.com.

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

toolbear74
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

Tony Morris
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.
>  

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

John Nilsson
In reply to this post by toolbear74
On Thu, Dec 31, 2009 at 2:36 AM, toolbear74 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

Jörg W Mittag-2
In reply to this post by Tony Morris
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] <http://EmacsWiki.Org/PrettyLambda/>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

toolbear74
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

Ray Racine
In reply to this post by toolbear74
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

√iktor Ҡlang

Perhaps one could experiment with precedence specced with annotations?

On Dec 31, 2009 3:13 PM, "Ray Racine" <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

Daniel Sobral
In reply to this post by toolbear74
=> 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

Kevin Wright-4
+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 <[hidden email]>
=> 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 <[hidden email]> 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: [hidden email]
wave: [hidden email]
skype: kev.lee.wright
twitter: @thecoda

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

Jason Zaugg
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
<[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

Rex Kerr-2

On Thu, Dec 31, 2009 at 11:22 AM, Jason Zaugg <[hidden email]> 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
 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

Tony Morris
In reply to this post by Daniel Sobral
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 <[hidden email]
> <mailto:[hidden email]>> 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/


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

√iktor Ҡlang


On Thu, Dec 31, 2009 at 10:32 PM, Tony Morris <[hidden email]> 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 <[hidden email]
> <mailto:[hidden email]>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

Naftoli Gugenheim
In reply to this post by toolbear74
So much for global warming...

-------------------------------------
Viktor Klang<[hidden email]> wrote:

On Thu, Dec 31, 2009 at 10:32 PM, Tony Morris <[hidden email]> 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 <[hidden email]
> > <mailto:[hidden email]>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More unicode alternatives for ASCII operators?

Dimitris Andreou
In reply to this post by Tony Morris
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 <[hidden email]>:

> 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 <[hidden email]
>> <mailto:[hidden email]>> 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/
>
>
>
Loading...