October 2001 - Haskell

announce: PARSEC
by Daan Leijen 04 Oct '01

04 Oct '01

I am pleased to announce a new release of PARSEC, a fast monadic parser library for Haskell. The PARSEC library is written for practice and uses some novel techniques to improve its speed and to give good error messages. It ships with extensive support libraries and documentation. PARSEC is distributed with GHC but GHC 5.02 unfortunately includes an older version. PARSEC can be downloaded from: http://www.cs.uu.nl/people/daan/parsec.html I would like to thank the many(!) people that have written me with advice and comments that improved the library. Have fun, Daan Leijen. ------------------------------------------------------------- New features: * The ability to use a seperate lexer. The parsers work on any kind of token stream instead of just characters. * A user definable state, very convenient to maintain a symbol table. * A module to parse permutation phrases [1]. * A parameterized lexical analyser module. * New combinators like "sepEndBy" ------------------------------------------------------------- [1] Arthur Baars, Andres Loh and Doaitse Swierstra "Parsing Permutation Phrases" Proceedings of the Haskell Workshop 2001.

2 1

Haskell 98 Report: October release
by Simon Peyton-Jones 04 Oct '01

04 Oct '01

It's that time of the month! Another iteration of the Revised Haskell 98 Report! http://research.microsoft.com/~simonpj/haskell98-revised I'm happy to say that my orbit is diminishing in radius and I shall shortly turn into a black hole. Seriously, the main things I've done this time (apart from a few more typos) is to * revise yet again the wording about export lists * revoke the change that removed Ord as a superclass of Ix But there are other minor things: grep for "Oct 2001" in the list of chages. Feedback please... Simon

4 3

Re: Strange error in show for datatype
by Marcin 'Qrczak' Kowalczyk 04 Oct '01

04 Oct '01

Thu, 4 Oct 2001 14:29:43 +0100, Ross Paterson <ross(a)soi.city.ac.uk> pisze: > So this extension adds something we already have in Haskell 98, with either > > newtype Void = Void Void > or data Void = Void !Void Theoretically yes, but this introduces a warning that the data constructor Void is not used, and it doesn't look clear. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Strange error in show for datatype
by Marcin 'Qrczak' Kowalczyk 04 Oct '01

04 Oct '01

Thu, 4 Oct 2001 00:36:55 -0700, Simon Peyton-Jones <simonpj(a)microsoft.com> 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 T > > and get a type T with no values. I think both Void and T have bottom, and both have no other values. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

2 1

RE: Strange error in show for datatype
by Simon Peyton-Jones 04 Oct '01

04 Oct '01

| > 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. But there's still something lurking there. 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 see (forall a::Pure. Show a => <type>) we're justified in fixing a to Empty. You need a sub-kinding system to make this work, so the cost has just gone up. My implemention mood has suddenly past. Isn't laziness wonderful? Simon

2 1

RE: Strange error in show for datatype
by Simon Peyton-Jones 04 Oct '01

04 Oct '01

| 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 passing a bottom dictionary for Show. I didn't say this, but the obvious thing to do is to fix 'a' to be some vacuous type Empty, and arrange that Empty is an instance of every class, with a bottom dictionary. And you're telling us that the subtyping folk worked this out yonks ago. Excellent! (Reference, for this particular point?) In a system with subtyping this would work even if T contained a free, as you say. But even in a system *without* subtyping, if 'a' is not free in T, we can safely remove the 'forall a' and fix a=Empty. (A calling context can only "see" the types in T, so this places no constraints on the calling context, which is why we don't need subtyping.) I think this is what your PPS suggested, yes? 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. I feel a little implementation coming on. Hmm. One question. Suppose I have forall a. C (a->Int) Int => T and C is positive in its first parameter. Can I zap 'a' to Empty? It looks as if it still occurs positively. What about data types? | PS In some previous version of Haskell (1.3?), the Prelude defined an | empty type called Void, but it has since been removed. Apparently, | people didn't see the potential of Void... 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 T and get a type T with no values. Simon

5 4

Lexical syntax and context free grammar in report
by Ian Lynagh 04 Oct '01

04 Oct '01

I've just looked at the revised lexical syntax and qop is a production of lexeme, but qop is still defined in the context free grammar rather than the lexical syntax. Also, in the context free grammar, the last production for aexp is aexp_{qcon} { fbind1 , ... , fbindn } but I believe should be aexp_<qcon> { fbind1 , ... , fbindn } Thanks Ian, who's going to have to rejig his code some time for the revised report :-(

1 0

H98: specialids and specialops
by Simon Peyton-Jones 04 Oct '01

04 Oct '01

Folks, George Russell and Wolfram Karl have both noticed that 'specialid' and 'specialop' are defined in the H98 syntax, but never used. Having looked at it, I propose to 1. Remove all references to 'specialid' and 'specialop' 2. Instead, add the following paragraph to 5.3 (Import declarations) "Lexically speaking, the terminal symbols ``as'', ``qualified'' and ``hiding'' are each a varid rather than a reservedid. They have special significance only in the context of an import declaration; in other contexts they may be used as variables." 3. Similarly, add the following paragraph to 4.2.1 (Strictness fields) "Lexically, ``!'' is an ordinary varsym not a reservedop; it has special significance only in the context of the argument types of a data declaration." The only other special-op (unary minus) is dealt with at length already. Any objections? I don't think this is controversial. Simon | -----Original Message----- | From: George Russell [mailto:ger@tzi.de] | Sent: 02 October 2001 18:28 | To: Simon Peyton-Jones | Subject: Yet more lexing pedantry | | | Dear Simon Peyton Jones, | | Again not a bug, but specialids appear rather orphaned. That | is, they are defined, but do not appear in any production, so | they cannot be used. One presumes that when "as", | "qualified" and "hiding" appear later they are magically to | be regarded as specialids rather than varids (which they | could also be), but this is nowhere specified and does not | seem particularly necessary. Rather than regarding "as" as a | specialid that happens to be "id", would it not simply be | better to regard it as a varid that happens to be "as"? | | Best wishes, | | George Russell |

2 1

RE: Strange error in show for datatype
by Jan-Willem Maessen 04 Oct '01

04 Oct '01

"Simon Peyton-Jones" <simonpj(a)microsoft.com> 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 data structures work (and most first and second year CS classes will) that happens all the time. It comes up in situations as simple as making sure your functions return [] when you expect them to. So a clever solution to this problem would make hugs, ghci, etc. far more usable. It would also allow the monomorphism restriction to be relaxed at absolutely no cost in certain cases. 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: class Num a => ZeroList a where consZero :: a -> [a] consZero _ = 0:xs instance ZeroList Int instance ZeroList Double Now: (consZero (error "no type")) :: (ConsNum a) => [a] show (consZero (error "no type")) :: (ConsNum a) => String Do we get "[0]" or "[0.0]"? OK, we have a problem worth addressing, and a non-obvious (or absent) solution. I'd love to hear what our resident type theorists have to say. -Jan-Willem Maessen Eager Haskell Project

2 1

Empty Datatypes
by Ashley Yakeley 04 Oct '01

04 Oct '01

At 2001-10-04 00:36, Simon Peyton-Jones wrote: >It's also useful to be able to introduce >such empty types for phantom-type purposes, so GHC now lets you say > > data T > >and get a type T with no values. Yay! One more thing to cross off my [GHC] Haskell wish-list. Is this working in 5.02? It isn't in 5.00.2. -- Ashley Yakeley, Seattle WA

1 0