lambdak: multi-line lambda implementation in native Python

[Rustom Mody]

On Friday, January 16, 2015 at 9:46:30 AM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:
> 
> > Let there be a hundred different versions, then people will
> > begin to clamor against the non-necessity of the penury-of-ASCII:
> > 
> > http://blog.languager.org/2015/01/unicode-and-universe.html
> 
> Almost 30 years ago, Apple's Hypertalk language allowed, and encouraged, the
> use of certain non-ASCII symbols. You could use ≤ ≥ and ≠ for
> less-or-equal, greater-or-equal, and not-equal comparisons; you could use ÷
> for division; and you could define a square root function using √ as the
> name. You could even define ∞ = 'INF' and do floating point operations on
> it.

Good stuff!

> 
> Apple could get away with this back in the 80s because they controlled the
> platform including keyboard mappings, and they could guarantee that key
> combinations such as Option-/ would generate the ÷ character and that any
> reasonable font would include a glyph for it.

APL went much further, 60 years ago.  And IBM could get away with it
for similar monopolistic reasons

> 
> Alas and alack, 30 years on and we have to live with the down-side of
> multicultural computers. Any modern Linux system is almost sure to be fully
> Unicode compatible with a UTF-8 filesystem -- *almost* sure. But we have to
> interoperate with Windows machines still stuck in the Dark Ages of "code
> pages"; Java that insists that Unicode == UTF-16 (and support for the
> supplementary multilingual planes is weak); there is a plethora of fonts
> but Unicode support is extremely variable; many of us are using US
> keyboards and there's no well-known or standard input method for Unicode
> characters; and while Apple only had to support somewhat fewer than 256
> characters, Unicode has tens of thousands.

No direct experience but my impression is that windows is almost as
unicode-compliant as linux:

http://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/dd374081%28v=vs.85%29.aspx

Yeah SMP support may be problematic. Anyways...
1. BMP alone is a 256-fold expansion over ASCII
2. SMP support all round is spotty. MySQL?? Blogger is messing my posts etc
3. For almost all the cases we're talking of BMP is enough and to spare

> 
> Before Unicode can take off for programming syntax, we need to solve at
> least four problems:
> 
> - we have to be confident that moving source code from one 
>   machine to another (Windows -> Linux or visa versa) won't
>   corrupt the file. That means UTF-8 everywhere.

Ok

> - we need a good selection of decent programmer's fonts with 
>   extensive support for Unicode especially mathematical symbols;

I guess so

> 
> - we need a platform-independent input method that will allow 
>   programmers to enter these symbols without moving their hands 
>   off the keyboard;

I dont see why.  I use laptops and desktops having different layouts.
Fumble a bit but not too much.
Others probably use much more way out devices eg android phones.

Likewise I dont see why input-methods need to match/be platform independent. As long as they work.

eg Some cars have European controls – wiper on left, lights on right.
Or American – the other way round.
When changing I fumble a bit but not so much its an issue

> 
> - and some way to make the existence of these symbols easily 
>   discoverable, e.g. for most of us, ~ is easily discoverable 
>   because we can see it on the keyboard, but the same doesn't
>   apply for ≈

I believe this is the nub of the matter.

Discoverability of 1 million characters is a very different matter from
discoverability of a few hundred.

eg 

1. Beginning programmers do search-and-peck typing – they need to
discover the US-104 (or whatever) keyboard
2. Beginning vi-users need to find the controls of the dragon with two modes
— one in which it beeps and one in which it corrupts the file
3. Beginning python programmers need to discover the difference
between typing at the command-prompt at the REPL and into a file… and
a dozen other things before python begins to look barely friendly

In the same way typing a ≤ ≥ ≠ on a stock keyboard may require some
learning/acclimatization/setup.

- Using a suitable editor mode it needs to be exactly the same as the ASCII
"<=", ">=", "!=" 
- With compose key setup its just a character more – the above preceded
by the compose key [right-win, ALtGr, Menu, whatever]

> 
> 
> I live in hope, but I am not confident that these issues will be solved in
> my lifetime. One of the ten most popular programming languages, PHP,
> doesn't even support Unicode even as a data type. What hope do we have?

Using, canvassing, clamoring, bugging (with bug-reports) is our toolset :-)