the meaning of r.......ïŸ
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Mon Jul 23 11:49:25 EDT 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