Re: Python-based monads essay (Re: Assignment versus binding)
On Friday, October 14, 2016 at 10:31:36 AM UTC+5:30, Marko Rauhamaa wrote: > Gregory Ewing : > > > Marko Rauhamaa wrote: > >> This suggests even the promoters of functional programming > >> intuitively prefer imperative programming, but that's ok as long as > >> it's all functional under the hood. > > > > You make it sound like functional programmers like functional > > programming because it gives them a warm fuzzy feeling. I don't think > > that's true -- there are specific reasons they like it, and those > > reason still apply when I/O is expressed using a monadic structure. > > > > Read Part 2 - I have something to say about that at the end. > > I've read it. This looks awfully imperative to me: You are an assembly language programmer. You've mastered interrupts, instruction formats, IO nitty gritties, protection modes and all the other good stuff Up comes this ‘structured programming' kid believing his new religion will save the world. You ask him about all the stuff youve spent your life on 1st answer: none of thats available You scratch your head: So the kewlest paradigm is the poweroff button 2nd answer: Well if you must have all that there's - separate compilation - inline assembly - intrinsics - etc - etc You: (scratching the head harder): Every solution you are giving me makes my life worse. You want to qualify as sadist? Be by guest! Programmers messiah? Not mine. Thank you! FP is not much more than structured programming carried to its logical limit: http://blog.languager.org/2012/11/imperative-programming-lessons-not.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Gregory Ewing :
> Marko Rauhamaa wrote:
>> This suggests even the promoters of functional programming
>> intuitively prefer imperative programming, but that's ok as long as
>> it's all functional under the hood.
>
> You make it sound like functional programmers like functional
> programming because it gives them a warm fuzzy feeling. I don't think
> that's true -- there are specific reasons they like it, and those
> reason still apply when I/O is expressed using a monadic structure.
>
> Read Part 2 - I have something to say about that at the end.
I've read it. This looks awfully imperative to me:
main = do
putStrLn "Hi, what's your name?"
name <- getLine
putStrLn ("Aren't monads great, " ++ name ++ "?")
Scheme programmers have (begin ...) for sequential blocks and (do ...)
and (for-each ...) for loops.
As your Part 2 indicates, Haskell's use of monads to implement I/O is
not pure functional programming. The order of execution is significant
and functions have side effects.
Nothing wrong with any of this. I'm all for mixed paradigms.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Marko Rauhamaa wrote: This suggests even the promoters of functional programming intuitively prefer imperative programming, but that's ok as long as it's all functional under the hood. You make it sound like functional programmers like functional programming because it gives them a warm fuzzy feeling. I don't think that's true -- there are specific reasons they like it, and those reason still apply when I/O is expressed using a monadic structure. Read Part 2 - I have something to say about that at the end. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Gregory Ewing : > Steve D'Aprano wrote: >> The way you can usually tell your functional language has given up >> purity in favour of mutating implementations is that your code >> actually runs with non-toy amounts of data :-) > > Hmmm. Your argument here seems to be: "Everyone knows that functional > languages are impractical, so if it's practical, then it can't be > functional." > > If she weighs the same as a duck, she's a witch! >From you essay: What's more, it's starting to look a lot like a sequential program. We can read it fairly clearly as "add the first element to the set, then add the rest of the elements to the set, unless the list is empty, in which case turn the set into a list and stop." http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/Demy stifyingMonads.html> It is interesting that right after introducing lambda calculus or pure functional programming to students, textbooks quickly proceed to demonstrate how the functional paradigm can emulate the imperative paradigm, as you have done above. This suggests even the promoters of functional programming intuitively prefer imperative programming, but that's ok as long as it's all functional under the hood. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Steve D'Aprano wrote: The way you can usually tell your functional language has given up purity in favour of mutating implementations is that your code actually runs with non-toy amounts of data :-) Hmmm. Your argument here seems to be: "Everyone knows that functional languages are impractical, so if it's practical, then it can't be functional." If she weighs the same as a duck, she's a witch! More seriously, saying "given up purity in favour of mutating implementations" implies that the two are mutually exclusive. I don't agree that they are. At least as far as in-memory data structure are concerned, in-place mutation is a form of garbage collection. You notice that the old version of the data is going to immediately become garbage, so it might as well be replaced by the new version. The observable behaviour of the program remains the same. That's what I mean by "impossible to tell". -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
On Wed, 12 Oct 2016 11:52 pm, Gregory Ewing wrote: > Steven D'Aprano wrote: >> "the implementation is free to use in-place mutations of the state object >> – ... without letting anyone know that the implementation has given up >> any functional purity." > > If it's impossible to tell that functional purity has > been given up, then in what sense has it been given up > at all? Did I say it was impossible to tell? Just because Donald Trump doesn't admit to wearing a hairpiece doesn't mean that nobody can tell that he does. *wink* The way you can usually tell your functional language has given up purity in favour of mutating implementations is that your code actually runs with non-toy amounts of data :-) -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Steven D'Aprano wrote: "the implementation is free to use in-place mutations of the state object – ... without letting anyone know that the implementation has given up any functional purity." If it's impossible to tell that functional purity has been given up, then in what sense has it been given up at all? -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
On Sunday 09 October 2016 18:48, Gregory Ewing wrote: > Here's the first part of the essay I said I'd write about > monads: > > http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html Quoting from the essay: "the implementation is free to use in-place mutations of the state object – which obviously allows considerable gains in efficiency, both in time and memory usage – without giving up any functional purity." Surely that should be as follows? "the implementation is free to use in-place mutations of the state object – which obviously allows considerable gains in efficiency, both in time and memory usage – without letting anyone know that the implementation has given up any functional purity." I'm inclined to agree with James Hague (via John Cook): functional programming is great, until you try to be strict about it. The closer you get to 100% functional, the less you can use it. He reckons the sweet spot is about 85% functional: http://www.johndcook.com/blog/2010/04/15/85-functional-language-purity/ -- Steven git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Paul Rubin wrote: Also if this operation is what it looks like, it's usually called "bind". seq is something else entirely. Ah, I hadn't realised there was already a function in Haskell called seq -- sorry about that! I don't really want to call the Python version 'bind', because it seems a bit obscure. Also, the way I'm using it there, it's not actually binding anything (it corresponds to >> rather than >>=), so calling it 'bind' would just confuse matters. I'll see if I can come up with a better name for it that doesn't clash with anything. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Anuradha Laxminarayan wrote: seq f g h = f (\s1 -> g h s1) better be written as seq f g x = f (\s1 -> g x s1) because naming conventions imply that h is function. Well, for the subset of monads I'm talking about, it always is a function -- it's the continuation to be run after f and g. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
On Tuesday, October 11, 2016 at 9:53:25 PM UTC+5:30, Anuradha Laxminarayan wrote: > On Sunday, 9 October 2016 13:18:32 UTC+5:30, Gregory Ewing wrote: > > Here's the first part of the essay I said I'd write about > > monads: > > > > http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html > > > > Hope it's useful, > > Greg > > Thanks, that made a very interesting read. Yeah agreed! Just got it running in ghc. Some small modifications needed: import Data.Set add x f s = f (insert x s) listify f s = f (toList s) s seqq f g x = f (\s1 -> g x s1) dedup (x:t) = seqq (add x) (dedup t) dedup [] = listify run_smf f a = f a (\r s -> r) empty > seq f g h = f (\s1 -> g h s1) > better be written as > seq f g x = f (\s1 -> g x s1) > because naming conventions imply that h is function. I think it would be good to make state and adhere to a name-convention eg c for continuation f,g for general function s for state etc Otherwise excellent work! V useful -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Anuradha Laxminarayan writes: > seq f g x = f (\s1 -> g x s1) > because naming conventions imply that h is function. Also if this operation is what it looks like, it's usually called "bind". seq is something else entirely. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
On Sunday, 9 October 2016 13:18:32 UTC+5:30, Gregory Ewing wrote: > Here's the first part of the essay I said I'd write about > monads: > > http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html > > Hope it's useful, > Greg Thanks, that made a very interesting read. In Haskell, the type M a -> M b-> M b tells a good deal of the story of seq In a Pythonic context, continuations seem to be an effective way to carry that story. Small minor haskell suggestions from a pedagodic pov [related to Ben Finney's suggestion?] seq f g h = f (\s1 -> g h s1) better be written as seq f g x = f (\s1 -> g x s1) because naming conventions imply that h is function. - Anuradha -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Paul Rubin writes: >https://www.cs.cmu.edu/~edmo/silliness/burrito_monads.pdf Whoops, url changed: http://emorehouse.web.wesleyan.edu/silliness/burrito_monads.pdf -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Gregory Ewing writes: > Oh, undoubtedly. I just don't think it helps understand how burritos > are used in prog... er, that is, how monads... well, you know what I > mean. How about in math? https://www.cs.cmu.edu/~edmo/silliness/burrito_monads.pdf ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Paul Rubin wrote: Well, at least I refrained from saying that monads are like burritos! But they are! See: http://blog.plover.com/prog/burritos.html Oh, undoubtedly. I just don't think it helps understand how burritos are used in prog... er, that is, how monads... well, you know what I mean. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
On Sunday, October 9, 2016 at 1:18:32 PM UTC+5:30, Gregory Ewing wrote: > Here's the first part of the essay I said I'd write about > monads: > > http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html > > Hope it's useful, > Greg Thanks Greg... looks v useful... the continuation-oriented approach. Will say more after a more careful study -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
> Well, at least I refrained from saying that monads are like burritos! But they are! See: http://blog.plover.com/prog/burritos.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Gregory Ewing writes: > Here's the first part of the essay I said I'd write about > monads: Thank you for tackling this. > http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html You appreciate an important feature of this: Often it is presented in a very abstract and mathematical way, which tends to have an eye-glazing effect on people who aren't hard-core mathematicians. This is an attempt to convey the basic ideas behind monads to someone who is a programmer rather than a mathematician. One important lack that I often see in essays written by mathematicians about programming, is the tendency to use opaque single-character symbols., such as might be easy to write in chalk on a blackboard. In a programming language, though, we do not have the constraint of writing them with chalk on a blackboard. Symbols can be given *descriptive names*, that communicate the semantic meaning of the symbol. Can you re-write the code examples, for example:: def add(x, f, s): s.add(x) return f(s) so that they are PEP 8 conformant? That means (in addition to 4-column indentation at each level) that you should *choose descriptive names* and use them consistently, to help the reader understand the code. -- \“Telling pious lies to trusting children is a form of abuse, | `\plain and simple.” —Daniel Dennett, 2010-01-12 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Gregory Ewing writes: > Not sure where I got [h|t] from -- maybe I was thinking of Prolog?) I've never used Prolog. Erlang is said to have Prolog-like syntax and it uses [h|t], so maybe Prolog uses it too. (Erlang was originally written in Prolog). -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
On 09/10/2016 11:35, Gregory Ewing wrote: Paul Rubin wrote: Gregory Ewing writes: http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ Well, at least I refrained from saying that monads are like burritos! I don't claim that everyone will suddenly understand everything there is to know about monads after reading my essay. But maybe it will help some people understand a little bit. It certainly couldn't help anyone if I didn't write it. I think the easiest way to deal with monads is pretend they don't exist. (I've no idea what they are, but from glancing at your essay, they look complicated.) Even if someone did struggle for a week to figure out what they mean and how to use them, how is anyone else supposed to understand their code? How is anyone going to have confidence that any such code will work? And Python (suddenly remembering which group this is) is supposed to be more accessible than other languages. It's not Haskell. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Paul Rubin wrote: Gregory Ewing writes: http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ Well, at least I refrained from saying that monads are like burritos! I don't claim that everyone will suddenly understand everything there is to know about monads after reading my essay. But maybe it will help some people understand a little bit. It certainly couldn't help anyone if I didn't write it. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Paul Rubin wrote: [h|t] should say h:t . Thanks, corrected. (You can probably tell I'm not a regular Haskell user. Not sure where I got [h|t] from -- maybe I was thinking of Prolog?) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Gregory Ewing writes: > http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html Erratum in Haskell section: Lists in Haskell are linked lists, and [h|t] represents a list whose first element is h and the rest of the list is t. [h|t] should say h:t . -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-based monads essay (Re: Assignment versus binding)
Gregory Ewing writes: > http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ -- https://mail.python.org/mailman/listinfo/python-list
