Re: Invoking a function from a list of functions

Re: Invoking a function from a list of functions

[Rusi]

Stefan and Yuri have pointed you to the search terms “higher order” and “first class” functions.  The wider umbrella term is functional programming (FP).
Unfortunately this has become a cult with more malarkey than stuff of late especially after increasing mainstreaming of the FP language Haskell.
IOW there is the irony: from 50 to 25 years ago when FP was academic arcana, the ideas were more accessible than today when the direction invariably tilts towards Haskell: which is somewhat like using a missile to kill a fly.
Me: After having tried many options for teaching programming, Ive personally returned to gofer http://blog.languager.org/2014/09/pugofer.html which is a tiny early Haskell dialect, better for pedagogic purposes than the current behemoth: Some reasons: https://stackoverflow.com/questions/25855507/are-typeclasses-essential/25880674#25880674

But while gofer is ok for students under my supervision it is not a reasonable suggestion across the net

Some more generally reasonable/accessible suggestions:

1. Scheme is very much a lisp (except the Lisp-1 Lisp-2 minor mess https://en.wikipedia.org/wiki/Common_Lisp#The_function_namespace )
and unlike (E)Lisp tries hard to be a propah FPL.
The original scheme text https://mitpress.mit.edu/sites/default/files/sicp/index.html is considered a programming classic by many.
I dont like it much -- http://blog.languager.org/2013/08/applying-si-on-sicp.html shows why scheme though more powerful than FPLs is not properly appreciated even by its authors. Felleisen and Friedman I much prefer to SICP
https://www.htdp.org/2003-09-26/Book/
https://www.cs.unm.edu/~williams/cs357/springer-friedman.pdf

2. APL When we were kids Lisp and APL were the two defacto FPLs.
Today Lisp has stopped being considered an FPL
http://blog.languager.org/2015/04/cs-history-1.html

And APL has fallen off the radar... unfortunate. From your single example — (funcall (nth 1 funcs))  — I assume you are sensing that short expressions can be amazingly powerful and want to learn how to do more of that. Look at https://aplwiki.com/FinnAplIdiomLibrary for more such APL examples [Beware! Head can explode]

3. Python: CS degree students it's reasonable to push through them a dozen different languages so that they understand different paradigms in their most optimal setting. People self learning or with less time etc this may be unpleasant/formidable.  And since you seem familiar with python there are also these two python options.
3a SICP in Python
https://wizardforcel.gitbooks.io/sicp-in-python/content/
http://www-inst.eecs.berkeley.edu/~cs61a/sp12/book/
3b Functional programming in python https://www.amazon.com/Functional-Python-Programming-Steven-Lott/dp/1784396990
[Disclaimer I have not delved into either of these so you spend your time at your risk]

Summary: If you wanted to learn Portuguese you could do it anywhere — NY, London Delhi Tokyo.  However staying in Lisbon or Rio de Janeiro will give you more success (presumably!). Python copied its list comprehensions from haskell so in principle one should be able to write (most) Haskell comprehensions in python.  But in the python world you will find universal dissuasion — "comprehensions are hard; first learn to write for-loops..." etc.
So paradoxically the best way to do comprehensions in python is by learning them out of python… Likewise FP in (E)Lisp

tl;dr: ‘(funcall (nth 1 funcs)) ’ is an example of FP style. Lisp/python can be used (for the most part) as an FPL. The cultural questions are the bigger impediment than the technical/factual ones

FP can be language independent… may be too laconic for a beginner! Consider these a list of search terms.

http://blog.languager.org/2012/10/functional-programming-lost-booty.html
http://blog.languager.org/2015/06/functional-programming-moving-target.html

[OFFTOPIC] Re: Invoking a function from a list of functions

[Stefan Monnier]

> http://blog.languager.org/2013/08/applying-si-on-sicp.html shows why scheme

Indeed, `quote` is crucial and while trivial to implement for Scheme,
it's far from trivial in general (see "cross stage persistence" for
example).

> And APL has fallen off the radar... unfortunate.

There's a bit of renewed (academic) interest, tho.  Not exactly in APL,
but in array languages of the same family (i.e. using the same concepts but
without the exotic character set).

See for example http://www.ccs.neu.edu/home/pete/research/esop-2014.html


        Stefan

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Rusi]

