- Haskell - Haskell.org

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

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

20 Jul '01

Dale is absolutely right! How has this entirely bogus code survived so long? Here is an (alleged) fix, which works in the tests I've tried. If anyone else can spare a moment to check my code I'd be very grateful. This is definitely going in the Revised H98 report! Thanks Dale. Simon ================ Library Report, Numeric library, Section 4.1, page 13. In the definition of formatRealFloat, in the definition of doFmt, in the FFFixed branch of "case fmt of ...", in the Nothing branch of "case decs of ..." replace the entire branch "Nothing -> ..." with Nothing | e >= 0 -> take e (ds ++ repeat '0') ++ "." ++ mk0 (drop e ds) | otherwise -> "0." ++ replicate (-e) '0' ++ ds =========================== | -----Original Message----- | From: Dylan Thurston [mailto:dpt@math.harvard.edu] | Sent: 17 July 2001 07:33 | To: Simon Peyton-Jones | Cc: haskell(a)haskell.org | Subject: Re: Haskell Report (again) | | | On Tue, Jul 10, 2001 at 05:50:08AM -0700, Simon Peyton-Jones wrote: | > As ever, the draft is at | > | > http://research.microsoft.com/~simonpj/haskell98-revised | > | > I'm really hoping this is the final version, but experience | suggests | > that whenever I say that someone discovers an entirely new | question! | > So I'm putting it out again for you to pick over. | | I'm astonished no one has noticed this before, but in the | library report for the Numeric library, the definition of | showFFloat is buggy: | | showFFloat Nothing 0.02 "" | | goes into an infinite loop. (There is an auxiliary function | 'f n s ds' which does not consider the case n < 0). | | This suggests that there needs to be a code review of | formatRealFloat, which I have not yet done. | | --Dylan Thurston |

2 1

CFP: FOOL 9 -- Foundations of Object-Oriented Languages
by Martin Odersky 20 Jul '01

20 Jul '01

Call for Papers The Ninth International Workshop on Foundations of Object-Oriented Languages FOOL 9 Sponsored by ACM SIGPLAN January 19, 2002 Portland, Oregon, USA Following POPL '02 http://www.cs.williams.edu/~kim/FOOL/fool9.html Deadlines Submissions: October 12, 2001 Notifications: November 12, 2001 Final versions: December 10, 2001 The search for sound principles for object-oriented languages has given rise to much work on the theory of programming languages during the past 15 years, leading to a better understanding of the key concepts of object-oriented languages and to important developments in type theory, semantics, and program verification. The FOOL workshops bring together researchers to share new ideas and results in these areas. The next workshop, FOOL 9, will be held in Portland, Oregon, on Saturday January 19, 2002, the day after POPL '02. Submissions for this event are invited in the general area of foundations of object-oriented languages; topics of interest include language semantics, type systems, program analysis and verification, programming calculi, concurrent and distributed languages, and database languages. The main focus in selecting workshop contributions will be the intrinsic interest and timeliness of the work, so authors are encouraged to submit polished descriptions of work in progress as well as papers describing completed projects. A web page will be created and made available as informal electronic conference proceedings. Submission procedure We solicit submissions on original research not previously published or currently submitted for publication elsewhere, in the form of extended abstracts. These extended abstracts should not exceed 5000 words (approximately 10 pages); shorter extended abstracts (e.g., 2000 words) are often sufficient. Submissions should be e-mailed to fool9(a)lampsun1.epfl.ch by Friday, October 12, 2001, using Postscript or PDF. Each submission may be included inline in a message or as a MIME attachment only. We may not be able to consider late submissions, or submissions that do not have a working and attended return e-mail address. (If electronic submission is impossible, please contact the program chair in September.) Receipt of the submissions will be acknowledged by e-mail. Authors should inquire in case a prompt acknowledgment is not received. Correspondence and questions should be sent to fool9(a)lampsun1.epfl.ch Steering Committee Martin Abadi, Bell Labs Kim Bruce, Williams College Luca Cardelli, Microsoft Research Kathleen Fisher, AT&T Labs Benjamin Pierce, University of Pennsylvania (chair) Didier Remy, INRIA Rocquencourt Program Chair Martin Odersky, Swiss Federal Institute of Technology Lausanne, fool9(a)lampsun1.epfl.ch Program Committee Viviana Bono, Universita di Torino Craig Chambers, University of Washington Erik Ernst, University of Aalborg Giorgio Ghelli, University of Pisa Atsushi Igarashi, University of Tokyo Shriram Krishnamurthi, Brown University Clemens Szyperski, Microsoft Research Jan Vitek, Purdue University

1 0

STRAW POLL: comp.lang.haskell (fwd)
by Mark Carroll 19 Jul '01

19 Jul '01

