Skip to content
This repository has been archived by the owner. It is now read-only.

Unicode keywords #33

Closed
paulmillr opened this issue Dec 3, 2011 · 18 comments

Comments

@paulmillr
Copy link
Contributor

commented Dec 3, 2011

Scala / Haskell support unicode keywords as an alternative to default ones.

\ λ
<-
->
=>

What do you think about this idea?

@puffnfresh

This comment has been minimized.

Copy link
Owner

commented Dec 3, 2011

I love this idea. Having Unicode support for built-in syntax would be awesome.

What to do about non-built-in syntax like in #16 might be a later issue.

@piranha

This comment has been minimized.

Copy link
Collaborator

commented Dec 3, 2011

Well, I believe that introducing too many syntax constructs will make language noisy. Also it will introduce wars for coding style and decrease consistency. ;-) I.e. I believe Python philosophy should be followed - 'There should be one-- and preferably only one --obvious way to do it.'

@paulmillr

This comment has been minimized.

Copy link
Contributor Author

commented Dec 3, 2011

Also it will introduce wars for coding style and decrease consistency

Nope, as we may see in haskell's / scala's example.

These are not additional constructs, they're just aliases

@paulmillr paulmillr closed this Dec 3, 2011

@piranha

This comment has been minimized.

Copy link
Collaborator

commented Dec 3, 2011

These are not additional constructs, they're just aliases

That's what I'm talking about. TIMTOWTDI. Perl, Ruby and to some extent CoffeeScript suffer from it.

@piranha

This comment has been minimized.

Copy link
Collaborator

commented Dec 3, 2011

Also, good editors make it possible to show unicode symbols instead of language constructs in case you want some prettiness.

@paulmillr

This comment has been minimized.

Copy link
Contributor Author

commented Dec 3, 2011

Also, good editors make it possible to show unicode symbols instead of language constructs in case you want some prettiness.

Noone would see this prettiness except me then.

I think that Roy should follow the way of functional programming languages like scala & haskell instead of pythonic imperative one. Personally, I don't think there's should be only one way to do it, but definitely language shouldn't have 5 ways of doing the same thing etc (perl).

Scala also has nice community-drived coding style guide. And, as I saw, scala code is very consistent.

@piranha

This comment has been minimized.

Copy link
Collaborator

commented Dec 3, 2011

Noone would see this prettiness except me then.

It's not like this prettiness will make something easier. It's not easier to read, not easier to write, and someone without configured keybindings will send you patches with ->, inconsistent with your pretty codebase with . This will be a pain point.

I think that Roy should follow the way of functional programming languages like scala & haskell instead of pythonic imperative one.

I'm not sure I follow how is consistency bound to functional/imperative styles? Let's say roy should follow the way of functional programming languages like lisp instead of perl imperative one, would this better explain my opinion?

@puffnfresh puffnfresh reopened this Dec 3, 2011

@michaelficarra

This comment has been minimized.

Copy link

commented Dec 3, 2011

related coffeescript discussion: jashkenas/coffeescript#1679

@puffnfresh

This comment has been minimized.

Copy link
Owner

commented Dec 4, 2011

Just wanted to say that I completely see both sides here.

It might increase inconsistency but hopefully a good style guide will eventually arise to mitigate that.

@esehara

This comment has been minimized.

Copy link
Collaborator

commented Dec 5, 2011

I vote for "be able not to Unicode operator as default syntax".

I like this idea,but I do not want Unicode Operator to be contained in default syntax.

Because I think that it becomes a cause by which a code becomes complicated. the core syntax should be kept simple.(and I love The Zen of Python "There should be one way to do it." ;) ).

Instead, I propose enabling it to use Unicode Operator as a standard module.

example:

import UnicodeOperator
@paulmillr

This comment has been minimized.

Copy link
Contributor Author

commented Dec 5, 2011

It's "complicated" only because programmers don't have a simple way to write those symbols. So this is a problem of tools, not language. And, IMO, this problem can be solved easily. All we need is an emacs mode & vim plugin (textmate bundle with support of symbols exists already).

@piranha

This comment has been minimized.

Copy link
Collaborator

commented Dec 5, 2011

It's complicated because:

  1. you've got alternative syntax for language;
  2. you won't be able to fix something with your phone or dumb terminal;
  3. isn't that enough?

It may be pretty, but it's arguably complicates language. Is Haskell or Scala simple (rhetorical question)?

@paulmillr

This comment has been minimized.

Copy link
Contributor Author

commented Dec 5, 2011

you won't be able to fix something with your phone or dumb terminal;

I am able to fix something because it's an alternative syntax, not only.

UPD:
Scala isn't complicated, it's clever.

@alvivi

This comment has been minimized.

Copy link
Collaborator

commented Dec 5, 2011

I'd prefer to follow the rule "only one way to do things...". In Haskell we got unicode symbols, but almost nobody use them (they have more uses in Literate Haskell, for pedagogical uses). If Roy provides unicode symbols the users will have option of use them, but the "entropy" of the language will be a little higher. Seems a matter of taste, and IMHO, not a high priority feature.

@paulmillr

This comment has been minimized.

Copy link
Contributor Author

commented Dec 5, 2011

Here's a simple script that replaces all the things :octocat::

sed -e "s/\\\/λ/g;s/<-/←/g;s/->/→/g;s/=>/⇒/g"

echo 'let a = \\a -> \\b -> \\c -> do return d <- e' \
  | sed -e "s/\\\/λ/g;s/<-/←/g;s/->/→/g;s/=>/⇒/g"
let a = λa → λb → λc → do return d ← e

I've implemented it as a command in TextMate / Sublime2 (⇧⌘P).

@esehara

This comment has been minimized.

Copy link
Collaborator

commented Dec 5, 2011

The number of character codes is not one. There are Shift-jis,EUC-JP,ISO-2022-JP in Japan.
In fact, if "←" as not Unicode is inputted, an error "Couldn't tokenize" will occur.

It seems in me that there is no character code agreement in Roy,
because I think it excessive to use a multi-byte's operator(Unicode Operator) as default syntax.
and I want not to recommend only Unicode.

@paulmillr

This comment has been minimized.

Copy link
Contributor Author

commented Dec 5, 2011

There are Shift-jis,EUC-JP,ISO-2022-JP in Japan.

Yep, there's many encodings, but Unicode is only one we need in our case, it's 2011 at all. For example, I use TextMate. It doesn't support anything but unicode. What should I do when I see source code in some strange foreign encoding? Node.js doesn't support anything but unicode & ascii. Javascript itself is a unicode thing.

I'm very glad that we are in the "unicode future", where most websites use one universal encoding.

Just to note: Scala's very popular libraries, like Akka & Scalaz use this arrows, see example.

@piranha

This comment has been minimized.

Copy link
Collaborator

commented Dec 6, 2011

Unicode is not an encoding. UTF-8, UTF-16 and UTF-32 are encodings.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
6 participants
You can’t perform that action at this time.