Hi! One of the nice things of laziness is that it allows us to
express things concisely. For instance:
func a b =
let ta = transmogrify a in
case b of
B1 -> doSomething
B2 -> doSomethingElse ta
B3 -> doAnotherThing ta
It is clear why having this let-expression is a good thing. We can
"transmogrify a" only once, and then use the "transmogrified a" only
when (if) needed. In this case, one branch of the case expression
doesn't need it, in which case we've effectively paid nothing for it, no
matter how complex and time/resource-consuming "transmogrify" is.
So far, so good.
Now, I need to interoperate with external code using FFI. I have a
function that gets called from outside, and gets its parameters as a
pointer to a structure, so:
func p = do
a <- peekByteOff p 0
b <- peekByteOff p 4
case b of
B1 -> doSomething
B2 -> doSomethingElse a
B3 -> doAnotherThing a
Now I see myself with a little dilemma. This code looks a lot like
the first version, where instead of "transmogrifying", we just read the
value from the structure through the use of the pointer. Reading the
value from memory can't be very time consuming, but it has to cost
something. If I don't want to pay for that cost, then I have to convert
the code as in:
func p =
b <- peekByteOff p 4
case b of
B1 -> doSomething
B2 -> do { a <- peekByteOff p 0; doSomethingElse a }
B3 -> do { a <- peekByteOff p 0; doAnotherThing a }
Repetition, repetition, repetition. This does get tedious. Especially
when the case expression has many branches, and there are many variables
in the structure that might or might not be needed. So you see my
dilemma. It's _very_ tempting to do something like:
func p = do
let a = unsafePerformIO $ peekByteOff p 0
b <- peekByteOff p 4
case b of
B1 -> doSomething
B2 -> doSomethingElse a
B3 -> doAnotherThing a
I mean... the contents of "p" are never going to be modified, so this
"feels" right on some level. But we're effectively breaking the pureness
of the language. I mean... this function could be called twice with the
same _pointer_ but different data stores in the structure, which can
(and maybe will) cause problems depending on how evaluation proceeds.
Is there a way to handle this nicely? I recently read about the Clean
language. It seems like it allows (and relies) in an extension to the
type system, that allows the program to specify uniqueness of values, so
that two pointers values might be represented using the same bits, but
they'd still be considered distinct values. But no such thing in
Haskell. Maybe a good thing... trying to understand the whole
explanation of uniqueness in Clean made my head spin. But still...
Is it known what GHC, for instance, will do to this code when
optimizing? Might it just do the right thing? Probably the C optimizer
would take care of it. It feels to me that's my only hope.
But it'd be great if the "haskell" part of the compiler could take
care of it natively. This is something that I've been thinking about. I
mean... the IO monad does seem to impose too much sometimes. Any IO
action always is assumed to modify the "external world" (affect the
execution of the actions that come after it), whether it does or not:
do
peekByteOff p 0 -- totally useless, but it needs to be performed
anyway before "returning"
return ()
do
a <- peekByteOff p 0
b <- peekByteOff p 4 -- could be done before "a"
Somehow, it feels like it'd be a good thing to be able to limit the
scope of IO actions. Going too far would complicate it enormously:
do
a <- readFile "file"
b <- peekByteOff p 4 -- could be done in any order, really, but how
would you express it... maybe "domains of influence", like "filesystem"
and "memory"... not very clear.
do
a <- peekByteOff p1 0
pokeByteOff p2 0 1234 -- could be done in any order, as long as p1
and p2 don't alias each other (yuck!)
So I wouldn't want to go that far... yet :). A global thing might be
an improvement. I'm aware it wouldn't be a monad anymore, but could it
be something else?
I hope this is all pointless :-).
JCAB
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