On Monday, November 12, 2018 at 8:50:09 PM UTC+5:30, Stefan Monnier wrote:
> Rusi wrote:
> > And APL has fallen off the radar... unfortunate.
> 
> There's a bit of renewed (academic) interest, tho.  Not exactly in APL,
> but in array languages of the same family (i.e. using the same concepts but
> without the exotic character set).
> 
> See for example http://www.ccs.neu.edu/home/pete/research/esop-2014.html

Interesting!

| The array-computational model pioneered by 
| Iverson’s languages APL and J offers a simple 

…

| Our type system’s principal contribution is that it serves to extract the
| implicit control structure that provides so much of the language’s 
| expressive power, making this structure explicitly apparent at compile time

Less known

Arthur Whitney is a Canadian computer scientist most notable for developing three programming languages inspired by APL: A+, K, and Q and for cofounding the U.S. company Kx Systems…
[ https://en.wikipedia.org/wiki/Arthur_Whitney_(computer_scientist) ]

A+ is free software and available in the debian repos
Last I knew the proprietary K,Q cost $ 25,000 per seat (!!)
Above may explain at least partly why people are willing to pay so much for the
speed!

On the more syntactic side I happen to hold more fringe views:

http://blog.languager.org/2015/02/universal-unicode.html
In more detail: http://blog.languager.org/2015/03/whimsical-unicode.html

Some corresponding python thoughts and facts:
http://blog.languager.org/2014/04/unicoded-python.html

Some few more things do work in haskell:
http://blog.languager.org/2014/05/unicode-in-haskell-source.html

Bottom Line: APL's character set was ‘exotic’ in its day
Unicode cannot reasonably called exotic in 2018

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[James K. Lowden]

On Thu, 15 Nov 2018 18:48:53 -0800 (PST)
Rusi <rustompmody@gmail.com> wrote:

> Some corresponding python thoughts and facts:
> http://blog.languager.org/2014/04/unicoded-python.html

I think you're overlooking the paucity of keyboard characters.  I doubt
many programmers want to learn an input system to allow them to
represent, say, u2208.  Never mind *one* input system; you have to
explain how to enter that symbol under Windows, on a Macintosh, in X,
and in a VT100 emulator, if not some combination of those.  

You're also overestimating the mathematical literacy of the programming
public, but that's a separate matter.  :-( 

--jkl

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Rusi]

On Friday, November 16, 2018 at 10:10:05 PM UTC+5:30, James K. Lowden wrote:
> On Thu, 15 Nov 2018 18:48:53 -0800 (PST)
> Rusi  wrote:
> 
> > Some corresponding python thoughts and facts:
> > http://blog.languager.org/2014/04/unicoded-python.html
> 
> I think you're overlooking the paucity of keyboard characters.  I doubt
> many programmers want to learn an input system to allow them to
> represent, say, u2208.  Never mind *one* input system; you have to
> explain how to enter that symbol under Windows, on a Macintosh, in X,
> and in a VT100 emulator, if not some combination of those.  

If you look at your keyboard I am ready to bet that 
- in the middle row on the left side you have a key that looks like ‘A’
- when you type it you get a char that looks more like ‘a’
- and only with the SHIFT-A chord generates an ‘A’.
IOW You are already using a non-trivial input method.

We tend to say “I am using an ASCII keyboard”. In loose informal language this is ok
However technically there is no such thing as an ASCII keyboard. What we call an
ASCII keyboard is most likely us-104 ... something that does not have a one to 
one relation with ASCII.

You can see this more clearly from the hardware angle:
What the keyboard sends to the computer when you type the ‘A’ key is a scan code 
and has no relation whatever with A/a characters.

And once you see
1 You are in any case using an input method
2 Which is user-choosable at OS/X/emacs etc level in any modern system
  it becomes natural to ask: Is the default best for me/my current usage?

At this point the real difficult questions start popping up:

To type αβςδεφγηιθκλμνοπχρστυvωξψζ I just typed abcdefgjijklmnopqrstuvwxyz
with the greek(-babel) input method in emacs.
This may be a reasonable choice if I were Homer(!)
But in the more likely case of being a typical mathematician who sprinkles greek on his writings without a clue about greek, this would be highly inconvenient. Tex input method would likely be better
So the real question is this: If Unicode has a 150,000 code points and a keyboard can be setup to input a few hundred (say) chars conveniently which should I assign for my convenience?