People should be aware of this article that was recently posted to the newsgroup comp.lang.functional. ------- start of forwarded message ------- From: jeff-haskell(a)litech.org (Jeffrey M. Vinocur) Newsgroups: comp.lang.functional,news.groups Subject: STRAW POLL: comp.lang.haskell Date: Thu, 19 Jul 2001 15:31:05 +0000 (UTC) Message-ID: <9j6ufp%24fil%243(a)marduk.litech.org> I'm volunteering to take a straw poll to see whether we should try proposing comp.lang.haskell as a new newsgroup, possibly gatewayed to a mailing list. Currently Haskell-related traffic is in comp.lang.functional, and some people feel that it is a sufficiently-large portion of the traffic there to warrant a separate group. Opinions should be sent to <jeff-haskell(a)litech.org>. What we're really trying to determine is how many people would respond to an eventual Call For Votes in news.groups. There would first be a discussion period to hash out the details of things like mailing list gatewaying. (There is some discussion going on in comp.lang.haskell at the moment, feel free to join in there.) Reasonable choices for opinions are "Yes", "No", "Yes, provided it's gatewayed to a mailing list", "Yes, provided it's not gatewayed to a mailing list", "Will abstain from voting but don't want it gatewayed to the mailing list", etc. Note that a perfectly rational justification for wanting a separate group is because you read comp.lang.functional and want the Haskell traffic elsewhere; you need not be interested in reading a Haskell-only group. I'll post a summary of results, mmm, early next week, perhaps. So please reply promptly. -- Jeffrey M. Vinocur jeff(a)litech.org ------- end of forwarded message -------

1 0

Re: Counting Constructors
by Tobias Haeberlein 19 Jul '01

19 Jul '01

