An earlier note on students reactions to the imperative style forced on them by
some Haskell libraries ("do ...") is interesting, and seems similar to an
observation in a project I was developing for students; making a version of a
simple lab from previous SML assignment.
It uses a dictionary to do some statistics for a text analysis, but since the
dictionary is read at a leaf node of the analysis algorithm, that function must
be IO(), and thus the analysis using it also, ... etc. all the way up to the
top.
So the implication of the rules:
1) all IO must start from the top level, and there is only one IO
2) you cannot extract anything from an IO
Seems to be that the whole program structure becomes a series of do... blocks,
which is basically a sequential imperative looking style.
The general advice of "Strive to keep as much of the program pure as possible"
thus seems difficult.
An option I suppose would be to read the dictionary at the top level, and then
pass it all the way down to the analysis routine that uses it, but that exposes
the details of how the analysis is done, and couples the top and bottom levels
of the previously modular functions.
While this is all logical and understandable, it is quite different than how I
did this in SML; where I could encapsulate the IO in the analysis function. It
was a local secret of the analysis what data it needed, and where it came from.
Note that (of course...) if the dictionary was static and an internal data
structure, then this would all go away. It is interesting to me (and curious at
first) that one could not somehow treat a "constant" data definition file
resource in a more encapsulated manner, and not have it ripple all the way up
through the program because it was "impure" once converted to an external
definition (=IO). My first impulse was to read the dictionary in a do... and
then try to extract it and go merrily on, but that won't work - by design of
course!
Considering something like a properties file in Java, it thus seems like every
part of a program wanting to use these, must either be passed some global
definition, or become a leaf on a hierarchy of do.. blocks if it does its own
IO to read the properties.
Anyway, while the more precise treatment and isolation of IO in Haskell seems
valuable, it also seems to have a notable impact on the lack of ability to
encapsulate and decouple parts of the program, and keep things pure between
them. I suppose this is because that by definition, once you have touched IO at
any leaf of a program, the whole thing is impure all the way up the functional
tree.
I rather had the feeling expressed by Robert Harper:
" Once you're in the IO monad, you're stuck there forever, and are reduced to
Algol-style imperative programming."
(http://existentialtype.wordpress.com/2011/05/01/of-course-ml-has-monads/)
Just an observation, in case I am missing something - being fairly new to
Haskell. I suppose this is just an adjustment to proper treatment of the
impurity of IO, but the effect on program structure was not good. :-)
-------------------------------------------
> -----Original Message-----
> Subject: Haskell-Cafe Digest, Vol 93, Issue 58
> Now, I have a personal pedagogical comment.
>A few months ago I gave to some 30 students an
>The results? A true DISASTER!
> The OpenGL bindings in Haskell are hardly "functional".
> You make us sweat with generic functional patterns, laziness, exquisite
> typing, non-determinism monad, parsing tools, etc.,
> and then you throw us into this ugly imperativism !
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
