Simon writes
| I have never, never been tripped up by the liftedness of tuples, but the
| argument that ``we are prepared to pay for laziness so why not this too''
| has a certain masochistic charm. I'll try the effect on performance of
| making all tuple-matching lazy in the nofib suite.
Good idea, but in terms of being tripped up by lifted tuples. Wouldn't
you think it would be good never to have to twiddle a tuple pattern?
| putString = \cs -> case cs of
| (c:cs) -> \s -> case (putChar c) of
| (_,s') -> putString cs s
|
| Never mind the details, just focus on that \s inside the branch of
| the case. I'd *like* now to transform to
|
| putString = \cs s -> case cs of
| (c:cs) -> case (putChar c) of
| (_,s') -> putString cs s
|
| That is, I'd like to float the \s outside the case. Currently
| I'm allowed to do that, and it is advanatageous to do so because
| it brings the two \'s together. (I'll elaborate for anyone who's interested.)
| But with lifted function spaces this transformation is Wrong.
|
| What upsets me about this example is that the sort of inner loop which
| appears a lot in our I/O and array-manipulation system, so I'm reluctant to
| take a performance hit there.
Great! Now, is there a similar argument about transformations and lifted
tuples? Here's at least one example (which I've probably mentioned on
this list before): In a comment in PreludeList, I said
span p xs = (takeWhile p xs, dropWhile p xs)
In fact, this is false, because when xs diverges, the left side is _|_,
but the right side is (_|_,_|_). This represents an important transformation,
known in the imperative world as loop fusion. It would be nice if it
were valid.
Here's another way of looking at this issue: An imperative routine can
easily have multiple effects, whereas a function (for syntactic reasons,
essentially) must return a tuple to have multiple results. It's important
that this artificial packaging of values not have any cost. If we insist
that a tuple has some meaning beyond the meanings of its components, we
run the risk of paying for that distinction. (I think this is what Arvind
was referring to when he mentioned the importance of tuple elimination in
the Id compiler.) I think this is rather like the problems Simon uncovered,
arising from considering a function to be anything more than its extensional
behavior.
--Joe
