Hi all, Now we are talking about implicit parameters, let us take up the following problem with them on the Haskell mailing list too. Suppose I have the following function definition: app :: (?ys :: [a]) => [a] -> [a] app xs = case ?ys of [] -> xs (y:ys') -> y : (app xs with ?ys = ys') This function appends its argument to its implicit argument, by recursively changing the implicit argument. For example: Hugs> app [1,2] with ?ys = [3,4] [3,4,1,2] So far so good! Now, since Haskell has type inference, we can leave out the type signature: -- app :: (?ys :: [a]) => [a] -> [a] app xs = case ?ys of [] -> xs (y:ys') -> y : (app xs with ?ys = ys') Let us check if it still works again: Hugs> app [1,2] with ?ys = [3,4] [3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,{Interrupted!} And, stunningly, it doesn't! Why doesn't this work? That is because type inference assumes that the body of `app' is monomorphic, i.e. has no context in its type. Therefore, the recursive call to app where ?ys is changed, had no effect at all. It works with the type signature there, because in order to implement type checking (note: not type inference) with polymorphic recursion demands to use the stated type in checking the body of the function. Mark Shields, Simon Peyton-Jones, and I, and also Jörgen Gustavsson have been discussing several modest solutions to this (we believe it is not needed to do full type inference that can deal with polymorphic recursion to solve this problem). My questiona are: Were the designers of the implicit parameters paper aware of this problem when they wrote the paper? If so, they probably did not think this was a big problem. Do people in general think this is a problem? /Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen Chalmers University, Gothenburg, Sweden.
On Monday 04 February 2002 01:58 am, Koen Claessen wrote:
Hi all,
Now we are talking about implicit parameters, let us take up the following problem with them on the Haskell mailing list too.
[implicit parameters are not propogated down recursive definitions without a type signature]
My questiona are: Were the designers of the implicit parameters paper aware of this problem when they wrote the paper? If so, they probably did not think this was a big problem. Do people in general think this is a problem?
I think we overlooked it when the paper was written, but I reported this at the Haskell Implementers Meeting in Egmond. At the time the only solution that occurred to me was to essentially do type inference twice - the first time to figure out what implicit parameters the definition depends on, and the second time with a weak signature provided that has those implicit parameters on board to get the effect of the user having provided the signature. I believe you guys have looked at something like this as well. But I find that solution fairly unsatisfactory, and have been hoping something nicer will come along.... I consider this to be a problem, but not enough of one that I've managed to spend time finding a solution ;-) --Jeff
My questiona are: Were the designers of the implicit parameters paper aware of this problem when they wrote the paper? If so, they probably did not think this was a big problem. Do people in general think this is a problem?
We certainly were aware. It is a problem, and a big one. The monomorphism restriction (MR) was (barely) acceptable in Haskell 98 because at least the final value returned by the program was not changed by this kludge kicking in. But, as we point out in the paper, implicit parameters and the MR are simply incompatible. One of them has to go. As John Hughes intimated, this debate is part of a much larger issue as to how Haskell handles type schemes versus types, and implicit parameters show that type schemes can arise from causes other than polymorphism. In the long term, should Haskell maintain a distinction between types and type schemes? Between call-by-name and call-by-need? Should type schemes be permitted everywhere? If so, should inference do it's best and simply report when ambiguities arise? Etc. etc. I think the time has come for us to address these types of questions from a fundamental basis, not simply as fixes to the existing infrastructure. Otherwise we'll never be able to budge from the sludge of the kludge... John
participants (3)
-
Jeffrey R. Lewis -
John Launchbury -
Koen Claessen