| | The solution to the problem is that Hugs refuses to print values of
| | polymorphic type!
|
| Not so. With the default settings, Hugs refuses to print values of
| polymorphic type in situations where the output might potentially
| differ with different choices of that type. So Hugs will happily
| accept something like:
|
| Main> [\x y -> x, \u v -> v]
| [<<function>>,<<function>>]
| Main>
|
| The type here is [a -> a -> a], but because the standard method for
| showing a function doesn't depend on the types of the argument or
| result (it always displays "<<function>>"), we can go ahead and "show"
| the result.
Yes, that's clear to me. I should have said that Hugs refuses to print
values of polymorphic type where there is a `Show' context on the
respective variable(s). Right?
(Show a) => [a] is refused
[a -> a -> a] is not
| | Could Hugs be a bit more clever here?
|
| I don't know. Would a reminder to read the user manual help? :-)
| There one might rediscover the command line option -u, which turns
| off Hugs use of "show", and substitutes a built-in printer instead.
| You loose some functionality this way, but now all your examples
| work as you would like, with or without a deriving clause.
Did you use this feature lately? The built-in printer has changed
in the latest (?) version of Hugs. Look
> hugs -u Tree.lhs
Main> tl (Node Empty 2 Empty)
Tree_Empty
The value constructors are prefixed with the type contructor. If the
terms are longer the output is quite hard to read.
| [...] In another message you
| suggested: "The point is that if the type involves a type variable
| we can substitute an arbitrary dictionary because it is never used!"
| But I'm afraid this is simply not correct. Think again about an
| example like show [] to see why.
Hmm. Perhaps I am missing something but why is my statement not
correct? [Isn't this a consequence of parametricity?] `show []'
should produce `[]' and `show ""' should produce `""'. If the
argument of `show' has type `forall a.[a]', then we can supply
any dictionary we like. Because an element of type `forall a.[a]'
cannot contain any elements.
Let's make an experiment. Assume that Hugs ignores the error message
and proceeds printing the value. Can you imagine a situation where the
output is not satisfactory?
| Let me also point out that while the -u option might help in this
| particular situation, it doesn't address the fundamental in the
| underlying system. For example, [] == [] will also be rejected,
| not because it can't show the resulting Boolean (it can!), but
| because it needs to know what type of lists are being compared.
Exactly, that's why I think that the `-u' switch is only a hack
around. Here the arguments of `==' have both type `forall a.[a]'.
Again, any dictionary should work because it is never used! But I
agree that some further thought is necessary here.
Cheers, Ralf