This is a real hard question…
The only answer I am sure of is a negative one — the default is almost certainly sub-optimal for almost everyone: On my keyboard I see two sets of digits, two sets of arrow keys, two sets of +-*/.
Two minus signs and no em,en dash! Seriously!
And above the digits I see !@#$%^&*()
I cant see why I would like to use any of these — other than !() — except for decades of ASCII overloading and misuse (perlish!) bad habits
And ignore all these beauties! 
http://xahlee.info/comp/unicode_math_operators.html

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[James K. Lowden]

On Sat, 17 Nov 2018 07:59:49 -0800 (PST)
Rusi <rustompmody@gmail.com> wrote:

> So the real question is this: If Unicode has a 150,000 code points
> and a keyboard can be setup to input a few hundred (say) chars
> conveniently which should I assign for my convenience?
> 
> This is a real hard question?

Exactly my point.  

> IOW You are already using a non-trivial input method.

Actually, it is a trival input method.  Nearly all keyboards have
symbol emblazoned on each key; exceptions are rare [1].  The user
expects each key to produce one of two characters associated with each
key.  That, I would say, is about as trivial as it gets.  

Since we're ostensibly talking about emacs, I'll point you to M-x.
Despite emacs' generous capacity to overload keys with meaning,
ultimate just the functions of the editor overwhelm the available
keys.  Where the world are you going to put 150,000 code points when
nroff mode steals M-s from occur to center a line?  

The moment you move from a 1:1 correspondence to key to character to
N:1, the possibilities do become endless.  The "compose" key in X, Tex,
and troff are examples.  But they are also daunting.  Just as
alphabetic languages use letters to form words, such input systems use
keys to form characters.  It's a new language.  

I'm simply suggesting that for most programmers, the beauty of reading
a non-alphabetic programming language is not worth the hassle of
learning to type it.  As evidence, I give you APL: every successor
dropped the exotic character set, despite being invented since the
advent of Unicode and bitmapped displays.  

--jkl

[1] https://www.daskeyboard.com/daskeyboard-4-ultimate/

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Stefan Monnier]

> I'm simply suggesting that for most programmers, the beauty of reading
> a non-alphabetic programming language is not worth the hassle of
> learning to type it.  As evidence, I give you APL: every successor
> dropped the exotic character set, despite being invented since the
> advent of Unicode and bitmapped displays.  

FWIW, in the Agda language, it's very common to use non-ASCII characters
which are input (in agda-mode) via a variant of the TeX input method.
The reason this is tolerated is because those chars are already familiar
to most users because they're used on paper for the same purpose.


        Stefan

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Amin Bandali]

Stefan Monnier writes:

> FWIW, in the Agda language, it's very common to use non-ASCII characters
> which are input (in agda-mode) via a variant of the TeX input method.
> The reason this is tolerated is because those chars are already familiar
> to most users because they're used on paper for the same purpose.

Same with Lean: lean-mode comes with lean-input which is based on
agda-input with minor changes, and it makes it /super/ convenient
to insert commonly used unicode characters: \a for α, \b for β,
a\1 for a₁, \and for ∧, \|- for ⊢, and hundreds more.  I’ve
actually come to like lean-input so much that I’ve set it as my
default-input-method so I can toggle it with C-\ and easily type
unicode symbols whenever and wherever I want.

I’ve been experimenting with using lean-input along with the
unicode-math package (for {Lua,Xe}TeX) and it has drastically
improved my experience with writing and reading Org and TeX
documents.  It’s possible to change the input prefix from
backslash to something else to avoid clashes when writing TeX¹.

Footnotes:
¹  https://git.sr.ht/~bandali/dotfiles/commit/e44b9b7eb100a3d5c1640b7df7d4c458f81998ab

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Stefan Monnier]

> Same with Lean: lean-mode comes with lean-input which is based on
> agda-input with minor changes, and it makes it /super/ convenient
> to insert commonly used unicode characters: \a for α, \b for β,
> a\1 for a₁, \and for ∧, \|- for ⊢, and hundreds more.  I’ve
> actually come to like lean-input so much that I’ve set it as my
> default-input-method so I can toggle it with C-\ and easily type
> unicode symbols whenever and wherever I want.

Maybe we should add a "math" input method along the lines of those
Agda/Lean input methods.  I currently use the TeX input method for such
purposes but it tends to be a bit more verbose than I like.

> It’s possible to change the input prefix from
> backslash to something else to avoid clashes when writing TeX¹.

