On Thu, 29 Jan 2004, Ashley Yakeley wrote:
Ben Rudiak-Gould <benrg@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