Profiles in GHC
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
Re: Haskell Report (again)
On Fri, Jul 20, 2001 at 08:35:13AM -0700, Simon Peyton-Jones wrote: > | (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. I could do it, if you prefer. > | (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. Yes, that should fix it. > | (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 Looks great! --Dylan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Type generalization ``order''?
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: > If, however, you can suggest some specific sentences that would help > to eliminate confusion, then please do suggest them. It is, to a certain extent, a design decision. One possibility might be to change > 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. to > 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. Another possibility might be to leave generalization as it is: > 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. and add a sentence here: > This implies that two contexts are considered equal > if and only if they imply the same set of class assertions > in the class environment. Instead of ``equal'' one might consider the somewhat less precise ``equivalent''. Wolfram ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Haskell Report (again)
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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Type generalization ``order''?
| 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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Type generalization ``order''?
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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell Report (again)
On Fri, Jul 20, 2001 at 04:59:05AM -0700, Simon Peyton-Jones wrote: > Dale is absolutely right! How has this entirely bogus code survived so > long? Err, my name is Dylan... > 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. (a) Where's the definition of mk0? (It was in the text you deleted.) (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? (c) I don't think the case e=0 is right; you miss the initial "0". (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. Best, Dylan > > 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 > > === ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Haskell Report (again)
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:[EMAIL PROTECTED]] | Sent: 17 July 2001 07:33 | To: Simon Peyton-Jones | Cc: [EMAIL PROTECTED] | 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 | ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
CFP: FOOL 9 -- Foundations of Object-Oriented Languages
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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, [EMAIL PROTECTED] 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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
