[Haskell] Re: Implicit parameters redux

[Ben Rudiak-Gould]

On Thu, 29 Jan 2004, Ashley Yakeley wrote:

>  Ben Rudiak-Gould <benrg at dark.darkweb.com> wrote:
> 
> > Another extension I proposed is that the "name" of an implicit return
> > value can include type parameters: thus %foo Int and %foo Char would be
> > treated as though they had different names.
> 
> This bit doesn't seem very polymorphic-friendly?

Well, there can be type variables there too.

The issue is that there needs to be a source of fresh names for
newly-created state threads, and the simplest solution I could think of
was to return an existentially-quantified %foo s. It's supposed to work
along the lines of a (Num a, Num b) context, where the type checker
doesn't merge the constraints because it can't prove they're equal, even
though it also can't prove they aren't. It's not clear that it's formally
sound, though.

Also, it would be nice if the type-class system could be implemented in
terms of implicit parameters (plus sugar), and this extension would help
with that.

It might be possible to just parameterize the type of the implicit
parameter instead of its name, and decree that merging happens by name and
type.

-- Ben