[Haskell-cafe] IO is a bad example for Monads [was: do]

[Conal Elliott]

It so happens that Haskell currently insists on main :: IO ().  That's
simple to fix, however, and with great pay-off.  Suppose instead main :: TV
a (where I'm omitting the other TV type args for simplicity.)  Then a
program could not only be run, but also composed with other programs.  They
could even be composed by the end-user *while running*, as in Eros.

Similarly, ghci implicitly inserts "print" when given a non-IO type.  We
could make that mechanism a little more general, and allow implicit
insertions of other kinds of renderers, for purely functional images, music,
2D & 3D geometry & animation, interactive GUIs, etc.

  - Conal

On Dec 9, 2007 4:38 PM, Lennart Augustsson <lennart at augustsson.net> wrote:

> I doubt all imperative programming will be banished from Haskell anytime
> soon.  I really, really wish we had all the nice abstractions in place
> already, but we just don't.
>
> You can't write any program in Haskell without using IO, because the type
> of main involves IO.
> And currently I believe that almost any real program will have to involve
> IO.
> (BTW, the only H98 IO avoiding wrapper, interact, was included in Haskell
> because I insisted on it.)
> It's just from my experience.  No matter how pure your program is, here
> and there it will be interacting with the rest of the world.
>
>   -- Lennart
>
>
> On Dec 9, 2007 10:16 PM, Conal Elliott <conal at conal.net> wrote:
>
> > Thanks.  If I'm tracking, your real point is that imperative programming
> > in Haskell is still useful enough to keep around.  I agree.
> >
> > I'm still puzzled.  Did you understand something I said, or maybe
> > someone else said, as suggesting that imperative programming be removed from
> > Haskell any time soon?
> >
> > > It's also important to teach people to stay away from IO whenever
> > possible, but it's simply not always possible.
> >
> > How can we possibly teach them to stay away from IO where possible if
> > we're also telling them that they can't write *any* real program without
> > using IO?
> >
> > Cheers, - Conal
> >
> >
> > On Dec 9, 2007 12:02 PM, Lennart Augustsson <lennart at augustsson.net >
> > wrote:
> >
> > > Conal,
> > >
> > > It's true that you can avoid using IO (except for a wrapper) for
> > > certain kinds of programs.
> > > For instance, if all you want is a String->String function, or some
> > > GUI program (you forgot to mention fudgets, which was the first wrapper of
> > > this kind) then you can ignore IO and just use a nice wrapper.
> > >
> > > But if someone asks me how to traverse a directory tree, invoking the
> > > 'file' program for each ',o' file and then renaming it if it's a text file,
> > > then what should I answer?  "Sorry, you can't do that in Haskell."  or "You
> > > need to use the IO monad."?
> > > I prefer the latter answer, and I think people who learn Haskell need
> > > to learn something about how you do some of the things that are easy in
> > > other languages.
> > >
> > > It's also important to teach people to stay away from IO whenever
> > > possible, but it's simply not always possible.
> > >
> > >   -- Lennart
> > >
> > >
> > > On Dec 9, 2007 5:31 PM, Conal Elliott <conal at conal.net > wrote:
> > >
> > > > > IO is important because you can't write any real program without
> > > > using it.
> > > >
> > > > Ouch!  I get awfully discouraged when I read statements like this
> > > > one.  The more people who believe it, the more true it becomes.  If you want
> > > > to do functional programming, instead of imperative programming in a
> > > > functional language, you can.  For instance, write real, interactive
> > > > programs in FRP, phooey, or TV.  And if you do, you'll get semantic
> > > > simplicity, powerful & simpler reasoning, safety and composability.
> > > >
> > > >   - Conal
> > > >
> > > > On Dec 8, 2007 1:26 AM, Lennart Augustsson <lennart at augustsson.net >
> > > > wrote:
> > > >
> > > > > I agree with Dan here.
> > > > >
> > > > > IO is important because you can't write any real program without
> > > > > using it.
> > > > > So why not teach enough of it to get people off the ground
> > > > > straight away?
> > > > >
> > > > > People who hang around long enough to do some more Haskell
> > > > > programming
> > > > > will run into the other monads sooner or later.  But IO is an
> > > > > unavoidable step to
> > > > > writing Haskell programs.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Dec 4, 2007 5:11 AM, Dan Piponi < dpiponi at gmail.com> wrote:
> > > > >
> > > > > > On Dec 3, 2007 6:36 PM, Ben Franksen < ben.franksen at online.de>
> > > > > > wrote:
> > > > > > > then the special features of IO
> > > > > > > will remain associated with monads in general, leading to a
> > > > > > whole jumble of
> > > > > > > completely wrong ideas about them.
> > > > > >
> > > > > > As I only learnt about monads a couple of years ago, the process
> > > > > > is
> > > > > > still fresh in my mind. I wasted quite a bit of time labouring
> > > > > > under
> > > > > > the impression that monads were primarily about sequencing. But
> > > > > > that
> > > > > > wasn't because I incorrectly generalised from IO. It was because
> > > > > > countless people out there explicitly said they were about
> > > > > > sequencing.
> > > > > > I suspect that if courses started with the List monad there'd be
> > > > > > countless blogs telling people that monads are a way to
> > > > > > eliminate
> > > > > > loops from your code like the way list comprehensions are used
> > > > > > in
> > > > > > Python.
> > > > > >
> > > > > > > This is yet another problem with IO as the standard example
> > > > > > for monads: its
> > > > > > > effect base is huge and poorly structured.
> > > > > >
> > > > > > You don't teach *all* of IO to students in one go!
> > > > > >
> > > > > > > This again makes it difficult to
> > > > > > > see exactly which intuitions about IO can be generalized to
> > > > > > arbitrary
> > > > > > > monads and which not.
> > > > > >
> > > > > > That's true of any monad. IO is unique. [] is unique. Cont is
> > > > > > unique.
> > > > > > All of them can lead you down the garden path. You need to see
> > > > > > multiple monads, and it helps if you can sneak an example under
> > > > > > a
> > > > > > student's nose so they can already reason about monads before
> > > > > > they
> > > > > > even know what a monad is.
> > > > > >
> > > > > > > What is pointless about failure and how to handle it?
> > > > > >
> > > > > > It's pointless when you're still trying to make your first
> > > > > > tweaks to
> > > > > > "Hello, World!" work.
> > > > > > --
> > > > > > Dan
> > > > > > _______________________________________________
> > > > > > Haskell-Cafe mailing list
> > > > > > Haskell-Cafe at haskell.org
> > > > > > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Haskell-Cafe mailing list
> > > > > Haskell-Cafe at haskell.org
> > > > > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > > > >
> > > > >
> > > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20071209/4c5b0860/attachment.htm