[Resent with permission of author -=chak] I'm beginning to find implicit parameters *extremely* useful, so I think it's important to get this right. I have some code that will have to change, but not as much as I will have in a couple of years...! I find adding a keyword to implicit parameter declarations, as in let dynamic ?base = 10 in addBase 5 or let nonrec ?base = 10 in addBase 5 just plain ugly. The question mark already indicates that this is an implicit parameter binding, there is no need for another keyword to say the same thing. This would make sense to me if implicit parameter names were lexically the same as other identifiers -- but THAT would be a big mistake! Without wanting to stir up language wars, this idea reminds me of ML rather than Haskell. One of the great strengths of Haskell's syntax, in my opinion, is just that it is so concise. Let's keep it that way! I am against let ?base := 10 in addBase 5 also -- not because := is already a constructor, but because I have another proposal for how to use it! From time to time I argue for a "monomorphic binding" operator, a substitute for the monomorphism restriction, which has become even more necessary with the addition of implicit parameters. (See my "Global Variables in Haskell" paper for a discussion and example). I'd like to reserve := for monomorphic binding. That leaves plain let bindings -- and in that case, why not also where, case, do, and lambda? There was also a mention of extending the implicit parameter story to work as recursive bindings, but I don't know any details here. It would certainly strengthen the case for using plain `let'. Why not recursive bindings? Why not mix implicitly bound variables and explicitly bound ones in the same pattern? This is surely the most orthogonal and powerful mechanism. The question is whether such bindings always have a clear meaning. I claim they do. For each implicitly bound variable ?x, let's assume that x is a fresh variable. Let e be an expression in the scope of ?x. Then I claim that replacing each such e by e with ?x = x and replacing the binding occurrence of ?x by x gives a sensible meaning to the extended language. For example, let ?fac n = if n==0 then 1 else n*fac? (n-1) in e means let fac n = if n==0 then 1 else n*fac? (n-1) with fac? = fac in e with fac? = fac And (\?x -> e) means (\x -> e with ?x = x) The only funny thing is that, because of the way implicit parameters are passed, their types cannot be generalised. John
As one of the authors let me give some responses. First of all, note that the implicit parameters paper did not attempt to give an account of implicit parameters that would fit seamlessly into Haskell. It was language feature within a hypothetical lambda calculus with its own type system etc. Indeed, there are a number of respects in which the existing implementations do not reflect correctly the design space the paper described. In particular, the impact of Haskell monomorphism restriction was identified as an issue that needs to be addressed to achieve a reasonable overall design. There's much more than just syntax at issue here!
There was also a mention of extending the implicit parameter story to work as recursive bindings, but I don't know any details here. It would certainly strengthen the case for using plain `let'.
Why not recursive bindings? Why not mix implicitly bound variables and explicitly bound ones in the same pattern? This is surely the most orthogonal and powerful mechanism.
The question is whether such bindings always have a clear meaning. I claim
Actually, that's not the question. The question is whether given their expected use, recursive or non-recursive binding is the most useful. We thought that the most common use for implicit parameters would be to be able to provide default values that could be overridden downstream. For example, suppose we have a graphics context passed in by default to some GUI code. Then we might want to update the context by e.g. e with ?cxt = ?cxt{color = Red} It would be a real pain (we guessed) to have to deal with recursive bindings all the time. Is there an argument that we made the wrong choice? John
participants (2)
-
John Hughes -
John Launchbury