In my experience (using the TeX input method when writing LaTeX),
I think the main problem with the clash on \ is that when the LaTeX
command I write has a valid prefix in the input method, the input method
rewrites that prefix.  If we could fix it so that "\b" inputs "β" but
"\beta" isn't rewritten to "βeta" then I might even be able to have \
play both roles without going bonkers.


        Stefan

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Amin Bandali]

> Maybe we should add a "math" input method along the lines of those
> Agda/Lean input methods.  I currently use the TeX input method for such
> purposes but it tends to be a bit more verbose than I like.

A proper “math”/“logic” input method would be awesome.  Also, I
too find the TeX input method very verbose and much prefer the
shorter and easier-to-remember aliases of the Lean/Agda input
methods.

> In my experience (using the TeX input method when writing LaTeX),
> I think the main problem with the clash on \ is that when the LaTeX
> command I write has a valid prefix in the input method, the input method
> rewrites that prefix.  If we could fix it so that "\b" inputs "β" but
> "\beta" isn't rewritten to "βeta" then I might even be able to have \
> play both roles without going bonkers.

Indeed, I think fixing that would alleviate a major pain point
with the default \ prefix.  I guess the user then wouldn’t have
to also escape the \ itself (by typing it twice) when wanting to
write actual TeX commands?

-amin

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Rusi]

On Tuesday, November 20, 2018 at 11:45:44 AM UTC+5:30, Amin Bandali wrote:
> Stefan Monnier writes:
> 
> > FWIW, in the Agda language, it's very common to use non-ASCII characters
> > which are input (in agda-mode) via a variant of the TeX input method.
> > The reason this is tolerated is because those chars are already familiar
> > to most users because they're used on paper for the same purpose.
> 
> Same with Lean: lean-mode comes with lean-input which is based on
> agda-input with minor changes, and it makes it /super/ convenient
> to insert commonly used unicode characters: \a for α, \b for β,
> a\1 for a₁, \and for ∧, \|- for ⊢, and hundreds more.  I’ve
> actually come to like lean-input so much that I’ve set it as my
> default-input-method so I can toggle it with C-\ and easily type
> unicode symbols whenever and wherever I want.

Thanks for pointing out lean to me
[And not just because its spelt L∃∀N !]

Do you have a good comparison of the contenders lean, agda, idris isabelle(?) etc?

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Amin Bandali]

On 2018-11-28  6:14 AM, Rusi wrote:
> Thanks for pointing out lean to me
> [And not just because its spelt L∃∀N !]

:) No worries!

> Do you have a good comparison of the contenders lean, agda, idris isabelle(?) etc?

I haven’t personally used all of them, so I can’t talk with certainty;
so please take this with a grain of salt.  Also, I think each of these
languages are great tools in their own light.

That said, the first three you mentioned (Lean, Agda, and Idris) are
based on dependent type theory, whereas Isabelle is based on simple type
theory.  I think that’s a fairly distinguishable difference.

Of the ones based on dependent type theory, Agda and Idris give me the
impression of being more closer to a programming language with dependent
types than a theorem prover.  A friend of mine that does a lot theorem
proving once told me he’d found Agda a bit hard to use because of its
limited proof language.  Though, he’d found pattern matching in Agda to
be really good and more convenient than Coq.  Lean and Coq, both being
based on the Calculus of Inductive Constructions flavour of dependent
type theory, seem to come off as more ‘general purpose’ environments not
geared towards only one of programming or theorem proving, but both.

Further, Lean borrows many niceties of the others, including Agda’s
pattern matching, Haskell’s type classes like Applicative Functors and
Monads and convenient syntactic sugar like the do notation, Coq’s CIC,
etc.  Another characteristic that makes Lean very exciting is its
meta-programming facilities and the ability to write tactics and extend
the language in Lean itself, e.g. unlike Haskell’s Template Haskell.
Further, two of the Lean core developers are working on rewriting more
pieces of currently-writtten-in-C++ of Lean in Lean for the upcoming
Lean 4, exposing more of the parser and internals for use by external
tools like text editors (including our favourite GNU Emacs :-)) and
embedding of arbitrary domain-specific languages in Lean.


Here are some links with vastly more information than my rant above :)

https://leanprover.github.io/papers/system.pdf
https://leanprover.github.io/talks/stanford2017.pdf
https://leanprover.github.io/presentations/20181012_MSR/
https://homotopytypetheory.org/2015/12/02/the-proof-assistant-lean/
https://www.reddit.com/r/Idris/comments/6qv5c6/comparison_between_idris_and_agda/
https://www.functionalgeekery.com/episode-62-lars-hupel/

