Hi again,
My question about my student's problem surely stirred an interesting and
clarifying discussion. Still, I have a question.
Reconsider the example. There's a data type
data LispList t = Atom t | LispList [LispList t] | Str [Char]
and an instance declaration
instance Show t = Show
On Fri, 5 Oct 2001, Bjorn Lisper wrote:
My question about my student's problem surely stirred an interesting and
clarifying discussion. Still, I have a question.
Reconsider the example.
...
only the first. So far as I can see there should relly be no ambiguity here!
I'd really like to know
Dylan Thurston [EMAIL PROTECTED] points out my mistake:
Strictness alas matters. Here's the witness:
class Num a = ZeroList a where
consZero :: a - [a]
consZero _ = 0:xs
Err, Num a is already a bad context by Simon's criterion because of
fromInteger, which is what ultimately
On Wed, Oct 03, 2001 at 11:52:30AM -0400, Jan-Willem Maessen wrote:
Earlier, Simon says:
Indeed, if none of the classes have a method that returns
an a-value without also consuming one (urk-- strictly, I think, sigh)
then the same holds.
Strictness alas matters. Here's the witness:
On Thu, Oct 04, 2001 at 12:36:55AM -0700, Simon Peyton-Jones wrote:
So in fact, all we need do is:
for each class, find the variance of each of its parameters
in an ambiguous type, zap any positive parameters to Empty
That sounds pretty easy. We don't need Haskell 2 for that.
My claim was that
forall a. Show a = T
could be implemented by passing a bottom dictionary for Show.
Excuse me, but Jan-Willem Maessen has already shown that this
implementation can give unexpected results. A simple example:
instance Show MyType where
shows _ = (element of
Olaf Chitil wrote:
| Admittedly, many Haskell beginners fall into the `show
| []' trap.
Indeed. And this is a perfect example of the fact that all
this bottom-dictionary passing does not work. The type of
the list still matters though:
Hugs show ([] :: [Char])
\\
Hugs show ([] ::
Koen Cleassen wrote:
Indeed. And this is a perfect example of the fact that all
this bottom-dictionary passing does not work. The type of
the list still matters though:
Hugs show ([] :: [Char])
\\
Hugs show ([] :: [Int])
[]
Koen is absolutely right. A fundamental property of
| My claim was that
|
| forall a. Show a = T
|
| could be implemented by passing a bottom dictionary for Show.
|
| Excuse me, but Jan-Willem Maessen has already shown that this
| implementation can give unexpected results.
Yes, I was quite wrong about that. How embarassing.
Simon Peyton-Jones wrote:
Consider:
data T a = T1 Int | T2 a
It's clear that (T1 Int) has no a's in it, not even bottom. Mark Shields
and ruminated in the corridor about a kind system to make this apparent.
That is, T1 would have type
T1 :: forall a::Pure . Int - T a
Then if we
On Thu, Oct 04, 2001 at 09:23:10AM +, Marcin 'Qrczak' Kowalczyk wrote:
Thu, 4 Oct 2001 00:36:55 -0700, Simon Peyton-Jones [EMAIL PROTECTED] pisze:
Void was a type with one element. What we really want here is
a type with no elements. It's also useful to be able to introduce
such
Thu, 4 Oct 2001 14:29:43 +0100, Ross Paterson [EMAIL PROTECTED] pisze:
So this extension adds something we already have in Haskell 98, with either
newtype Void = Void Void
ordata Void = Void !Void
Theoretically yes, but this introduces a warning that the data
constructor Void is
Thu, 4 Oct 2001 06:05:16 -0700, Simon Peyton-Jones [EMAIL PROTECTED] pisze:
data T a = T1 Int | T2 a
It's clear that (T1 Int) has no a's in it, not even bottom.
instance Show a = Show (T a) where
show x = show (tail [case x of T2 y - y])
We have show (T1 0 :: T Int) == [], show
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
This problem is probably caused by the unbound type variable in
values like (Str HEJ).
Try giving a specific type as the parameter to LispList:
(Str HEJ :: LispList Int)
The error message here could me more informative!
John
___
Haskell mailing
Interesting. The difficulty (which GHCi has too) is this. Consider
expr = Str foo
msg = show expr
Hugs wants to print msg. What are the types?
expr :: forall a. LispList a
msg :: forall a. Show a = String
Urk! What Show dictionary should Hugs use when
Simon Peyton-Jones [EMAIL PROTECTED] tries his hand at
inventing free theorems for qualified types, then concludes:
In which case we could report ambiguity a bit less often. How
useful this would be I don't know.
A lot. Any time one is testing the empty case of a bulk type. If
you're coding
Simon Peyton-Jones wrote:
...
msg :: forall a. Show a = String
Urk! What Show dictionary should Hugs use when evaluating msg?
You may say it doesn't matter, but in general that's not the case.
In the case of class Num, for example, we might have
expr = 3+4
msg =
Bjorn Lisper [EMAIL PROTECTED] writes:
data LispList t = Atom t | LispList [LispList t] | Str [Char]
instance Show t = Show (LispList t) where
show (Atom t) = show t
show (LispList t) = show t
show (Str t) = show t
hugsprompt (LispList [Atom 1, Str HEJ]) == [1,HEJ]
19 matches
Mail list logo
