Proposed new syntax

Rustom Mody rustompmody at gmail.com
Sun Aug 20 00:28:04 EDT 2017


On Saturday, August 19, 2017 at 9:45:48 AM UTC+5:30, Steve D'Aprano wrote:
> On Sat, 19 Aug 2017 12:59 am, Chris Angelico wrote:
> 
> > On Fri, Aug 18, 2017 at 11:46 PM, Rustom Mody  wrote:
> >> Compare the well-known haskell tutorial
> >> http://learnyouahaskell.com/starting-out
> >> whose comprehension intro starts:
> >>
> >> | If you've ever taken a course in mathematics, you've probably run into set
> >> | comprehensions. They're normally used for building more specific sets out
> >> | of general sets. A basic comprehension for a set that contains the first
> >> | ten even | natural numbers is
> >>
> >> | S = {2·x | x ∈ ℕ, x ≤ 10}
> 
> For the record, this is not the best example to give, since the Natural numbers
> ℕ are not well-defined. Some people include 0, and some do not, so there's a
> slight ambiguity to the above.
> 
> http://mathworld.wolfram.com/NaturalNumber.html
> 
> Despite that nit-pick, set builder notation is very common in maths, but not
> universal. It is taught in secondary education (high school) in Australia, but
> not to all students.

There's more than just a nit-pick wrong with that expression

Here’s an actual Haskell run

