July 2001 - Haskell - Haskell.org

RE: Haskell 98 Report possible errors, part one
by Simon Peyton-Jones 23 Jul '01

23 Jul '01

Marcin Thanks for your careful read. Many of your suggestions I will implement. I'll send separate email about any others. [Haskell mailing list folk: I hope you'll forgive email about the minutae of the Haskell Report. But I don't want to let changes, or even clarifications, go by without giving you all a chance to yell. It is amazing how the act of saying "here's the final version" has an uncanny ability to stimulate new, and entirely well-founded, feedback. I propose to continue this process, though. I continue to make strenuous efforts to change the report only (a) to clarify what is obscure, (b) to fix grevious errors or inconsistencies.] Simon

1 0

RE: Type generalization ``order''?
by Simon Peyton-Jones 23 Jul '01

23 Jul '01

| Types are related by a generalization preorder (specified | below); the most general type, up to the equivalence | induced by that preorder, that can be assigned to a | particular expression (in a given environment) is called | its principal type. I like that, and will implement it. Thanks [Others: this is para 6 of 4.1.4 of the Haskell Report, if you are interested.] Simon

1 0

RE: Haskell 98 Report possible errors, part one
by Simon Marlow 23 Jul '01

23 Jul '01

> 3. A precedence table says that case (rightwards) has higher > precedence > than operators and right associativity. If it's meaningful to talk > about precedence of such syntactic constructs as case at all, > it should > probably be told to have a lower precedence, so "case x+1 of ..." > is valid as "case (x+1) of ...". At least I don't see a difference > between "case" (rightwards) and "if" (rightwards). I'm not sure if > it makes sense to explain parsing of "case" in terms of precedence. Interesting. The table seems to say that case(rightwards) has a higher precedence than infix operators, so that eg. case x of p -> x + y would parse as (case x of p -> x) + y which is in conflict with the longest parse rule. I have no idea why case(rightwards) is given a different precedence, and the inclusion of 'case alternative' in the list is confusing. > 4.3.1. "A class declaration with no where part [...] > The instance declaration must be given explicitly with no where part." > Actually the where part may be present but empty, with the > same meaning > as no where part. > > Generally I'm not sure that having a layout rule which says that {} is > inserted when the next indentation level is about to start and the new > indent is smaller than the outer one is necessary; in all useful cases > the keyword which triggered the layout could be omitted, and writing > let x = case x of > foo -> ... > should be either an error or it should be allowed to have the next > indent smaller than the previous one - it's not useful to let it mean > let {x = case x of {}} > foo -> ... > and in case one really wants to have empty alts in case, he > can write {} > explicitly. I agree, but this isn't really a bug so there's no need to change the report. Besides, GHC is the only compiler which actually implements the layout rule as specified :-) Cheers, Simon

1 0

RE: Profiles in GHC
by Simon Marlow 23 Jul '01

23 Jul '01

> Can anyone give me a brief explanation (or show me where in the web I can > find some info) about using the profiling library in GHC? Is it avaible for > Windows 98/NT? There's documentation on GHC's profiling facilities here: http://www.haskell.org/ghc/docs/latest/set/profiling.html And yes, profiling is available with the Windows version of GHC. Cheers, Simon

1 0

2001 Haskell Workshop: call for participation
by Ralf Hinze 22 Jul '01

22 Jul '01

