RFC: Syntax for implicit parameter bindings

[John Launchbury]

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