On Tuesday, October 18, 2016 at 2:55:07 PM UTC+5:30, Chris Angelico wrote:
> On Fri, Oct 14, 2016 at 9:52 AM, Gregory Ewing wrote:
> > A bit more on SMFs, and then some I/O.
> >
> > http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads2.html
> Finally finished reading this - it's been up in a tab in Chrome for
> the past few days.
> So here's how I summarize your explanation of monads:
> 1) Functional programming can describe states and transitions.
> 2) We can cheat with those by hiding the states and implementing
> things imperatively.
> 3) Once we're already implementing things imperatively, we can do I/O.

Seems like a reasonable summary (to me; would like to hear Greg tho')

> If you want to prove to me that monads are still functional, *REVERSE*
> your transformation in the original article. You can take your
> original set-builder monad and turn it into genuinely functional code;
> show me that you can do the same with I/O. Otherwise, what you're
> really saying is "we can cheat until we can do I/O",

Dont understand the 'until'

> not "we can do I/O in a functional way".

Not sure what you mean by 'cheat' and 'functional'
I have a feeling you are assuming a definition of 'functional that is
unusable in practice such as "programming without any effects"

People who actually use FP to do serious work probably need to use a more
nuanced definition such as
- being very explicit about effects (disallowing side-effects is quite 
different from disallowing all effects)
- making sure the effects are well documented
  'Documented' could be quite different: eg in scheme its an informal naming
   convention — names containing a '!' and pronouned SHRIEK are non-functional
   In haskell its more formal: effectful things must have monadic types

One thing probably is correct in what you are saying (if you are saying!):
The IO monad cannot be programmed at the vanilla user/programmer level but must 
be hardwired into the system (for an FPL of course; for python its all demo 

Reply via email to