Olaf Chitil wrote:
>Anyway, I find all these suggestions about occurrence and variance of
>type variables rather complicated.
>
As I suspected, some people are afraid of subtypes :-) But variances are
not that difficult to compute. For example, it is part of the O'Haskell
type system, which is implemented in ohugs [1,2].
Koen Claessen wrote:
> Hugs> show ([] :: [Char])
> "\"\""
>
> Hugs> show ([] :: [Int])
> "[]"
>
Oops. I was wrong when I wrote that the proposed way of dealing with
ambiguity gives the same result as if you manually disambiguate whith an
arbitrary type. Sorry.
As an example of why passing undefined dictionaries fails, consider how
'show ([]::[T])' for some type T is computed: it would first call the
show method of the Show instance for lists, which in turn calls the
showList method for the type T. Hence, if we pass an undefined
dictionary for Show a to compute the result of 'show [] :: Show a =>
String', we would try to extract showList from the undefined dictionary,
leading to an undefined result, rather than a string like "[]"...
But I think the method of simplifying types based on ideas from
subtyping and using instances for the Empty type (which actually
contains _|_ , like all other types), could still be useful. It should
not be seen as a semantics preserving transformation, but as a new kind
of defaulting mechanism, where default instances are specified by giving
instance declarations for the Empty type.
For the primary example with the Show class, with this approach, adding
instance Show Empty
would be enough to get
Hugs> show []
"[]"
thanks to the default for the showList method in the Show class. Things like
Hugs> show (Left True,Nothing)
"(Left True,Nothing)"
would also work although the above instance declaration in effect leaves
the show method for Empty undefined.
(Another way to achieve this would perhaps be to just extend the
current default declarations to allow defaults to be declared for
arbitrary classes, not just the Num class...)
Simon-Peyton Jones wrote:
>... And you're telling us that the subtyping folk worked this
>out yonks ago. Excellent! (Reference, for this particular point?)
>
As I guess has become aparent, I don't have a reference to a complete
solution to this problem, but using ideas from subtyping to solve this
has been in the back of my head for many years, although it seems I have
been too naive, not taking laziness and coherence into account. My
underlying intuition comes from working with ideas from papers like [3]
and [4].
>My implemention mood has
>suddenly past.
>
Does this mail do anything for your implementation mood?
Thomas Hallgren
PS By the way, perhaps theorems for free (e.g., [5]) also have something
to contribute to the solution of this problem?
[1] http://www.cs.chalmers.se/~nordland/ohaskell/
[2] http://www.cs.chalmers.se/~nordland/ohugs/
[3]
http://www.acm.org/pubs/citations/journals/surveys/1985-17-4/p471-cardelli/
[4] http://www.cs.berkeley.edu/~aiken/publications/papers/fpca93.ps
[5] http://www.acm.org/pubs/citations/proceedings/fp/99370/p347-wadler/
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