Thanks all for helping me! For those, who are interested in it: I got another solution of the problem: Instead of defining data Nest a = Zero | Succ a I "lift" Nest to the class level: data Zero a = Zero a data Succ a = Succ a class Nest a where count :: a -> Either Int a instance Nest (Zero a) where count Zero = Left 0 instance Nest a => Nest (Succ a) where count (Succ a) = case (count a) of Left i -> (Left i+1) Right _ -> (Right (Succ a) Then my desired show-instance is easy to define by instance Show (Zero a) where show Zero = show 0 instance (Show a, Nest a) => Show (Succ a) where show x = case (count x) of Left i -> show i Right (Succ x') -> show x' (Funny, Conor McBride does a similar "lifting" throughout his ingenious paper "Faking It: Simulating dependent types in Haskell"...) -Tobi -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net GMX Tipp: Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1! http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a

1 0

PLI2001: Early Registration Deadline is approaching
by Rosario Pugliese 19 Jul '01

19 Jul '01

[Apologies for multiple copies] ---------------------------------------------------------------- EARLY REGISTRATION DEADLINE IS APPROACHING PLI 2001 Principles, Logics, and Implementations of high-level programming languages Firenze, ITALY September 2 - 8, 2001 http://music.dsi.unifi.it/pli01/ The colloquium on Principles, Logics, and Implementations of high- level programming languages is a collection of events aimed at the advancement of high-level programming languages. PLI 2001 includes the following conferences and workshops: ACM Sponsored Conferences: ICFP (September 3-5) Int. Conf. on Functional Programming General chair: Benjamin Pierce (Univ. Pennsylvania) Program chair: Xavier Leroy (INRIA Rocquencourt) Invited speakers: To be announced PPDP (September 5-7) Int. Conf. on Principles and Practice of Declarative Programming Conference chair: Rocco De Nicola (Univ. Firenze) Program chair: Harald S?øndergaard (Univ. Melbourne) Invited speakers: J. Esparza, A. Gordon, and D.A. Schmidt. ACM Sponsored Workshops: · BABEL (Multi-language Infrastructure and Interoperability) · HASKELL · QAPL (Quantitative Aspects of Programming Languages) · RULE (Rule-Based Programming) · SAIG (Semantics, Applications, and Implementation of Program Generation) · SCHEME (Scheme and Functional Programming) · VCL (Verification and Computational Logic) Co-located Workshops: · ERLANG · FICS (Fixed Points in Computer Science) A detailed presentation of PLI2001, including schedule of events, travel, logistic and tourist information, is available at http://music.dsi.unifi.it/pli01/. Registration and accommodation information and forms are available at http://music.dsi.unifi.it/pli01/registration/ Early registration rates apply until July 25. For informations about hotels please contact (mentioning PLI 2001) Giubbi Jet di Volo Viaggi Piazza San Jacopino, 34/r - 50144 Firenze Telephone: +39 055 3249074 - +39 055 350577 Fax: +39 055 366807 E-mail: incoming(a)voloviaggi.com For all other informations mail to pli-org(a)gdn.dsi.unifi.it ------------------------------------------------------------------- Firenze is packed in September; do book accommodation as soon as possible. -------------------------------------------------------------------

1 0

Emacs ghci mode
by Chris Webb 19 Jul '01

19 Jul '01

I've adapted Guy Lapalme's haskell-hugs mode to work correctly with the new GHCi (principally to recognise the different error message formats). Having okayed this with him, I've popped it up for download for anyone who might find it useful: http://home.arachsys.com/~chris/haskell-ghci.el Please send me any complaints about bugs and suggestions for other things it might usefully do! Since the current version of haskell-mode.el doesn't contain an autoload for haskell-ghci, you'll need to add (autoload 'turn-on-haskell-ghci "haskell-ghci" "Turn on interaction with a GHCi interpreter." t) (add-hook 'haskell-mode-hook 'turn-on-haskell-ghci) to ~/.emacs to make it work. (All the haskell-hugs functions and variables have been renamed to haskell-ghci, and in theory you can run both inferior hugs and inferior ghci modes at the same time if you set up suitable keybindings.) Cheers, Chris.

1 1

Type declaration error
by To Anthony Widjaja 19 Jul '01

19 Jul '01

I've just tried writing a small code uses a function (/). When hugs compiled it, it turned out that the type declaration is the error. For function every function (/) you had to use type class Fractional it says. But do we have to use Fractional every time we include (/)? the code is as follows: more_less :: [(Int,Int)] -> ([(Int,Int)],[(Int,Int)]) more_less x = ([ m | m <- x, map (snd x) >= mean x], [ l | l <- x, map (snd x) < mean x] where mean x = (sum (map snd x))/(length x) What the code is intended to do is take a list of [(Int,Int)] and sort out the list in terms of their second value compared to the mean of the mean of the second values. I look forward to hearing from everyone. Thanks Cheers, Anthony Sign up for your FREE E-MAIL @ COMETMAIL: http://www.cometmail.com

1 0

<Re:lexical description problem in language report?>
by To Anthony Widjaja 19 Jul '01

19 Jul '01

<Hi Gary, Sorry I'm not answering your question. But I just want to know what sort of book (or perhaps something else) that contains this problem? Because you said in section 2.2, 2.3 and so on. On Wed, 18 Jul 2001 11:51:40 -0700 "Memovich, Gary" <GARY.MEMOVICH(a)kla-tencor.com> wrote: I believe I've found a problem, or at least a confusion, in the Haskell 98 Language Report. The section on lexical structure seems to use the term "lexeme" in an inconsistent way. "lexeme" is one of the productions in the lexical grammar in section 2.2, but the term is also used in section 2.3 where it is claimed that the string "{-" is a lexeme. However the string "{-" cannot be produced by the given grammar production. Is section 2.3, and the discussion of the maximal-munch rule, using the term lexeme in a different way than the grammar production in section 2.2? If so, maybe a new term should be introduced such as "rawlexeme", with a production like: rawlexeme -> lexeme | opencom | closecom | dashes Then perhaps the maximal-munch rule could be described in terms of "rawlexeme". Any thoughts? -- Gary > Sign up for your FREE E-MAIL @ COMETMAIL: http://www.cometmail.com

1 0

Re: Counting Constructors
by Jay Cox 18 Jul '01

18 Jul '01

> From: Tobias Haeberlein <T.Haeberlein(a)gmx.de> > To: haskell(a)haskell.org > Subject: Counting Constructors > > I want a show - instance for that type: > data Bind a = Zero | Succ a > resp. for the types (Bind ( ... (Bind a)...)) > > showing the following: > > show (Succ ( ... (Succ Zero)..)) = n > (where n is the number of Succ's) > and > > show (Succ ( ... (Succ x)..)) = show x > (when x != Zero) that doesnt make sense. You want n to be some some integral type and show x is a string. > > Does anyone know, how to define those functions in haskell/hugs ?? > (Are they defineable at all?) sounds like you really want something like data Bind a = Zero (Maybe a) | Succ (Bind a) instance (Show a) => Show (Bind a) where show x = z 0 x where z count (Zero Nothing) = show count z _ (Zero (Just x)) = show x z count (Succ x) = z (count+1) x Main> let {x :: Bind String; x = Succ $ Succ $ Succ $ Zero Nothing} in show x "3" Main> show (Succ $ Succ $ Zero (Just "Funky")) "\"Funky\"" However just because you can do it doesnt mean you should. Personally, I would think data Bind a = Something Int (Maybe a) or even using the Either datatype in a similar fashion could be more useful (and has a very trivial show instance which would meet your requirements).Meh, I'm probably doing somebody's homework here anyway. Jay

1 0