Prelude> [x*2 | x <- [1..], x <= 10]
[2,4,6,8,10,12,14,16,18,20^CInterrupted.
Prelude> 

ie after “…,20” instead of printing a ']' and giving back the  "Prelude>" prompt
it hangs… searching in the entire set of integers > 10…
for an integer <= 10 (!!)
…until a Control-C is given

What’s the conclusion?? Take your pick:
- Functional programming is stupid
- Haskell is not all that intelligent
- Halting problem is unsolvable
- Converting the borderline uncomputable notion of set builder /comprehensions
  into the computational framework of programming is fraught with trouble
- Sets are a harder data-structure from computational pov than lists
- ??

> 
> 
> 
> >> Analogous thing shown at ghci prompt:
> >>
> >> | ghci> [x*2 | x <- [1..10]]
> >> | [2,4,6,8,10,12,14,16,18,20]

So not really analogous!
[Its the first time I am reading that article/book… just searched a standard
Haskell tutorial source and posted it]

> > 
> > And what if you HAVEN'T taken a course in mathematics? What use is
> > this then? How would you teach this to a non-mathematician?
> 
> Speaking as someone who *has* taken a course of mathematics or two, I find that
> Rustom's insistence in coming back to the fundamentals of set theory and the
> Zermelo–Fraenkel axioms is not terribly helpful. Even among professional
> mathematicians. Z-F and the axiom of choice and related matters are extremely
> specialised and abstract fields of little interest to the average working
> mathematician.

Dunno where you got that
My reference to Zermelo-Fraenkel was entirely from the point of tracing the history,
not to say that the logic-studies of a 100 years ago has any relevance to today
Specifically the term 'comprehension' used today as a programming construct
traces somewhat tenuously to an axiom that Zermelo/Fraenkel formulated in the 1920s

Lives today in python in the fact that the russel-set gives a straightforward
syntax error and nothing more grandly profound

>>> R = {x if x not in x}
  File "<stdin>", line 1
    R = {x if x not in x}
                        ^
SyntaxError: invalid syntax
>>> 
ie the first element of a comprehension must be a 'for' not

Almost…

Unfortunately python muddies the discussion by overloading predicate 'in'
and generator 'in'. So following follows the stricture above but still does not work 😦

>>> R = {x for x not in x}
  File "<stdin>", line 1
    R = {x for x not in x}
                   ^
SyntaxError: invalid syntax
>>> 



> 
> In my experience, they're of more interest to philosophers and dilettantes than
> actual mathematicians, outside of the minority working in that specific field.
> 
> Yes yes, it is absolutely fundamental to mathematics, just as quantum mechanics
> is absolutely fundamental to an understanding of matter. How many bridge
> builders care about quantum mechanics?
> 
> Python is not Haskell and makes no pretence at being mathematically sound[1].
> The Zen of Python sets forth some of the design principles in the language,
> and "mathematical purity" is not one of them.
> 
> The opposite, in fact: "practicality beats purity."
> 
> To answer your (Chris') question:

Strawman argument as usual!
For myself, thanks to Peter's clarification that 'comprehension' is best
thought of as 'comprise', I am now going to teach to my students:
“Comprehension is a misspelling of comprision”
[Comprehensivesion would be more tolerable semantically than comprehension
but hurts mouth and eyes!]

> 
> When I teach comprehension syntax, I always mention set builder notation and
> say "you may have been taught this is school". I don't think I have ever come
> across someone who both *was* taught it and *remembers* so, but I'll keep
> trying. For those who don't understand set builder notation (so far, everyone
> I've tried to teach comps to) I explain them in terms of for loops.
> 
> In fact, even if you do understand set builder notation, for more complex
> examples with "if" clauses and multiple "for" loops, I maintain that you have
> to think of it in terms of loops to understand it. I am extremely skeptical
> that anyone could look at a comprehension like:
> 
>     [expr for x in A for y in B if P for z in C if Q for w in D for v in E if R]
> 
> and understand it *without* converting it to nested loops.
> 
> 
> > Pretty much everyone, at some point in their lives, will follow a set
> > of written instructions. Most commonly, a recipe for some sort of
> > food. It consists of a set of ingredients and a sequence of commands.
> > This translates well into a classic imperative style
> 
> Indeed. People find imperative (recipe) algorithms easy to follow, and pure
> functional reasoning hard. I'm glad that functional programming is fashionable
> again, and hope that people will learn good habits from it, but I think that
> mathematical purity is not necessary or even helpful in the majority of
> programming tasks.

<anecdote>
I had a good friend in school who loved to play the flute.
And when he played everyone around suffered
He knew they suffered; he did not know why

One day he asked me: “Please teach me music!”
“uh… I dont know flute”
“No No! You know music! Please teach me!”

So I went to the piano and (tried) to show him…
“See (hear) this…”
Middle-C + upper-C
C + G
C + E
C + C#

I was hoping to show him that musical proximity and physical proximity are not 
the same
I was hoping to show him that…
all C's are the 'same'
C + G is consonant as is C + E; but C+E is more 'interesting'
C+ C# is unpleasant
etc

I never reached that far!
He gave me a funny look; I asked : “What happened?”
“To me they all sound the same” (¡!¡!)
</anecdote>

So if Chris can answer how to teach music to a tone-deaf person, I can
consider how to answer the question of how to teach programming to a math-challenged one

Hint:

>>> import operator
>>> dir(operator)
['__abs__', '__add__', '__and__', '__concat__', '__contains__', '__delitem__', '__delslice__', '__div__', '__doc__', '__eq__', '__floordiv__', '__ge__', '__getitem__', '__getslice__', '__gt__', '__iadd__', '__iand__', '__iconcat__', '__idiv__', '__ifloordiv__', '__ilshift__', '__imod__', '__imul__', '__index__', '__inv__', '__invert__', '__ior__', '__ipow__', '__irepeat__', '__irshift__', '__isub__', '__itruediv__', '__ixor__', '__le__', '__lshift__', '__lt__', '__mod__', '__mul__', '__name__', '__ne__', '__neg__', '__not__', '__or__', '__package__', '__pos__', '__pow__', '__repeat__', '__rshift__', '__setitem__', '__setslice__', '__sub__', '__truediv__', '__xor__', '_compare_digest', 'abs', 'add', 'and_', 'attrgetter', 'concat', 'contains', 'countOf', 'delitem', 'delslice', 'div', 'eq', 'floordiv', 'ge', 'getitem', 'getslice', 'gt', 'iadd', 'iand', 'iconcat', 'idiv', 'ifloordiv', 'ilshift', 'imod', 'imul', 'index', 'indexOf', 'inv', 'invert', 'ior', 'ipow', 'irepeat', 'irshift', 'isCallable', 'isMappingType', 'isNumberType', 'isSequenceType', 'is_', 'is_not', 'isub', 'itemgetter', 'itruediv', 'ixor', 'le', 'lshift', 'lt', 'methodcaller', 'mod', 'mul', 'ne', 'neg', 'not_', 'or_', 'pos', 'pow', 'repeat', 'rshift', 'sequenceIncludes', 'setitem', 'setslice', 'sub', 'truediv', 'truth', 'xor']


Do tell me how many of these are unrelated to math!



More information about the Python-list mailing list