HTH.

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Rusi]

On Tuesday, November 20, 2018 at 4:42:06 AM UTC+5:30, Stefan Monnier wrote:
> > I'm simply suggesting that for most programmers, the beauty of reading
> > a non-alphabetic programming language is not worth the hassle of
> > learning to type it.  As evidence, I give you APL: every successor
> > dropped the exotic character set, despite being invented since the
> > advent of Unicode and bitmapped displays.  
> 
> FWIW, in the Agda language, it's very common to use non-ASCII characters
> which are input (in agda-mode) via a variant of the TeX input method.
> The reason this is tolerated is because those chars are already familiar
> to most users because they're used on paper for the same purpose.

I did not want to bring in Agda since I think it botches up unicode input with
over enthusiasm [I dont know much Agda FWIW]

However the number of ways of doing unicode badly should be combinatorially larger
than the number of ways of doing it right

Heres python3 compared to elisp


ELISP> (setq flag "hi")
"hi"
ELISP> (setq flag "there")
"there"
ELISP> (list flag flag)
("hi" "there")

ELISP> (setq á "hi")
"hi"
ELISP>  (setq á "there")
"there"
ELISP>  (list á á)

Python

>>> flag = 1
>>> flag = 2
>>> (flag, flag)
(2, 2)

>>> á = 1
>>> á = 2
>>> (á, á)
(2, 2)

In my view python does it right(er) than elisp (Haskell is in elisp category)
where "right" is defined by :identifiers should identify



However when push comes to shove both python and elisp are equally bad

>>> Α = "hi"
>>> A = "there"
>>> (Α,A)
('hi', 'there')


ELISP>  (setq Α "hi")
"hi"
ELISP>  (setq A "there")
"there"
ELISP>  (list Α A)
("hi" "there")

which brings me to…

On Tuesday, November 20, 2018 at 3:54:00 AM UTC+5:30, James K. Lowden wrote:
> On Sat, 17 Nov 2018 07:59:49 -0800 (PST)
> Rusi wrote:
> > IOW You are already using a non-trivial input method.
> 
> Actually, it is a trival input method.  Nearly all keyboards have
> symbol emblazoned on each key; exceptions are rare [1].  The user
> expects each key to produce one of two characters associated with each
> key.  That, I would say, is about as trivial as it gets.  

Notice how anglo-centric above is??
If you find ‘A’ an ‘a’ as trivially the same
what do you say about ‘A’ and ‘Α’??

PS Just to be clear: I am no fan of liberalism multi-culturalism and all that 
jazz; just pointing out that all modern programming languages are falling over
each other to be more virtuous
Even C seems to have something called extended identifiers¿?

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Eli Zaretskii]

> Date: Wed, 28 Nov 2018 06:10:48 -0800 (PST)
> From: Rusi <rustompmody@gmail.com>
> 
> ELISP> (setq flag "hi")
> "hi"
> ELISP> (setq flag "there")
> "there"
> ELISP> (list flag flag)
> ("hi" "there")
> 
> ELISP> (setq á "hi")
> "hi"
> ELISP>  (setq á "there")
> "there"
> ELISP>  (list á á)
> 
> Python
> 
> >>> flag = 1
> >>> flag = 2
> >>> (flag, flag)
> (2, 2)
> 
> >>> á = 1
> >>> á = 2
> >>> (á, á)
> (2, 2)
> 
> In my view python does it right(er) than elisp

That's debatable: the Unicode Standard says to act according to
canonical equivalence only in text, whereas the above are symbol
names.  We do display them the same (if the font supports that), but
we aren't under any obligation to map them to the same symbols, IMO.

> However when push comes to shove both python and elisp are equally bad
> 
> >>> Α = "hi"
> >>> A = "there"
> >>> (Α,A)
> ('hi', 'there')
> 
> 
> ELISP>  (setq Α "hi")
> "hi"
> ELISP>  (setq A "there")
> "there"
> ELISP>  (list Α A)
> ("hi" "there")

Why bad?  Those characters are not canonically equivalent.  If you
want to go by compatibility equivalence, you will enter a slippery
slope, where, for example, Ⅰ and 1 will yield the same symbol or even
the same number.  Is that what you (or we) really want?  I'd be
surprised.

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Yuri Khan]

