Digraphs *and* Unicode pretty-glyphs, for arrows, triangle, etc.
A few others relevant to EcmaScript:
=== ⩶ != ≠ !== ≢ ... … ! ¬
- × / ÷ Infinity ∞ sqrt √ cbrt ∛ PI π Intl 🌐 // requires better fonts (www.fileformat.info/info/unicode/char/1f310)
Besides typing, legibility is critical: ⇒, ≥, ≤ are clearly improvements over their ASCII counterparts, but ≠ and ≢ are too hard to tell apart.
Norbert
Yeah, I'd like them. I just thought it is no point suggesting.
Norbert Lindenberg wrote:
A few others relevant to EcmaScript:
=== ⩶
Why not ≡ (to match !==). It has also better meaning.
!= ≠ !== ≢ ... … ! ¬
- × / ÷
Yes! I'd like to see the last two (not is nice, too), to split it from other meanings of / and *.
&& ∧ || ∨ in ∈
== ≈ !== ≉
(and just for fun: for ∀ if ∃ though I think that the first would work :-) )
Infinity ∞ sqrt √ cbrt ∛ PI π Intl 🌐 // requires better fonts (www.fileformat.info/info/unicode/char/1f310)
Besides typing, legibility is critical: ⇒, ≥, ≤ are clearly improvements over their ASCII counterparts, but ≠ and ≢ are too hard to tell apart.
I think there should be not ≠ (!== is anyway not very good to use, one should favor !===) only ≡ and ≢ for === and !===.
Norbert
On Apr 4, 2012, at 22:23 , Brendan Eich wrote:
From www.scala-lang.org/node/4723 (hat tip Corey Farwell@frewsxcvtwitter.com/#!/frewsxcv
):
=> ⇒ // implemented <- ← // implemented -> → // implemented == ⩵
≫ << ≪
⋙
For these three I am concerned with meaning... it should be neither "French quotes" nor "much greater/lesser than".
On Thu, Apr 5, 2012 at 7:23 AM, Brendan Eich <brendan at mozilla.org> wrote:
From www.scala-lang.org/node/4723 (hat tip Corey Farwell@frewsxcv twitter.com/#!/frewsxcv
*
):
|=> ⇒ // implemented <- ← // implemented -> → // implemented == ⩵
≫
<< ≪
⋙
= ≥
<= ≤ :: ∷|
Corey suggested editors could do the input conversion when users type the digraph. If Scala can go here, why not JS?
↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵
Thaddee Tyl wrote:
On Thu, Apr 5, 2012 at 7:23 AM, Brendan Eich<brendan at mozilla.org> wrote:
From www.scala-lang.org/node/4723 (hat tip Corey Farwell@frewsxcvtwitter.com/#!/frewsxcv
):
|=> ⇒ // implemented <- ← // implemented -> → // implemented == ⩵
≫ << ≪
⋙ = ≥ <= ≤ :: ∷|
Corey suggested editors could do the input conversion when users type the digraph. If Scala can go here, why not JS?
↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵
Hey, it's not that bad.
Here's nodejs's lib/path.js log, math and rel replaced: gist.github.com/2310485/53ca798220d5d6f28fb4c15035c974b2db1d81d1
IMO it is more readable. You see the distinction between == and === better (see the first function -- you see the first if is ≈ (not exactly equal) while the second is ≡ (strictly equal)).
And those nots, ors and ends in math notation are sweet. Much better, for me.
Herby
P.S.: Here's the funny one with for and if replaced as well: gist.github.com/2310485/bc2cb70e411e5ecf0f2e45e78558ff16b2b0be45
On Wed, 4 Apr 2012 23:54:54 -0700, Norbert Lindenberg <ecmascript at norbertlindenberg.com> wrote:
Besides typing, legibility is critical: â, â¥, ⤠are clearly improvements over their ASCII counterparts, but â and ⢠are too hard to tell apart.
I use a monospace font when programming, like many people. Those characters are so small at my prefered font sizes for me to be comfortable using it or seeing it in code, I'd always translate back to the "normal" notation.
On Wed, 04 Apr 2012 22:23:54 -0700, Brendan Eich <brendan at mozilla.org> wrote:
Corey suggested editors could do the input conversion when users type the digraph. If Scala can go here, why not JS?
Why introduce an entirely functionless, useless syntactical non-semantic change to the language when preprocessors could fill that role? If we're going to do this we might as well add in a generic feature to allow any identifier to stand in for any other operator.
Only-half-kidding'ly yours, Corey Richardson
I don't see anything inherently wrong with adding some nice sugar to ES, because the people who will be using this "math heavy" notation will be those who are used to it. The "everyday" ecmascript programmer probably won't touch these because they might add extra work for them. Plus, it'd be nice to be able to read math in ES (for us math oriented folk).
On Apr 4, 2012, at 10:23 PM, Brendan Eich wrote:
From www.scala-lang.org/node/4723 (hat tip Corey Farwell@frewsxcv twitter.com/#!/frewsxcv
):
|=> ⇒ // implemented <- ← // implemented -> → // implemented == ⩵
≫ << ≪
⋙ = ≥ <= ≤ :: ∷|
Corey suggested editors could do the input conversion when users type the digraph. If Scala can go here, why not JS?
I'm glad to see everybody getting on the bandwagon esdiscuss/2012-March/020908 ;-)
On Thu, Apr 5, 2012 at 11:00 AM, Adam Shannon <adam at ashannon.us> wrote:
I don't see anything inherently wrong with adding some nice sugar to ES, because the people who will be using this "math heavy" notation will be those who are used to it. The "everyday" ecmascript programmer probably won't touch these because they might add extra work for them. Plus, it'd be nice to be able to read math in ES (for us math oriented folk).
So what about people editing code written by others? Will they have to run the source through some transformation tool to get the ASCII operators back?
On Thu, Apr 5, 2012 at 5:00 PM, Adam Shannon <adam at ashannon.us> wrote:
I don't see anything inherently wrong with adding some nice sugar to ES, because the people who will be using this "math heavy" notation will be those who are used to it. The "everyday" ecmascript programmer probably won't touch these because they might add extra work for them. Plus, it'd be nice to be able to read math in ES (for us math oriented folk).
Leksah leksah.org is a Haskell IDE whose editor converts ->
and other operators to their unicode equivalent. It saves the file in ascii.
If you want that feature in the editor, do it. On the other hand, there is no reason to make programming JS harder for people with a weaker editor.
Good point - this prettification may be better handled as a rendering option in editors than in the language. As a rendering feature, it can be tailored to the reader's preferences, font availability, and screen resolution, all of which may differ between people looking at the same piece of source code.
The way Leksah implements its "source candy" seems broken though, as the warning in the manual indicates: "Leksah reads and writes files encoded in UTF-8. So you can edit Unicode Haskell source files. When you want to do this, switch off source candy, because otherwise Unicode characters may be converted to ASCII when saving the file." Source candy should be implemented as part of rendering, just like source coloring, which doesn't introduce or remove any tags into/from the source.
Norbert
On Thu, 5 Apr 2012 10:00:56 -0500, Adam Shannon <adam at ashannon.us> wrote:
I don't see anything inherently wrong with adding some nice sugar to ES, because the people who will be using this "math heavy" notation will be those who are used to it. The "everyday" ecmascript programmer probably won't touch these because they might add extra work for them. Plus, it'd be nice to be able to read math in ES (for us math oriented folk).
You don't see anything wrong with making the spec larger, implementation harder, adding more to learn, more for a decent text editor to support, and more burden on everyone who doesn't want to use those fancy unicode thingers?
As mentioned elsewhere on the list, it's best as a display option in a text editor, not as a language feature. It doesn't even introduce minification benefits since the number of bytes in any of those fancy symbols encoded to utf8 is >= the equivalent number of 'regular' operators.
Bikeshedding'ly yours, Corey Richardson
On 4/4/12 at 23:54, ecmascript at norbertlindenberg.com (Norbert Lindenberg) wrote:
Besides typing, legibility is critical: ⇒, ≥, ≤ are clearly improvements over their ASCII counterparts, but ≠ and ≢ are too hard to tell apart.
One thing that concerns me with using the extended Unicode set is that I will need to shift to a larger font size to make out the extended characters. I don't know whether that will result in more or less of the program text in a fixed size window, but if it is less, then having those characters in the source will not improve program readability.
Cheers - Bill
Bill Frantz |"After all, if the conventional wisdom was working, the 408-356-8506 | rate of systems being compromised would be going down, www.periwinkle.com | wouldn't it?" -- Marcus Ranum
On 5 April 2012 17:35, Thaddee Tyl <thaddee.tyl at gmail.com> wrote:
On Thu, Apr 5, 2012 at 5:00 PM, Adam Shannon <adam at ashannon.us> wrote:
I don't see anything inherently wrong with adding some nice sugar to ES, because the people who will be using this "math heavy" notation will be those who are used to it. The "everyday" ecmascript programmer probably won't touch these because they might add extra work for them. Plus, it'd be nice to be able to read math in ES (for us math oriented folk).
Leksah leksah.org is a Haskell IDE whose editor converts -> and other operators to their unicode equivalent. It saves the file in ascii.
Indeed, this is standard practice for almost all functional languages. For example, even old-school Emacs modes for Haskell, OCaml, Agda, Coq, etc are all capable of rendering underlying ASCII with nice math characters, and have been for ages.
No need to burden the language with multiple representations. Algol 68 tried and failed :).
2012/4/10 Andreas Rossberg <rossberg at google.com>:
On 5 April 2012 17:35, Thaddee Tyl <thaddee.tyl at gmail.com> wrote:
On Thu, Apr 5, 2012 at 5:00 PM, Adam Shannon <adam at ashannon.us> wrote:
I don't see anything inherently wrong with adding some nice sugar to ES, because the people who will be using this "math heavy" notation will be those who are used to it. The "everyday" ecmascript programmer probably won't touch these because they might add extra work for them. Plus, it'd be nice to be able to read math in ES (for us math oriented folk).
Leksah leksah.org is a Haskell IDE whose editor converts -> and other operators to their unicode equivalent. It saves the file in ascii.
Indeed, this is standard practice for almost all functional languages. For example, even old-school Emacs modes for Haskell, OCaml, Agda, Coq, etc are all capable of rendering underlying ASCII with nice math characters, and have been for ages.
No need to burden the language with multiple representations. Algol 68 tried and failed :).
I think Unicode support has come a long way since then.
On Apr 10, 2012, at 3:16 AM, Erik Corry wrote:
2012/4/10 Andreas Rossberg <rossberg at google.com>:
...
No need to burden the language with multiple representations. Algol 68 tried and failed :).
I think Unicode support has come a long way since then.
PL/I tried it and succeeded. It its early days (only a couple years before Algol 68) it had to exist in a world where 026 card punches still existed. 026's didn't support many useful characters such as >, < , [, ], etc. So PL/I had digraphs for use on legacy input devices and pretty-glyphs for use with "modern" input devices. Over-time the digraphs faded from use.
Something similar happened with FORTRAN. Prior to FORTRAN 90 you had to say .LT. instead of < but now it supports a full suite of Ascii operators in addition to the original 026-based character sequences.
2012/4/10 Andreas Rossberg <rossberg at google.com>:
On 5 April 2012 17:35, Thaddee Tyl <thaddee.tyl at gmail.com> wrote:
On Thu, Apr 5, 2012 at 5:00 PM, Adam Shannon <adam at ashannon.us> wrote:
I don't see anything inherently wrong with adding some nice sugar to ES, because the people who will be using this "math heavy" notation will be those who are used to it. The "everyday" ecmascript programmer probably won't touch these because they might add extra work for them. Plus, it'd be nice to be able to read math in ES (for us math oriented folk).
Leksah leksah.org is a Haskell IDE whose editor converts -> and other operators to their unicode equivalent. It saves the file in ascii.
Indeed, this is standard practice for almost all functional languages. For example, even old-school Emacs modes for Haskell, OCaml, Agda, Coq, etc are all capable of rendering underlying ASCII with nice math characters, and have been for ages.
There are lots of apps that display JS source. For example the web based code review tool, the terminal output from 'svn blame' or the pages produced by the svn-www source browsing gateway. There are services like gist or mailing lists like this one. All of these are capable of displaying Unicode characters with no problems these days, but it would be too much to ask for all of them to autoconvert =>into =>.
Note that I said they could all display Unicode, but it is not necessarily easy to input Unicode characters, so the ASCII version still has to work.
I have to say I don't like this idea (at this time). Gmail autoconverting out of Unicode is another signal that Unicode support just isn't there yet.
My preferred terminal (urxvt) has Unicode support, but it's an exception rather than a rule; that terminal even has Unicode in its name. I've worked with a lot of terminals that didn't support Unicode, in fact even my VPS doesn't support Unicode over SSH, and when I'm traveling, I often code over SSH on that server. My Twitter client doesn't (properly) support Unicode. My keyboard has no glyphs in it.
Unicode will come there, but I don't think now is the time to put something like this in the language. If a code viewer does syntax highlighting, it's a piece of cake to display glyphs instead of operators, and that's as far as language support should go for now. This would have implications on minifiers, code parsers, pretty much everything, and the gain is very small; it's hardly easier to input glyphs, and it's easily harder to read them (I'm referring to the poor support).
Please, feel sorry for the poor chaps who have to debug code that shows as blocks on their editors. :) I'm asking if this is something we actually need enough for it to be worth it that some code becomes illegible to some people?
Agreed, we're not ready to support Unicode operators in-language, yet (as you say, the time may come).
I raised this mostly to cite the Scala thinking. Thanks for all the responses. It seems better to have editors blaze the trail for now.
From www.scala-lang.org/node/4723 (hat tip Corey Farwell @frewsxcv)
):
Corey suggested editors could do the input conversion when users type the digraph. If Scala can go here, why not JS?