the meaning of r.......ïŸ

Steven D'Aprano steve+comp.lang.python at pearwood.info
Mon Jul 23 17:49:25 CEST 2012


On Mon, 23 Jul 2012 08:55:22 -0400, Roy Smith wrote:

> Some day, we're going to have programming languages that take advantage
> of the full unicode character set.

I don't know about the full Unicode character set, since there are many 
more than 10000 characters, and few languages require that many distinct 
tokens.

But if you mean a richer character set than mere ASCII, then I agree, 
provided if by "some day" you mean nearly half a century ago.

http://en.wikipedia.org/wiki/APL_%28programming_language%29

Sort an array by the length of the word:

X[⍋X+.≠' ';]

compared to Python:

words.sort(key=len)

I think that's a clear example of why APL has never quite taken the world 
by storm. It makes Perl look like human-readable pseudo-code.

It isn't necessary to go to APL's extremes to get the power of a richer 
character set. Back in the 1990s, Apple's Hypertalk language allowed 
single character synonyms for certain operators, including:

≠ for <>
≤ for <=
≥ for >=
÷ for /
√ for sqrt


See OpenXION for a modern, non-GUI version:

http://www.openxion.org/


Unicode includes a very rich set of operator characters. Assuming the 
character input problem were solved, it would be awesome to be able to 
define a rich set of operators beyond the few Python already has. For 
example, we could use proper ∩ and ∪ operators for set intersection and 
union, or use chevrons «» as delimiters for types without clashing with 
lists [], tuples(), sets and dicts {}.

And wouldn't you rather see something like "string␊␍" instead of 
"string\n\r"? I know I would.

Of course, the character input problem *is* a genuine problem. Between 
that and the issue of character display (not all fonts are capable of 
showing all characters) I wouldn't hold my breath for full Unicode syntax 
any time soon.



-- 
Steven



More information about the Python-list mailing list