On Thu, 29 Jan 2004, Ashley Yakeley wrote:
Ben Rudiak-Gould [EMAIL PROTECTED] 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
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
