Strange error in show for datatype

[Thomas Hallgren]

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/