On Thu, Nov 29, 2018 at 12:21 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > >>> (á, á)> > (2, 2)
> >
> > In my view python does it right(er) than elisp
>
> That's debatable: the Unicode Standard says to act according to
> canonical equivalence only in text, whereas the above are symbol
> names.  We do display them the same (if the font supports that), but
> we aren't under any obligation to map them to the same symbols, IMO.

Standard Annex 31 deals with identifiers in programming languages, and
recommends considering identifiers equivalent if they are the same
under Normalization Form C for case-sensitive languages (such as
Python and Elisp).

(It suggests using Normalization Form KC for case-insensitive
languages, although I do not see how compatibility decomposition is
similar to case folding.)

> > ELISP>  (list Α A)
> > ("hi" "there")
>
> Why bad?  Those characters are not canonically equivalent.

They are not even compatibility equivalent. Homoglyphic, yes, but not
equivalent in any way.

> If you
> want to go by compatibility equivalence, you will enter a slippery
> slope, where, for example, Ⅰ and 1 will yield the same symbol or even
> the same number.

No they won’t. Compatibility decomposition of U+2160 ROMAN NUMERAL ONE
is U+0073 LATIN CAPITAL LETTER I.

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Eli Zaretskii]

> From: Yuri Khan <yurivkhan@gmail.com>
> Date: Thu, 29 Nov 2018 01:15:41 +0700
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> > That's debatable: the Unicode Standard says to act according to
> > canonical equivalence only in text, whereas the above are symbol
> > names.  We do display them the same (if the font supports that), but
> > we aren't under any obligation to map them to the same symbols, IMO.
> 
> Standard Annex 31 deals with identifiers in programming languages, and
> recommends considering identifiers equivalent if they are the same
> under Normalization Form C for case-sensitive languages (such as
> Python and Elisp).

  "Implementations that take normalization and case into account have
  two choices: to treat variants as equivalent, or to disallow
  variants."

So there's a choice.

> (It suggests using Normalization Form KC for case-insensitive
> languages, although I do not see how compatibility decomposition is
> similar to case folding.)

Case-folding is considered a special case of character folding.

> > > ELISP>  (list Α A)
> > > ("hi" "there")
> >
> > Why bad?  Those characters are not canonically equivalent.
> 
> They are not even compatibility equivalent.

I didn't say they were.

> > If you
> > want to go by compatibility equivalence, you will enter a slippery
> > slope, where, for example, Ⅰ and 1 will yield the same symbol or even
> > the same number.
> 
> No they won’t. Compatibility decomposition of U+2160 ROMAN NUMERAL ONE
> is U+0073 LATIN CAPITAL LETTER I.

Yes, a mistaken example, sorry.  But the idea is clear, I hope.  E.g.,
the compatibility decomposition of ⁵ is 5, and the compatibility
decomposition of ⑴, a single character, is (1), which is a list in
Emacs.

That way lies madness, IMO.

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Yuri Khan]

On Thu, Nov 29, 2018 at 1:58 AM Eli Zaretskii <eliz@gnu.org> wrote:

> the compatibility decomposition of ⁵ is 5, and the compatibility
> decomposition of ⑴, a single character, is (1), which is a list in
> Emacs.
>
> That way lies madness, IMO.

FWIW, I agree, trying to apply too much decomposition is misguided.

(I was recently informed that web browsers allow the use of
compatibility characters in domain names, and compatibility-decompose
them before resolving, so U+338F “kilogram” becomes Kyrgyzstan and
milliliter maps to Mali. That *is* madness.)

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[Rusi]

On Thursday, November 29, 2018 at 12:38:49 AM UTC+5:30, Yuri Khan wrote:

> (I was recently informed that web browsers allow the use of
> compatibility characters in domain names, and compatibility-decompose
> them before resolving, so U+338F “kilogram” becomes Kyrgyzstan and
> milliliter maps to Mali.

I am being troublesome but (hopefully!) not malicious
Add some good ol badness as hot peppers to the cake
https://en.wikipedia.org/wiki/IDN_homograph_attack

> That *is* madness.)

Precisely my point

