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
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 kn
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 (L
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
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) == "[]"
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 Voi
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
> > s
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
>
> T
| > 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 embarassin
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 fundamenta
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 ([] ::
> 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 _ = ("elemen
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 empty types for phantom-type purposes, so GHC now lets you say
>
> data
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 tha
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 witn
| So, obviously, the next version of Haskell should have a type system
| with subtyping, don't you agree? :-)
It's always delightful to find that some awkward fumbling has
been Done Properly by someone else earlier. My claim was that
forall a. Show a => T
could be implemented by pass
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"]) ==> [
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
>
"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 c
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 e
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 mailin
Hi,
For a change, a teacher asking for help on behalf of a student
I have a student who wants to emulate S-expressions of Lisp in Haskell. He
came up with the following data type:
data LispList t = Atom t | LispList [LispList t] | Str [Char]
This works just fine. He then wanted to make it
22 matches
Mail list logo