============================================================================ CALL FOR PARTICIPATION ACM SIGPLAN 2001 Haskell Workshop Firenze, Italy, 2nd September 2001 The Haskell Workshop is sponsored by ACM SIGPLAN and forms part of the PLI 2001 colloquium on Principles, Logics, and Implementations of high-level programming languages, which comprises the ICFP/PPDP conferences and associated workshops. Previous Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris (1999), and Montreal (2000). http://www.cs.uu.nl/~ralf/hw2001.{html,pdf,ps,txt} ============================================================================ Workshop programme ------------------ The workshop received a total of 23 submissions and after careful consideration the programme committee selected the 10 papers below (6 regular, 4 pearls, and no application letters) for acceptance. The selection was competitive: several good papers had to be rejected. Please, note that in addition to longer presentations on accepted papers, a number of slots for participants to make 10-minute informal presentations are available. To request such a slot, contact Ralf Hinze (ralf(a)cs.uu.nl) 9.00 - 10.30: chaired by Ralf Hinze Functional Pearl: "Derivation of a Carry Lookahead Addition Circuit", John O'Donnell and Gudula R?nger Functional Pearl: "Inverting the Burrows-Wheeler Transform", Richard Bird, Shin-Cheng Mu, and Barney Stratford "Genuinely Functional User Interfaces", Antony Courtney and Conal Elliott 10.30 - 11.00: Coffee break 11.00 - 12.30: chaired by Patrik Jansson "Named Instances for Haskell Type Classes", Wolfram Kahl and Jan Scheffczyk "A Functional Notation for Functional Dependencies", Martin Gasbichler, Matthias Neubauer, Michael Sperber, and Peter Thiemann Report from the program chair and 10-minute talks (to be announced) 12.30 - 14.00: Lunch 14.00 - 15.30: chaired by Ross Paterson "GHood - Graphical Visualisation and Animation of Haskell Object Observations", Claus Reinke "Multiple-View Tracing for Haskell: a New Hat", Malcolm Wallace, Olaf Chitil, Thorsten Brehm, and Colin Runciman 10-minute talks (to be announced) 15.30 - 16.00: Coffee break 16.00 - 17.30: chaired by Jeremy Gibbons Functional Pearl: "Parsing Permutation Phrases", Arthur Baars, Andres L?h, and S. Doaitse Swierstra Functional Pearl: "Pretty Printing with Lazy Dequeues", Olaf Chitil "Playing by the Rules: Rewriting as a practical optimisation technique in GHC", Simon Peyton Jones, Andrew Tolmach, and Tony Hoare 17.30 - 18.00: chaired by Manuel Chakravarty Discussion: the future of Haskell ============================================================================ Programme committee ------------------- Manuel Chakravarty University of New South Wales Jeremy Gibbons University of Oxford Ralf Hinze (chair) University of Utrecht Patrik Jansson Chalmers University Mark Jones Oregon Graduate Institute Ross Paterson City University, London Simon Peyton Jones Microsoft Research Stephanie Weirich Cornell University ============================================================================ Scope ----- The purpose of the Haskell Workshop is to discuss experience with Haskell, and possible future developments for the language. The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. Submissions that discuss limitations of Haskell at present and/or propose new ideas for future versions of Haskell are particularly encouraged. Adopting an idea from ICFP 2000, the workshop also solicits two special classes of submissions, application letters and functional pearls, described below. Application Letters ------------------- An application letter describes experience using Haskell to solve real-world problems. Such a paper might typically be about six pages, and may be judged by interest of the application and novel use of Haskell. Functional Pearls ----------------- A functional pearl presents - using Haskell as a vehicle - an idea that is small, rounded, and glows with its own light. Such a paper might typically be about six pages, and may be judged by elegance of development and clarity of expression. ============================================================================ Useful links ------------ PLI 2001 http://music.dsi.unifi.it/pli01/ Haskell Workshop 2001 http://www.cs.uu.nl/~ralf/hw2001.html Registration Information http://music.dsi.unifi.it/pli01/registration/ Haskell Home Page http://www.haskell.org

1 0

Haskell on Mac OS X release?
by Howard Oakley 22 Jul '01

22 Jul '01

[newbie alert] Although I have seen ports of HUGS and GHC to Mac OS X beta, is anyone actively working on ports for the release version of OS X? (I have the current HUGS up and running, and am looking at porting one or more of the compilers when life quietens down a bit towards the end of this month. Has anyone any server space to hold binaries? Although new to Haskell, I'm fairly experienced at porting to Mac and OS X, including LAM and Charm++. I'm also wondering about interfaces between Haskell and OS X graphics etc....) Howard. Dr Howard Oakley * M1BWR: QRV on 2, 4 & 6 m SSB EHN & DIJ Oakley * Internet howard(a)quercus.demon.co.uk Brooklands Lodge * CompuServe 70734,120 Park View Close * http://www.quercus.demon.co.uk Wroxall, Ventnor * voice +44 1983 853605 Isle of Wight, PO38 3EQ, UK * fax +44 1983 853253

