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