On Thursday, November 29, 2018 at 12:27:46 AM UTC+5:30, Eli Zaretskii wrote:
> > From: Yuri Khan 
> > 
> > > That's debatable: the Unicode Standard says to act according to
> > > canonical equivalence only in text, whereas the above are symbol
> > > names.  We do display them the same (if the font supports that), but
> > > we aren't under any obligation to map them to the same symbols, IMO.
> > 
> > Standard Annex 31 deals with identifiers in programming languages, and
> > recommends considering identifiers equivalent if they are the same
> > under Normalization Form C for case-sensitive languages (such as
> > Python and Elisp).
> 
>   "Implementations that take normalization and case into account have
>   two choices: to treat variants as equivalent, or to disallow
>   variants."
> 
> So there's a choice.

And if you ask me, disallow is the reasonable default
Earlier I compared python3 and elisp — a nuanced comparison
A more basic comparison would be between python 2 and 3 


$ cat simple.py 
A = 1
A = 2
print("A, A, A==A : %s, %s, %s\n" % (A,A,A==A))


$ cat homoglyph.py 
A = 1
А = 2
print("A, А, A==А : %s, %s, %s\n" % (A,А,A==А))

$ python2 simple.py 
A, A, A==A : 2, 2, True

$ python3 simple.py 
A, A, A==A : 2, 2, True

$ python3 homoglyph.py 
A, А, A==А : 1, 2, False

$ python2 homoglyph.py 
  File "homoglyph.py", line 2
SyntaxError: Non-ASCII character '\xd0' in file homoglyph.py on line 2, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details


IMHO python 2 is doing the right thing not python3 
As I am sure elisp would be doing if we could get a 25 year old version

We could sharpen the error if we liked:

$ cat homoglyphE.py 
# -*- coding: utf-8 -*-
A = 1
А = 2
print("A, А, A==А : %s, %s, %s\n" % (A,А,A==А))



$ python2 homoglyphE.py 
  File "homoglyphE.py", line 3
    А = 2
    ^
SyntaxError: invalid syntax

Re: [OFFTOPIC] Re: Invoking a function from a list of functions

[James K. Lowden]

On Thu, 15 Nov 2018 18:48:53 -0800 (PST)
Rusi <rustompmody@gmail.com> wrote:

> > See for example
> > http://www.ccs.neu.edu/home/pete/research/esop-2014.html
> 
> Interesting!
> 
> | The array-computational model pioneered by 
> | Iverson?s languages APL and J offers a simple 

Yes.  IMO array operators and orthogonal persistence are two very
underappreciated language design features.  

As for John Sowa, I have to agree and disagree: 

> Whenever a major organization develops a new system as an official
> standard for X, the primary result is the widespread adoption of some
> simpler system as a de facto standard for X. 

Yes, but his examples don't hold water

> The PL/I project by IBM and SHARE resulted in
> Fortran and COBOL 

PL/1 post-dates Cobol by at least 7 years.  By the time PL/1 was
available, Cobol was already commercially successful.  What use did the
Cobol programmer have for PL/1?  And what evidence that it's a simpler
language?  

> Algol 68 project by IFIPS resulted in Pascal

Algol and Pascal are contemporaries, but Pascal was expressly designed
as a pedagogical language.  That it succeeded in academia should be no
surprise, other than that it achieved Wirth's goals.  

> Ada project by the US DoD resulted in C 

Ada was developed concurrently with C, but C was in widespread use long
before the DoD idiotically standardized on Ada in ... 1991.  By that
time C had escaped Bell Labs and been ratified by ANSI, not to mention
had been used to write at least 4 operating systems.  Ada's impact on C
was nil.  

> The OS/2 project by IBM and Microsoft resulted in Windows 

Because Windows was simpler?  Debatable, to say the least.  There's a
lot of industrial intrigue in that story, and marketing savvy.  

And technical merit.   What IBM really missed was exploiting protected
mode while supporting real-mode DOS applications.  Window's was "good
enough" for most people: it ran faster and had 10x the application that
OS/2 ever had. Windows NT was a game changer: protected memory and full
multitasking for a couple thousand bucks.  It cost 1/10 of the
competition, and had at least 10x the application suite.  OS/2 had
neither the technical competency nor the application support.  

--jkl

RE: [OFFTOPIC] Re: Invoking a function from a list of functions

[Drew Adams]

> > The PL/I project by IBM and SHARE resulted in
> > Fortran and COBOL
> 
> PL/1 post-dates Cobol by at least 7 years.  By the time PL/1 was
> available, Cobol was already commercially successful.  What use did the
> Cobol programmer have for PL/1?  And what evidence that it's a simpler
> language?

And Fortran certainly came years before "the PL/I project".

https://en.wikipedia.org/wiki/PL/I#Early_history