2 1

Profiles in GHC
by Andre W B Furtado 21 Jul '01

21 Jul '01

Can anyone give me a brief explanation (or show me where in the web I can find some info) about using the profiling library in GHC? Is it avaible for Windows 98/NT? Thanks in advance, Andre W B Furtado

1 0

RE: Haskell Report (again)
by Simon Peyton-Jones 20 Jul '01

20 Jul '01

Dylan (sorry for the wrong name) | (a) Where's the definition of mk0? (It was in the text you deleted.) Ah, it should go back. | (b) What is the code supposed to do? The code you posted always | prints a decimal point; I imagine this is intended? Can this be | documented? Sigh. The numeric library is entirely inadequately documented. I suppose that now you have forced me to face up to this fact I shall have to write some (brief) documentation for at least the exported functions. | (c) I don't think the case e=0 is right; you miss the initial "0". True. The e>=0 should be e>0, I think. | (d) "floatToDigits" seems to return an exponent that is off by 1 from | what I expected at first. This is reasonable, but since the | function is exported, it should be documented. Here's a comment I've just deduced and typed in for floatToDigits. Does it meet the need? -- floatToDigits takes a base and a non-negative RealFloat number, -- and returns a list of digits and an exponent. -- In particular, if x>=0, and -- floatToDigits base x = ([d1,d2,...,dn], e) -- then -- (a) n >= 1 -- (b) x = 0.d1d2...dn * (base**e) -- (c) 0 <= di <= base-1

2 1

RE: Type generalization ``order''?
by Simon Peyton-Jones 20 Jul '01

20 Jul '01

| I suggest to include an appropriate hint in the report... | | > In this subsection, we provide informal details of the | type system. > (Wadler and Blott [11] and Jones [6] discuss | type and constructor classes, > respectively, in more detail.) | | I think this kind of outsourcing of essential parts of the | language definition is not desirable. The Report's description of the type system is not a proper specification. That is a flaw, but it is not one I can fix for the Revised H98 Report. If, however, you can suggest some specific sentences that would help to eliminate confusion, then please do suggest them. Incidentally, Karl-Filip Faxen is working on a formal static semantics for Haskell. Simon

2 1

Type generalization ``order''?
by kahl＠heraklit.informatik.unibw-muenchen.de 20 Jul '01

20 Jul '01

The Haskell 98 report (also in the current revised version) includes the following in section 4.1.4: > Types are related by a generalization order (specified below); > the most general type that can be assigned to a particular expression > (in a given environment) is called its principal type. > Haskell 's extended Hindley-Milner type system can infer the > principal type of all expressions, including the proper use of > overloaded class methods (although certain ambiguous overloadings > could arise, as described in Section 4.3.4). Therefore, explicit typings > (called type signatures) are usually optional (see Sections 3.16 and 4.4.1). > > The type forall u. cx1 =>t1 is more general than the type > forall w. cx2 =>t2 if and only if there is a substitution S > whose domain is u such that: > > t2 is identical to S(t1). > > Whenever cx2 holds in the class environment, S(cx1) also holds. The relation defined here clearly is a preorder. If it is an order, then in particular the following types are equal (via identical substitutions): (Eq a, Ord b) => (a,b) (Ord b, Eq a) => (a,b) (Eq b, Ord b, Eq a) => (a,b) (Eq [a], Ord b) => (a,b) It seems to me that this arises since the report only defines the SYNTAX of contexts (see the heading ``4.1.3 Syntax of Class Assertions and Contexts''), but never defines what a context IS, that is, the SEMANTICS of contexts. A context could be: * a SEQUENCE of class assertions (according to the syntax) * a SET of class assertions (slightly more intuitive) * a THEORY of class assertions If type generalisation is an order, then the third alternative was chosen. I suggest to include an appropriate hint in the report... (I am aware of the beginning of 4.1.4: > In this subsection, we provide informal details of the type system. > (Wadler and Blott [11] and Jones [6] discuss type and constructor classes, > respectively, in more detail.) I think this kind of outsourcing of essential parts of the language definition is not desirable. ) Best regards, Wolfram

1 0