From simonpj at microsoft.com Mon Feb 8 11:18:07 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Feb 8 10:50:00 2010 Subject: Negation Message-ID: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> Folks Which of these definitions are correct Haskell? x1 = 4 + -5 x2 = -4 + 5 x3 = 4 - -5 x4 = -4 - 5 x5 = 4 * -5 x6 = -4 * 5 Ghc accepts x2, x4, x6 and rejects the others with a message like Foo.hs:4:7: Precedence parsing error cannot mix `+' [infixl 6] and prefix `-' [infixl 6] in the same infix expression Hugs accepts them all. I believe that the language specifies that all should be rejected. http://haskell.org/onlinereport/syntax-iso.html I think that Hugs is right here. After all, there is no ambiguity in any of these expressions. And an application-domain user found this behaviour very surprising. I'm inclined to start a Haskell Prime ticket to fix this language definition bug. But first, can anyone think of a reason *not* to allow all the above? Simon From dan.doel at gmail.com Mon Feb 8 12:00:52 2010 From: dan.doel at gmail.com (Dan Doel) Date: Mon Feb 8 11:32:13 2010 Subject: Negation In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <201002081200.52407.dan.doel@gmail.com> On Monday 08 February 2010 11:18:07 am Simon Peyton-Jones wrote: > I think that Hugs is right here. After all, there is no ambiguity in any > of these expressions. And an application-domain user found this behaviour > very surprising. I think it's clear what one would expect the result of these expressions to be, but there is some ambiguity considering how GHC parses other similar expressions (I don't actually know if it's following the report in doing so or not). For instance: -4 `mod` 5 parses as: -(4 `mod` 5) which I've seen confuse many a person (and it confused me the first time I saw it; it makes divMod and quotRem appear identical if one is testing them by hand as above, and doesn't know about the weird parsing). Knowing the above, I wasn't entirely sure what the results of x2 and x4 would be. Of course, I think the `mod` parsing is the weird bit, and it'd be good if it could be amended such that -a `mod` -b = (-a) `mod` (-b) like the rest of the proposal. -- Dan From ross at soi.city.ac.uk Mon Feb 8 11:59:59 2010 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Feb 8 11:32:13 2010 Subject: Negation In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <20100208165958.GA14892@soi.city.ac.uk> On Mon, Feb 08, 2010 at 04:18:07PM +0000, Simon Peyton-Jones wrote: > Which of these definitions are correct Haskell? > > x1 = 4 + -5 > x2 = -4 + 5 > x3 = 4 - -5 > x4 = -4 - 5 > x5 = 4 * -5 > x6 = -4 * 5 > > Ghc accepts x2, x4, x6 and rejects the others with a message like > Foo.hs:4:7: > Precedence parsing error > cannot mix `+' [infixl 6] and prefix `-' [infixl 6] in the same infix expression > > Hugs accepts them all. > > I believe that the language specifies that all should be rejected. http://haskell.org/onlinereport/syntax-iso.html I think GHC conforms to the Report; here is the relevant part of the grammar: exp6 -> exp7 | lexp6 lexp6 -> (lexp6 | exp7) + exp7 | (lexp6 | exp7) - exp7 | - exp7 exp7 -> exp8 | lexp7 lexp7 -> (lexp7 | exp8) * exp8 But I agree they should all be legal, i.e. that unary minus should bind more tightly than any infix operator (as in C). Note that Hugs does not do that: Hugs> -5 `mod` 2 -1 Hugs> (-5) `mod` 2 1 Hugs> -(5 `mod` 2) -1 From igloo at earth.li Mon Feb 8 12:20:03 2010 From: igloo at earth.li (Ian Lynagh) Date: Mon Feb 8 11:51:17 2010 Subject: Negation In-Reply-To: <20100208165958.GA14892@soi.city.ac.uk> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <20100208165958.GA14892@soi.city.ac.uk> Message-ID: <20100208172003.GA23661@matrix.chaos.earth.li> On Mon, Feb 08, 2010 at 04:59:59PM +0000, Ross Paterson wrote: > > But I agree they should all be legal, i.e. that unary minus should bind > more tightly than any infix operator (as in C). See also http://hackage.haskell.org/trac/haskell-prime/wiki/NegativeSyntax Thanks Ian From sjurberengal at gmail.com Mon Feb 8 12:54:25 2010 From: sjurberengal at gmail.com (Sjur =?iso-8859-1?q?Gj=F8stein_Karevoll?=) Date: Mon Feb 8 12:26:21 2010 Subject: Negation In-Reply-To: <20100208165958.GA14892@soi.city.ac.uk> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <20100208165958.GA14892@soi.city.ac.uk> Message-ID: <201002081854.25778.sjurberengal@gmail.com> M?ndag 8. februar 2010 17.59.59 skreiv Ross Paterson: > But I agree they should all be legal, i.e. that unary minus should bind > more tightly than any infix operator (as in C). I second this, at least in general. However, one issue is function application. Should unary minus bind tighter than it or not and are there special cases (spaces)? Consider: 1) foo-1 2) foo -1 3) foo - 1 If unary minus binds tighter than application then we get `foo (-1)` in all cases. The other way around we get `(foo) - (1)` in all cases. To me the most natural parsing would be 1) (foo) - (1) 2) foo (-1) 3) (foo) - (1) Then there's also the issue of literals: 4) 1-1 5) 1 -1 6) 1 - 1 To me, all of these should parse as `(1) - (1)`. I'm a fan of treating literals and variables the same though (referential transparancy even in parsing), and that makes this problematic. Personally I'd like to just get rid of unary minus altogether and use some other symbol, like _, to represent negation, but doing that would probably break most programs out there. -- Sjur Gj?stein Karevoll From lennart at augustsson.net Mon Feb 8 13:30:07 2010 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Feb 8 13:01:20 2010 Subject: Negation In-Reply-To: <20100208165958.GA14892@soi.city.ac.uk> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <20100208165958.GA14892@soi.city.ac.uk> Message-ID: Of course unary minus should bind tighter than any infix operator. I remember suggesting this when the language was designed, but the Haskell committee was very set against it (mostly Joe Fasel I think). I think it's too late to change that now, it could really introduce some subtle bugs with no parse or type errors. On Mon, Feb 8, 2010 at 5:59 PM, Ross Paterson wrote: > On Mon, Feb 08, 2010 at 04:18:07PM +0000, Simon Peyton-Jones wrote: >> Which of these definitions are correct Haskell? >> >> ? x1 = 4 + -5 >> ? x2 = -4 + 5 >> ? x3 = 4 - -5 >> ? x4 = -4 - 5 >> ? x5 = 4 * -5 >> ? x6 = -4 * 5 >> >> Ghc accepts x2, x4, x6 and rejects the others with a message like >> Foo.hs:4:7: >> ? ? Precedence parsing error >> ? ? ? ? cannot mix `+' [infixl 6] and prefix `-' [infixl 6] in the same infix expression >> >> Hugs accepts them all. >> >> I believe that the language specifies that all should be rejected. ?http://haskell.org/onlinereport/syntax-iso.html > > I think GHC conforms to the Report; here is the relevant part of the grammar: > > exp6 ? ?-> ? ? ?exp7 > ? ? ? ?| ? ? ? lexp6 > lexp6 ? -> ? ? ?(lexp6 | exp7) + exp7 > ? ? ? ?| ? ? ? (lexp6 | exp7) - exp7 > ? ? ? ?| ? ? ? - exp7 > > exp7 ? ?-> ? ? ?exp8 > ? ? ? ?| ? ? ? lexp7 > lexp7 ? -> ? ? ?(lexp7 | exp8) * exp8 > > But I agree they should all be legal, i.e. that unary minus should bind > more tightly than any infix operator (as in C). ?Note that Hugs does > not do that: > > Hugs> -5 `mod` 2 > -1 > Hugs> (-5) `mod` 2 > 1 > Hugs> -(5 `mod` 2) > -1 > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From jur at cs.uu.nl Mon Feb 8 14:04:44 2010 From: jur at cs.uu.nl (jur) Date: Mon Feb 8 13:35:58 2010 Subject: Negation In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: On Feb 8, 2010, at 5:18 PM, Simon Peyton-Jones wrote: > Folks > > Which of these definitions are correct Haskell? > > x1 = 4 + -5 > x2 = -4 + 5 > x3 = 4 - -5 > x4 = -4 - 5 > x5 = 4 * -5 > x6 = -4 * 5 > > Ghc accepts x2, x4, x6 and rejects the others with a message like > Foo.hs:4:7: > Precedence parsing error > cannot mix `+' [infixl 6] and prefix `-' [infixl 6] in the > same infix expression > > Hugs accepts them all. Helium accepts them all as well, and also delivers the, for me, expected results. > > I believe that the language specifies that all should be rejected. http://haskell.org/onlinereport/syntax-iso.html > > > I think that Hugs is right here. After all, there is no ambiguity > in any of these expressions. And an application-domain user found > this behaviour very surprising. > > I'm inclined to start a Haskell Prime ticket to fix this language > definition bug. But first, can anyone think of a reason *not* to > allow all the above? > > Simon Jurriaan From john at repetae.net Mon Feb 8 16:24:55 2010 From: john at repetae.net (John Meacham) Date: Mon Feb 8 15:56:10 2010 Subject: Negation In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <20100208212455.GC16245@sliver.repetae.net> On Mon, Feb 08, 2010 at 04:18:07PM +0000, Simon Peyton-Jones wrote: > Which of these definitions are correct Haskell? > > x1 = 4 + -5 > x2 = -4 + 5 > x3 = 4 - -5 > x4 = -4 - 5 > x5 = 4 * -5 > x6 = -4 * 5 > > Ghc accepts x2, x4, x6 and rejects the others with a message like > Foo.hs:4:7: > Precedence parsing error > cannot mix `+' [infixl 6] and prefix `-' [infixl 6] in the same infix expression > > Hugs accepts them all. > > I believe that the language specifies that all should be rejected. http://haskell.org/onlinereport/syntax-iso.html > > > I think that Hugs is right here. After all, there is no ambiguity in any of these expressions. And an application-domain user found this behaviour very surprising. > > I'm inclined to start a Haskell Prime ticket to fix this language definition bug. But first, can anyone think of a reason *not* to allow all the above? What would be the actual change proposed? If it is something concrete and not something like "negatives should be interpreted as unary minus when otherwise it would lead to a parse error" then that wouldn't be good. I have enough issues with the layout rule as is :) John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From ross at soi.city.ac.uk Mon Feb 8 18:04:29 2010 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Feb 8 17:36:12 2010 Subject: Negation In-Reply-To: <20100208212455.GC16245@sliver.repetae.net> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <20100208212455.GC16245@sliver.repetae.net> Message-ID: <20100208230429.GA24543@soi.city.ac.uk> On Mon, Feb 08, 2010 at 01:24:55PM -0800, John Meacham wrote: > What would be the actual change proposed? If it is something concrete > and not something like "negatives should be interpreted as unary minus > when otherwise it would lead to a parse error" then that wouldn't be > good. I have enough issues with the layout rule as is :) I imagine it would be something like deleting the production lexp6 -> - exp7 and adding the production exp10 -> - fexp From simonpj at microsoft.com Tue Feb 9 02:30:29 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Feb 9 02:02:05 2010 Subject: Negation In-Reply-To: References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <20100208165958.GA14892@soi.city.ac.uk> Message-ID: <59543203684B2244980D7E4057D5FBC10AFD30F1@DB3EX14MBXC306.europe.corp.microsoft.com> | Of course unary minus should bind tighter than any infix operator. | I remember suggesting this when the language was designed, but the | Haskell committee was very set against it (mostly Joe Fasel I think). | | I think it's too late to change that now, it could really introduce | some subtle bugs with no parse or type errors. I'm not sure it's too late to change. That's what Haskell Prime is for. The change would have a flag of course, and could emit a warning if the old and new would give different results. I think I'll create a ticket at least. | I imagine it would be something like deleting the production | | lexp6 -> - exp7 | | and adding the production | | exp10 -> - fexp Yes, exactly Simon From ganesh.sittampalam at credit-suisse.com Tue Feb 9 03:28:27 2010 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Feb 9 02:59:48 2010 Subject: Negation In-Reply-To: References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com><20100208165958.GA14892@soi.city.ac.uk> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B08816E01@ELON17P32001A.csfb.cs-group.com> Lennart Augustsson wrote: > Of course unary minus should bind tighter than any infix operator. > I remember suggesting this when the language was designed, but the > Haskell committee was very set against it (mostly Joe Fasel I think). Are there archives of this discussion anywhere? Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From jon.fairbairn at cl.cam.ac.uk Tue Feb 9 04:43:17 2010 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Tue Feb 9 04:14:53 2010 Subject: Negation References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <20100208165958.GA14892@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B08816E01@ELON17P32001A.csfb.cs-group.com> Message-ID: "Sittampalam, Ganesh" writes: > Lennart Augustsson wrote: >> Of course unary minus should bind tighter than any infix operator. >> I remember suggesting this when the language was designed, but the >> Haskell committee was very set against it (mostly Joe Fasel I think). > > Are there archives of this discussion anywhere? If it was on the fplangc mailing list, the archive exists somewhere (Thomas Johnsson had it in the past). If it was at one of the committee meetings, Thomas or Lennart had a tape recorder running. I remember asking some time later what happened to this and got a reply that contained the phrase "teknisk miss?de", which doesn't take much of a grasp of Swedish to guess the meaning of. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From johndearle at cox.net Tue Feb 9 08:39:53 2010 From: johndearle at cox.net (johndearle@cox.net) Date: Tue Feb 9 08:11:04 2010 Subject: Negation In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <20100209083953.FPWKQ.600528.imail@fed1rmwml30> Monadic operators are atomic in that they form an atom. Binary operators do not. Perhaps I should have used the word unary instead of monadic, hmm. It is best sometimes to never turn back. What is done is done! There is an ambiguity. One is a partial order whereas the other is a total order. Despite the apparent clarity the question is are there mitigating factors? I do not wish to reveal all the mysteries of the universe in one sitting (in other words I have no intention of discussing the precise mechanisms involved), but having multiple uses for a symbol complicates the grammar. Hyphen is badly overloaded. The rules as they are may serve to discourage certain patterns. OK, I'll spell it out. Ambiguity is not a one way street. In the usual course of the compiler, something might be unambiguous (with respect to the compiler). The compiler exhibits what I shall call direction bias. This is why it appears in a sense to be unambiguous. We usually explain this away by saying that though it is unambiguous, it is unclear. This is merely informal speech that results from a lack of understanding of the nature of the problem. On occasion despite the direction bias of the machine in real world problems we often encounter this ambiguity that occurs in the opposite direction. Typically, we merely dismiss the ambiguity as not even being a legitimate expression of ambiguity once we realize that in the conventional direction it is unambiguous. We will conclude that we were confused when in fact we were not. Our confusion is our conclusion that we were confused. So in a sense it is unambiguous and in another it is ambiguous in a manner that is context sensitive. For example, if you are trying to extend the grammar of the language you may have to account for the various ways in which hyphens are used. In other words you have to account for the ambiguities. This has been an area of research for me. As a practical matter it is often possible to account for them if you grok the language and how it was implemented, and have nothing better to do with your time than to work out all the possible implications of a proposed change to the language which is what all of you are doing. Since this sort of thing only crops up on occasion we dismiss it as unreal. You/we could use tilde for minus sign much like Standard ML does. It was a brilliant stroke and it isn't heresy. It is conceivable that an alternative albeit inferior approach to achieve a similar outcome was taken that everyone is now stuck with, but there is more to the story. Someone gave an example involving modular arithmetic. If negation were meaningless with respect to an operation that operation could be regarded as more atomic as in more primitive than negation. You essentially skip over the expression concluding that it can't apply because it cannot meaningfully apply. Negation is meaningful (though not wholly meaningful) with respect to modular arithmetic and so there is no reason for it to be regarded as more primitive than additive inverse "negation". There are no type distinctions. An integer is an integer is an integer though I could see how someone might think of modular arithmetic as the arithmetic of the finite and therefore smaller and something that fits inside of the infinite. The type of the result of modular arithmetic is not a pure integer. It has a more restrictive type even though the distinction is easily overlooked. The domain and codomain does not form the Cartesian product of integers. It is bounded by the modulus, thus a dependent type. Can the degree to which a type is broad or narrow be used to signify the default order of evaluation, known as precedence? There is reason to believe so. Since one type is more restrictive than another on occasion the operation will be meaningful and on others meaningless. By way of analogy (and efficiency) more restrictive types should be evaluated first and therefore have a higher precedence compared to their less restrictive counterparts even if the type distinctions are invisible to the compiler. It needs to be appreciated that the Haskell language was created by type theorists who were not necessarily concerned with how they do it in C. From lennart at augustsson.net Tue Feb 9 10:12:06 2010 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Feb 9 09:43:17 2010 Subject: Negation In-Reply-To: <20100209083953.FPWKQ.600528.imail@fed1rmwml30> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <20100209083953.FPWKQ.600528.imail@fed1rmwml30> Message-ID: It's not true at all that Haskell was created by type theorists. It is true that little attention was paid for how things are done in C. :) On Tue, Feb 9, 2010 at 2:39 PM, wrote: > > It needs to be appreciated that the Haskell language was created by type theorists who were not necessarily concerned with how they do it in C. From Christian.Maeder at dfki.de Tue Feb 9 11:07:18 2010 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Feb 9 10:38:32 2010 Subject: Negation In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFD30F1@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <20100208165958.GA14892@soi.city.ac.uk> <59543203684B2244980D7E4057D5FBC10AFD30F1@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <4B718836.6000607@dfki.de> > | I imagine it would be something like deleting the production > | > | lexp6 -> - exp7 The rational for the current choice was the example: f x = -x^2 > | and adding the production > | > | exp10 -> - fexp But I would also recommend this change. It would also make sense to allow "-" before "let", "if" and "case" or another "-" expression, but that's a matter of taste. Cheers Christian From johndearle at cox.net Tue Feb 9 14:48:45 2010 From: johndearle at cox.net (johndearle@cox.net) Date: Tue Feb 9 14:19:57 2010 Subject: Negation In-Reply-To: <4B718836.6000607@dfki.de> Message-ID: <20100209144845.7CZ59.625317.imail@fed1rmwml45> My impression is that combinatory logic figures prominently in the design of Haskell and some of the constructs seem to be best understood as combinatorial logic with syntactic sugar. One could predict from this a number of things. One of such is the language would at some points seem counter intuitive, albeit rational. I am concerned that those who lose sight of this, or perhaps never understood this and don't care to, may lose touch with the language's intent. If it is an outcome of combinatorial logic it is likely correct. The problem may lie else where. The example given "rationale" suggests that the problem centers on the language designers being in possession of a necessary condition for correctness, but not a sufficient condition. If this is the case, there are two courses of action that are available to you/us. Solve the problem, as in work out all the necessary conditions so that you are in possession of a sufficient condition or give up the attempt to solve the problem altogether, throw up your hands and admit you failed, proclaiming that the naive solution found was and is worse than the problem. It may even turn out that as you become familiar with the alleged solution, that it has charm, in that it brings you flowers and you discover that he isn't all that bad. ---- Christian Maeder wrote: > > | I imagine it would be something like deleting the production > > | > > | lexp6 -> - exp7 > > The rational for the current choice was the example: > > f x = -x^2 > > > | and adding the production > > | > > | exp10 -> - fexp > > But I would also recommend this change. > > It would also make sense to allow "-" before "let", "if" and "case" or > another "-" expression, but that's a matter of taste. > > Cheers Christian > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime From doaitse at cs.uu.nl Tue Feb 9 16:43:02 2010 From: doaitse at cs.uu.nl (S. Doaitse Swierstra) Date: Tue Feb 9 16:14:15 2010 Subject: Negation In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: One we start discussing syntax again it might be a good occasion to reformulate/make more precise a few points. The following program is accepted by the Utrecht Haskell Compiler (here we took great effort to follow the report closely ;-} instead of spending our time on n+k patterns), but not by the GHC and Hugs. module Main where -- this is a (rather elaborate) definition of the number 1 one = let x=1 in x -- this is a definition of the successor function using section notation increment = ( one + ) -- but if we now unfold the definition of one we get a parser error in GHC increment' = ( let x=1 in x + ) The GHC and Hugs parsers are trying so hard to adhere to the meta rule that bodies of let-expressions extend as far as possible when needed in order to avoid ambiguity, that they even apply that rule when there is no ambiguity; here we have only a single possible parse, i.e. interpreting the offending expression as ((let x = 1 in ) +). Yes, Haskell is both a difficult language to parse and to describe precisely. Doaitse On 8 feb 2010, at 17:18, Simon Peyton-Jones wrote: > Folks > > Which of these definitions are correct Haskell? > > x1 = 4 + -5 > x2 = -4 + 5 > x3 = 4 - -5 > x4 = -4 - 5 > x5 = 4 * -5 > x6 = -4 * 5 > > Ghc accepts x2, x4, x6 and rejects the others with a message like > Foo.hs:4:7: > Precedence parsing error > cannot mix `+' [infixl 6] and prefix `-' [infixl 6] in the > same infix expression > > Hugs accepts them all. > > I believe that the language specifies that all should be rejected. http://haskell.org/onlinereport/syntax-iso.html > > > I think that Hugs is right here. After all, there is no ambiguity > in any of these expressions. And an application-domain user found > this behaviour very surprising. > > I'm inclined to start a Haskell Prime ticket to fix this language > definition bug. But first, can anyone think of a reason *not* to > allow all the above? > > Simon > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime From lennart at augustsson.net Tue Feb 9 18:53:46 2010 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Feb 9 18:24:55 2010 Subject: Negation In-Reply-To: References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: Do you deal with this correctly as well: case () of _ -> 1==1==True On Tue, Feb 9, 2010 at 10:43 PM, S. Doaitse Swierstra wrote: > One we start discussing syntax again it might be a good occasion to > reformulate/make more precise a few points. > > The following program is accepted by the Utrecht Haskell Compiler (here we > took great effort to follow the report closely ;-} instead of spending our > time on n+k patterns), but not by the GHC and Hugs. > > module Main where > > -- this is a (rather elaborate) definition of the number 1 > one = let x=1 in x > > -- this is a definition of the successor function using section notation > increment = ( one + ) > > -- but if we now unfold the definition of one we get a parser error in GHC > increment' = ( let x=1 in x ?+ ?) > > The GHC and Hugs parsers are trying so hard to adhere to the meta rule that > bodies of let-expressions > extend as far as possible when needed in order to avoid ambiguity, that they > even apply that rule when there is no ambiguity; > here we have ?only a single possible parse, i.e. interpreting the offending > expression as ((let x = 1 in ) +). > > Yes, Haskell is both a difficult language to parse and to describe > precisely. > > Doaitse > > > On 8 feb 2010, at 17:18, Simon Peyton-Jones wrote: > >> Folks >> >> Which of these definitions are correct Haskell? >> >> x1 = 4 + -5 >> x2 = -4 + 5 >> x3 = 4 - -5 >> x4 = -4 - 5 >> x5 = 4 * -5 >> x6 = -4 * 5 >> >> Ghc accepts x2, x4, x6 and rejects the others with a message like >> Foo.hs:4:7: >> ?Precedence parsing error >> ? ? ?cannot mix `+' [infixl 6] and prefix `-' [infixl 6] in the same infix >> expression >> >> Hugs accepts them all. >> >> I believe that the language specifies that all should be rejected. >> ?http://haskell.org/onlinereport/syntax-iso.html >> >> >> I think that Hugs is right here. ?After all, there is no ambiguity in any >> of these expressions. ?And an application-domain user found this behaviour >> very surprising. >> >> I'm inclined to start a Haskell Prime ticket to fix this language >> definition bug. ?But first, can anyone think of a reason *not* to allow all >> the above? >> >> Simon >> >> >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-prime > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From atze at xs4all.nl Wed Feb 10 02:53:16 2010 From: atze at xs4all.nl (Atze Dijkstra) Date: Wed Feb 10 02:24:28 2010 Subject: Negation In-Reply-To: References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: On 10 Feb, 2010, at 00:53 , Lennart Augustsson wrote: > Do you deal with this correctly as well: > case () of _ -> 1==1==True No, that is, in the same way as GHC & Hugs, by reporting an error. The report acknowledges that compilers may not deal with this correctly when it has the form ``let x=() in 1=1=True'' (or a if/\... -> prefix), but does not do so for your example. It is even a bit more complicated of the layout rule because case () of _ -> 1==1 ==True is accepted. I think the combination of layout rule, ambiguity disambiguated by a 'extend as far as possible to the right' rule, fixity notation as syntax directives (but not separated as such), makes the language design at some points rather complex to manage implementationwise in a compiler. Like all we do our best to approach the definition. When possible I'd prefer changes in the language which simplify matters (like a simpler way of dealing with negate as proposed), at least with these syntactical issues. > > > On Tue, Feb 9, 2010 at 10:43 PM, S. Doaitse Swierstra > wrote: >> One we start discussing syntax again it might be a good occasion to >> reformulate/make more precise a few points. >> >> The following program is accepted by the Utrecht Haskell Compiler >> (here we >> took great effort to follow the report closely ;-} instead of >> spending our >> time on n+k patterns), but not by the GHC and Hugs. >> >> module Main where >> >> -- this is a (rather elaborate) definition of the number 1 >> one = let x=1 in x >> >> -- this is a definition of the successor function using section >> notation >> increment = ( one + ) >> >> -- but if we now unfold the definition of one we get a parser error >> in GHC >> increment' = ( let x=1 in x + ) >> >> The GHC and Hugs parsers are trying so hard to adhere to the meta >> rule that >> bodies of let-expressions >> extend as far as possible when needed in order to avoid ambiguity, >> that they >> even apply that rule when there is no ambiguity; >> here we have only a single possible parse, i.e. interpreting the >> offending >> expression as ((let x = 1 in ) +). >> >> Yes, Haskell is both a difficult language to parse and to describe >> precisely. >> >> Doaitse >> >> >> On 8 feb 2010, at 17:18, Simon Peyton-Jones wrote: >> >>> Folks >>> >>> Which of these definitions are correct Haskell? >>> >>> x1 = 4 + -5 >>> x2 = -4 + 5 >>> x3 = 4 - -5 >>> x4 = -4 - 5 >>> x5 = 4 * -5 >>> x6 = -4 * 5 >>> >>> Ghc accepts x2, x4, x6 and rejects the others with a message like >>> Foo.hs:4:7: >>> Precedence parsing error >>> cannot mix `+' [infixl 6] and prefix `-' [infixl 6] in the >>> same infix >>> expression >>> >>> Hugs accepts them all. >>> >>> I believe that the language specifies that all should be rejected. >>> http://haskell.org/onlinereport/syntax-iso.html >>> >>> >>> I think that Hugs is right here. After all, there is no ambiguity >>> in any >>> of these expressions. And an application-domain user found this >>> behaviour >>> very surprising. >>> >>> I'm inclined to start a Haskell Prime ticket to fix this language >>> definition bug. But first, can anyone think of a reason *not* to >>> allow all >>> the above? >>> >>> Simon >>> >>> >>> _______________________________________________ >>> Haskell-prime mailing list >>> Haskell-prime@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-prime >> >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-prime >> > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 .... | Email: atze@cs.uu.nl ............ / |___\ From sebf at informatik.uni-kiel.de Wed Feb 10 04:40:34 2010 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Wed Feb 10 04:11:45 2010 Subject: Negation In-Reply-To: References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <140A1721-0EB6-41D6-8B40-35BC77DA9A2E@informatik.uni-kiel.de> On Feb 9, 2010, at 10:43 PM, S. Doaitse Swierstra wrote: > -- but if we now unfold the definition of one we get a parser error > in GHC > increment' = ( let x=1 in x + ) > > The GHC and Hugs parsers are trying so hard to adhere to the meta > rule that bodies of let-expressions > extend as far as possible when needed in order to avoid ambiguity, > that they even apply that rule when there is no ambiguity; > here we have only a single possible parse, i.e. interpreting the > offending expression as ((let x = 1 in ) +). Despite the fact that there is a typo (second x is missing), I can think of two possible parses. Actually, my mental parser produced the second one: ((let x=1 in x)+) let x=1 in (x+) The Haskell report may exclude my mental parse because operator sections need to be parenthesised. Or are you arguing that in your example different possible parses have the same semantics for an arguably obvious reason and that this fact is relevant? Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) From doaitse at cs.uu.nl Wed Feb 10 07:25:41 2010 From: doaitse at cs.uu.nl (S. Doaitse Swierstra) Date: Wed Feb 10 06:56:53 2010 Subject: Negation In-Reply-To: <140A1721-0EB6-41D6-8B40-35BC77DA9A2E@informatik.uni-kiel.de> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <140A1721-0EB6-41D6-8B40-35BC77DA9A2E@informatik.uni-kiel.de> Message-ID: <75A59E78-2ED1-4971-A6E1-A01A2C657293@cs.uu.nl> On 10 feb 2010, at 10:40, Sebastian Fischer wrote: > > On Feb 9, 2010, at 10:43 PM, S. Doaitse Swierstra wrote: > >> -- but if we now unfold the definition of one we get a parser error >> in GHC >> increment' = ( let x=1 in x + ) >> >> The GHC and Hugs parsers are trying so hard to adhere to the meta >> rule that bodies of let-expressions >> extend as far as possible when needed in order to avoid ambiguity, >> that they even apply that rule when there is no ambiguity; >> here we have only a single possible parse, i.e. interpreting the >> offending expression as ((let x = 1 in ) +). > > Despite the fact that there is a typo (second x is missing), I can > think of two possible parses. Actually, my mental parser produced > the second one: > > ((let x=1 in x)+) > let x=1 in (x+) > > The Haskell report may exclude my mental parse because operator > sections need to be parenthesised. Indeed, but it is not "may exclude", but "excludes". > > Or are you arguing that in your example different possible parses > have the same semantics for an arguably obvious reason and that this > fact is relevant? No, Doaitse > > Sebastian > > > -- > Underestimating the novelty of the future is a time-honored tradition. > (D.G.) > > From JohnDEarle at cox.net Thu Feb 11 12:43:08 2010 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Feb 11 12:14:16 2010 Subject: Negation In-Reply-To: References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <8C9A31E7C9AF45BDBD84AC7AF51129B1@JohnPC> Possible Solution There is a reason why lexical analysis follows the maximal munch rule whereas a parser will follow the minimal munch rule which I won't discuss, a fact that many of you may thank me for. Stated simply, the two operations, lexical analysis and parsing, correspond to different paradigms. I have done work in this area. If the compiler is at some step following the maximal munch rule it is performing lexical analysis and not parsing. Herein, may lie the problem. What this means is that the Haskell language needs to be compiled in stages wherein there is at least one intermediate language that in turn is the subject of lexical analysis followed by parsing. If the Haskell language specification makes this clear, the problem may go away. -------------------------------------------------- From: "S. Doaitse Swierstra" Sent: 09 Tuesday February 2010 1443 To: "Haskell Prime" Subject: Re: Negation > One we start discussing syntax again it might be a good occasion to > reformulate/make more precise a few points. > > The following program is accepted by the Utrecht Haskell Compiler > (here we took great effort to follow the report closely ;-} instead of > spending our time on n+k patterns), but not by the GHC and Hugs. > > module Main where > > -- this is a (rather elaborate) definition of the number 1 > one = let x=1 in x > > -- this is a definition of the successor function using section notation > increment = ( one + ) > > -- but if we now unfold the definition of one we get a parser error in > GHC > increment' = ( let x=1 in x + ) > > The GHC and Hugs parsers are trying so hard to adhere to the meta rule > that bodies of let-expressions > extend as far as possible when needed in order to avoid ambiguity, > that they even apply that rule when there is no ambiguity; > here we have only a single possible parse, i.e. interpreting the > offending expression as ((let x = 1 in ) +). > > Yes, Haskell is both a difficult language to parse and to describe > precisely. > > Doaitse From marlowsd at gmail.com Sat Feb 13 14:37:36 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Sat Feb 13 14:08:37 2010 Subject: Negation In-Reply-To: <20100208230429.GA24543@soi.city.ac.uk> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <20100208212455.GC16245@sliver.repetae.net> <20100208230429.GA24543@soi.city.ac.uk> Message-ID: <4B76FF80.7090203@gmail.com> On 08/02/10 23:04, Ross Paterson wrote: > On Mon, Feb 08, 2010 at 01:24:55PM -0800, John Meacham wrote: >> What would be the actual change proposed? If it is something concrete >> and not something like "negatives should be interpreted as unary minus >> when otherwise it would lead to a parse error" then that wouldn't be >> good. I have enough issues with the layout rule as is :) > > I imagine it would be something like deleting the production > > lexp6 -> - exp7 > > and adding the production > > exp10 -> - fexp Remember that Haskell 2010 changed things here, so that production no longer exists: http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution the equivalent change can be made in the new formulation, of course, and would probably simplify it. Cheers, Simon From marlowsd at gmail.com Sat Feb 13 14:42:30 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Sat Feb 13 14:13:38 2010 Subject: Negation In-Reply-To: References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <4B7700A6.5080503@gmail.com> On 10/02/10 07:53, Atze Dijkstra wrote: > > On 10 Feb, 2010, at 00:53 , Lennart Augustsson wrote: > >> Do you deal with this correctly as well: >> case () of _ -> 1==1==True > > No, that is, in the same way as GHC & Hugs, by reporting an error. Note that Haskell 2010 now specifies that expression to be a precedence parsing error, assuming that == is nonfix. http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution Cheers, Simon From marlowsd at gmail.com Sat Feb 13 14:56:07 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Sat Feb 13 14:27:08 2010 Subject: Negation In-Reply-To: References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <4B7703D7.8040902@gmail.com> On 09/02/10 21:43, S. Doaitse Swierstra wrote: > One we start discussing syntax again it might be a good occasion to > reformulate/make more precise a few points. > > The following program is accepted by the Utrecht Haskell Compiler (here > we took great effort to follow the report closely ;-} instead of > spending our time on n+k patterns), but not by the GHC and Hugs. > > module Main where > > -- this is a (rather elaborate) definition of the number 1 > one = let x=1 in x > > -- this is a definition of the successor function using section notation > increment = ( one + ) > > -- but if we now unfold the definition of one we get a parser error in GHC > increment' = ( let x=1 in x + ) Now that *is* an interesting example. I had no idea we had a bug in that area. Seems to me that it ought to be possible to fix it by refactoring the grammar, but I haven't tried yet. Are there any more of these that you know about? Cheers, Simon From john at galois.com Sat Feb 13 19:48:38 2010 From: john at galois.com (John Launchbury) Date: Sat Feb 13 19:19:38 2010 Subject: Negation In-Reply-To: <4B7703D7.8040902@gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <4B7703D7.8040902@gmail.com> Message-ID: I don't think this is a bug. I do not expect to be able to unfold a definition without some syntactic issues. For example, two = 1+1 four = 2 * two but unfolding fails (four = 2 * 1 + 1). In general, we expect to have to parenthesize things when unfolding them. John On Feb 13, 2010, at 11:56 AM, Simon Marlow wrote: > On 09/02/10 21:43, S. Doaitse Swierstra wrote: >> One we start discussing syntax again it might be a good occasion to >> reformulate/make more precise a few points. >> >> The following program is accepted by the Utrecht Haskell Compiler (here >> we took great effort to follow the report closely ;-} instead of >> spending our time on n+k patterns), but not by the GHC and Hugs. >> >> module Main where >> >> -- this is a (rather elaborate) definition of the number 1 >> one = let x=1 in x >> >> -- this is a definition of the successor function using section notation >> increment = ( one + ) >> >> -- but if we now unfold the definition of one we get a parser error in GHC >> increment' = ( let x=1 in x + ) > > Now that *is* an interesting example. I had no idea we had a bug in that area. Seems to me that it ought to be possible to fix it by refactoring the grammar, but I haven't tried yet. > > Are there any more of these that you know about? > > Cheers, > Simon > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime From lennart at augustsson.net Sat Feb 13 21:21:54 2010 From: lennart at augustsson.net (Lennart Augustsson) Date: Sat Feb 13 20:52:52 2010 Subject: Negation In-Reply-To: References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <4B7703D7.8040902@gmail.com> Message-ID: I agree, I don't think this is a bug. If the grammar actually says that this is legal, then I think the grammar is wrong. On Sun, Feb 14, 2010 at 1:48 AM, John Launchbury wrote: > I don't think this is a bug. I do not expect to be able to unfold a definition without some syntactic issues. For example, > > two = 1+1 > four = 2 * two > > but unfolding fails (four = 2 * 1 + 1). In general, we expect to have to parenthesize things when unfolding them. > > John > > > On Feb 13, 2010, at 11:56 AM, Simon Marlow wrote: > >> On 09/02/10 21:43, S. Doaitse Swierstra wrote: >>> One we start discussing syntax again it might be a good occasion to >>> reformulate/make more precise a few points. >>> >>> The following program is accepted by the Utrecht Haskell Compiler (here >>> we took great effort to follow the report closely ;-} instead of >>> spending our time on n+k patterns), but not by the GHC and Hugs. >>> >>> module Main where >>> >>> -- this is a (rather elaborate) definition of the number 1 >>> one = let x=1 in x >>> >>> -- this is a definition of the successor function using section notation >>> increment = ( one + ) >>> >>> -- but if we now unfold the definition of one we get a parser error in GHC >>> increment' = ( let x=1 in x + ) >> >> Now that *is* an interesting example. ?I had no idea we had a bug in that area. Seems to me that it ought to be possible to fix it by refactoring the grammar, but I haven't tried yet. >> >> Are there any more of these that you know about? >> >> Cheers, >> ? ? ? Simon >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-prime > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From igloo at earth.li Sat Feb 13 21:44:39 2010 From: igloo at earth.li (Ian Lynagh) Date: Sat Feb 13 21:15:36 2010 Subject: Negation In-Reply-To: References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <4B7703D7.8040902@gmail.com> Message-ID: <20100214024439.GA12450@matrix.chaos.earth.li> On Sun, Feb 14, 2010 at 03:21:54AM +0100, Lennart Augustsson wrote: > I agree, I don't think this is a bug. If the grammar actually says > that this is legal, then I think the grammar is wrong. Then what do you think the grammar should say instead? That sections should be ( fexp qop ) ? I've never been keen on (1 * 2 +) actually; and I've just discovered that hugs doesn't accept it. Thanks Ian > On Sun, Feb 14, 2010 at 1:48 AM, John Launchbury wrote: > > I don't think this is a bug. I do not expect to be able to unfold a definition without some syntactic issues. For example, > > > > two = 1+1 > > four = 2 * two > > > > but unfolding fails (four = 2 * 1 + 1). In general, we expect to have to parenthesize things when unfolding them. > > > > John > > > > > > On Feb 13, 2010, at 11:56 AM, Simon Marlow wrote: > > > >> On 09/02/10 21:43, S. Doaitse Swierstra wrote: > >>> One we start discussing syntax again it might be a good occasion to > >>> reformulate/make more precise a few points. > >>> > >>> The following program is accepted by the Utrecht Haskell Compiler (here > >>> we took great effort to follow the report closely ;-} instead of > >>> spending our time on n+k patterns), but not by the GHC and Hugs. > >>> > >>> module Main where > >>> > >>> -- this is a (rather elaborate) definition of the number 1 > >>> one = let x=1 in x > >>> > >>> -- this is a definition of the successor function using section notation > >>> increment = ( one + ) > >>> > >>> -- but if we now unfold the definition of one we get a parser error in GHC > >>> increment' = ( let x=1 in x + ) > >> > >> Now that *is* an interesting example. ?I had no idea we had a bug in that area. Seems to me that it ought to be possible to fix it by refactoring the grammar, but I haven't tried yet. > >> > >> Are there any more of these that you know about? From marlowsd at gmail.com Sun Feb 14 03:32:15 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Sun Feb 14 03:03:16 2010 Subject: Negation In-Reply-To: References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <4B7703D7.8040902@gmail.com> Message-ID: <4B77B50F.4060705@gmail.com> On 14/02/10 02:21, Lennart Augustsson wrote: > I agree, I don't think this is a bug. If the grammar actually says > that this is legal, then I think the grammar is wrong. As far as I can tell Doitse is correct in that GHC does not implement the grammar, so it's either a bug in GHC or the grammar. To fix it in the grammar would no doubt involve quite a bit of refactoring, I can't immediately see how to do it easily. Cheers, Simon > > On Sun, Feb 14, 2010 at 1:48 AM, John Launchbury wrote: >> I don't think this is a bug. I do not expect to be able to unfold a definition without some syntactic issues. For example, >> >> two = 1+1 >> four = 2 * two >> >> but unfolding fails (four = 2 * 1 + 1). In general, we expect to have to parenthesize things when unfolding them. >> >> John >> >> >> On Feb 13, 2010, at 11:56 AM, Simon Marlow wrote: >> >>> On 09/02/10 21:43, S. Doaitse Swierstra wrote: >>>> One we start discussing syntax again it might be a good occasion to >>>> reformulate/make more precise a few points. >>>> >>>> The following program is accepted by the Utrecht Haskell Compiler (here >>>> we took great effort to follow the report closely ;-} instead of >>>> spending our time on n+k patterns), but not by the GHC and Hugs. >>>> >>>> module Main where >>>> >>>> -- this is a (rather elaborate) definition of the number 1 >>>> one = let x=1 in x >>>> >>>> -- this is a definition of the successor function using section notation >>>> increment = ( one + ) >>>> >>>> -- but if we now unfold the definition of one we get a parser error in GHC >>>> increment' = ( let x=1 in x + ) >>> >>> Now that *is* an interesting example. I had no idea we had a bug in that area. Seems to me that it ought to be possible to fix it by refactoring the grammar, but I haven't tried yet. >>> >>> Are there any more of these that you know about? >>> >>> Cheers, >>> Simon >>> _______________________________________________ >>> Haskell-prime mailing list >>> Haskell-prime@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-prime >> >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-prime >> From atze at xs4all.nl Sun Feb 14 04:04:48 2010 From: atze at xs4all.nl (Atze Dijkstra) Date: Sun Feb 14 03:35:47 2010 Subject: Negation In-Reply-To: <4B77B50F.4060705@gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <4B7703D7.8040902@gmail.com> <4B77B50F.4060705@gmail.com> Message-ID: <7DAE4A5B-32D6-49FB-B0DE-248106B02F44@xs4all.nl> In UHC it was unpleasant to make it work, because in (e) and (e +) it only is detected just before the closing parenthesis which of the two alternatives (i.e. parenthesized or sectioned expression) must be chosen. The use of LL parsing aggravates this somewhat, so the required left-factoring now takes into account everything that may be accepted between parenthesis in one parser (also (e1,e2,...), (e::t)), and then later on sorts out the correct choice; a 2-pass approach thus. For LR parsing I expect this to be simpler. However, because it concerns examples into which apparently few have stumbled, I'd be happy to follow Ian's suggestion that sections have the syntax: ( fexp qop ) I have no idea though how many programs will break on this. cheers, Atze On 14 Feb, 2010, at 09:32 , Simon Marlow wrote: > On 14/02/10 02:21, Lennart Augustsson wrote: >> I agree, I don't think this is a bug. If the grammar actually says >> that this is legal, then I think the grammar is wrong. > > As far as I can tell Doitse is correct in that GHC does not > implement the grammar, so it's either a bug in GHC or the grammar. > To fix it in the grammar would no doubt involve quite a bit of > refactoring, I can't immediately see how to do it easily. > > Cheers, > Simon > >> >> On Sun, Feb 14, 2010 at 1:48 AM, John Launchbury >> wrote: >>> I don't think this is a bug. I do not expect to be able to unfold >>> a definition without some syntactic issues. For example, >>> >>> two = 1+1 >>> four = 2 * two >>> >>> but unfolding fails (four = 2 * 1 + 1). In general, we expect to >>> have to parenthesize things when unfolding them. >>> >>> John >>> >>> >>> On Feb 13, 2010, at 11:56 AM, Simon Marlow wrote: >>> >>>> On 09/02/10 21:43, S. Doaitse Swierstra wrote: >>>>> One we start discussing syntax again it might be a good occasion >>>>> to >>>>> reformulate/make more precise a few points. >>>>> >>>>> The following program is accepted by the Utrecht Haskell >>>>> Compiler (here >>>>> we took great effort to follow the report closely ;-} instead of >>>>> spending our time on n+k patterns), but not by the GHC and Hugs. >>>>> >>>>> module Main where >>>>> >>>>> -- this is a (rather elaborate) definition of the number 1 >>>>> one = let x=1 in x >>>>> >>>>> -- this is a definition of the successor function using section >>>>> notation >>>>> increment = ( one + ) >>>>> >>>>> -- but if we now unfold the definition of one we get a parser >>>>> error in GHC >>>>> increment' = ( let x=1 in x + ) >>>> >>>> Now that *is* an interesting example. I had no idea we had a bug >>>> in that area. Seems to me that it ought to be possible to fix it >>>> by refactoring the grammar, but I haven't tried yet. >>>> >>>> Are there any more of these that you know about? >>>> >>>> Cheers, >>>> Simon >>>> _______________________________________________ >>>> Haskell-prime mailing list >>>> Haskell-prime@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-prime >>> >>> _______________________________________________ >>> Haskell-prime mailing list >>> Haskell-prime@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-prime >>> > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime From doaitse at cs.uu.nl Sun Feb 14 05:25:07 2010 From: doaitse at cs.uu.nl (S. Doaitse Swierstra) Date: Sun Feb 14 04:56:05 2010 Subject: Negation In-Reply-To: <4B77B50F.4060705@gmail.com> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <4B7703D7.8040902@gmail.com> <4B77B50F.4060705@gmail.com> Message-ID: <69E39A81-365C-42A9-A241-E515AD5DA3F7@cs.uu.nl> On 14 feb 2010, at 09:32, Simon Marlow wrote: > On 14/02/10 02:21, Lennart Augustsson wrote: >> I agree, I don't think this is a bug. If the grammar actually says >> that this is legal, then I think the grammar is wrong. > > As far as I can tell Doitse is correct in that GHC does not > implement the grammar, so it's either a bug in GHC or the grammar. > To fix it in the grammar would no doubt involve quite a bit of > refactoring, I can't immediately see how to do it easily. This is indeed not easy, and probably one more situation where some extra text has to exclude this since I actually think it should not be accepted from a language design point of view. How would you explain that weird :: Int -> Int weird = (if True then 3 else 5+) is perfectly correct Haskell? Doaitse > > Cheers, > Simon > >> >> On Sun, Feb 14, 2010 at 1:48 AM, John Launchbury >> wrote: >>> I don't think this is a bug. I do not expect to be able to unfold >>> a definition without some syntactic issues. For example, >>> >>> two = 1+1 >>> four = 2 * two >>> >>> but unfolding fails (four = 2 * 1 + 1). In general, we expect to >>> have to parenthesize things when unfolding them. >>> >>> John >>> >>> >>> On Feb 13, 2010, at 11:56 AM, Simon Marlow wrote: >>> >>>> On 09/02/10 21:43, S. Doaitse Swierstra wrote: >>>>> One we start discussing syntax again it might be a good occasion >>>>> to >>>>> reformulate/make more precise a few points. >>>>> >>>>> The following program is accepted by the Utrecht Haskell >>>>> Compiler (here >>>>> we took great effort to follow the report closely ;-} instead of >>>>> spending our time on n+k patterns), but not by the GHC and Hugs. >>>>> >>>>> module Main where >>>>> >>>>> -- this is a (rather elaborate) definition of the number 1 >>>>> one = let x=1 in x >>>>> >>>>> -- this is a definition of the successor function using section >>>>> notation >>>>> increment = ( one + ) >>>>> >>>>> -- but if we now unfold the definition of one we get a parser >>>>> error in GHC >>>>> increment' = ( let x=1 in x + ) >>>> >>>> Now that *is* an interesting example. I had no idea we had a bug >>>> in that area. Seems to me that it ought to be possible to fix it >>>> by refactoring the grammar, but I haven't tried yet. >>>> >>>> Are there any more of these that you know about? >>>> >>>> Cheers, >>>> Simon >>>> _______________________________________________ >>>> Haskell-prime mailing list >>>> Haskell-prime@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-prime >>> >>> _______________________________________________ >>> Haskell-prime mailing list >>> Haskell-prime@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-prime >>> From Christian.Maeder at dfki.de Sun Feb 14 09:25:55 2010 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Sun Feb 14 08:56:53 2010 Subject: Fixity was: Negation In-Reply-To: <69E39A81-365C-42A9-A241-E515AD5DA3F7@cs.uu.nl> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <4B7703D7.8040902@gmail.com> <4B77B50F.4060705@gmail.com> <69E39A81-365C-42A9-A241-E515AD5DA3F7@cs.uu.nl> Message-ID: <4B7807F3.2010105@dfki.de> S. Doaitse Swierstra schrieb: > weird :: Int -> Int > weird = (if True then 3 else 5+) > > is perfectly correct Haskell? Yes, this is legal according to the grammar http://haskell.org/onlinereport/syntax-iso.html but rejected by ghc and hugs, because "5+" is illegal. The problem is to allow let-, if-, do-, and lambda-expressions to the left of operators (qop), because for those the meta rule "extend as far as possible" should apply. Switching to the new grammar http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution infixexp -> exp10 qop infixexp | - infixexp | exp10 should be replaced by: infixexp -> fexp qop infixexp | exp10 (omitting the negate rule) or shorter: "infixexp -> { fexp qop } exp10" Left sections should look like: ( {fexp qop} fexp qop ) It would be even possible to avoid parenthesis around sections, because a leading or trailing operator (or just a single operator) uniquely determines the kind of expression. Negation should be added independently to fexp (and possibly to exp10, too) fexp -> [fexp] aexp (function application) minusexp -> fexp | - fexp infixexp -> minusexp qop infixexp | exp10 | - exp10 (unless some wants the old FORTRAN behaviour of unary "-" to bind weaker than infix multiplication and exponentiation.) Cheers Christian From Christian.Maeder at dfki.de Sun Feb 14 10:52:49 2010 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Sun Feb 14 10:23:47 2010 Subject: Fixity was: Negation In-Reply-To: <4B7807F3.2010105@dfki.de> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <4B7703D7.8040902@gmail.com> <4B77B50F.4060705@gmail.com> <69E39A81-365C-42A9-A241-E515AD5DA3F7@cs.uu.nl> <4B7807F3.2010105@dfki.de> Message-ID: <4B781C51.4040702@dfki.de> Christian Maeder schrieb: > S. Doaitse Swierstra schrieb: >> weird :: Int -> Int >> weird = (if True then 3 else 5+) [...] > infixexp -> fexp qop infixexp > | exp10 This is no good, because it would exclude: do ... ++ do expressions. > It would be even possible to avoid parenthesis around sections, because > a leading or trailing operator (or just a single operator) uniquely > determines the kind of expression. Maybe this is a solution to the above problem, because "5+" could be legally parsed (and only rejected during type inference). C. From Christian.Maeder at dfki.de Mon Feb 15 05:38:17 2010 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Feb 15 05:09:13 2010 Subject: Fixity In-Reply-To: <4B7807F3.2010105@dfki.de> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <4B7703D7.8040902@gmail.com> <4B77B50F.4060705@gmail.com> <69E39A81-365C-42A9-A241-E515AD5DA3F7@cs.uu.nl> <4B7807F3.2010105@dfki.de> Message-ID: <4B792419.8070104@dfki.de> let me try again to fix the issue. Apologies, if you mind. Christian Maeder schrieb: > S. Doaitse Swierstra schrieb: >> weird :: Int -> Int >> weird = (if True then 3 else 5+) >> >> is perfectly correct Haskell? > > Yes, this is legal according to the grammar > http://haskell.org/onlinereport/syntax-iso.html > but rejected by ghc and hugs, because "5+" is illegal. "5+" is illegal, but therefore neither ghc nor hugs only parse the "5" and assume that the if-then-else-expression is finished after this "5" and leave the "+" to form the section as ((if True then 3 else 5)+) > The problem is to allow let-, if-, do-, and lambda-expressions > to the left of operators (qop), because for those the meta rule > "extend as far as possible" should apply. Do- and case-expressions do not fall in the same class than let-, if-, and lambda-expressions. An operator following let, if and lambda should be impossible because such an operator should belong to the last expression inside let, if and lambda. But do- and case- expressions are terminated by a closing brace. The point is, when this closing brace is inserted. weird2 m = (do m >>) Inserting "}" between "m" and ">>" because "m >>" is illegal, leads to the same problem as above for if-then-else. "}" should be inserted before the ")". hugs and ghc fail because they expect an fexp following ">>". > Switching to the new grammar > http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution > > infixexp -> exp10 qop infixexp > | - infixexp > | exp10 > > should be replaced by: > > infixexp -> fexp qop infixexp > | exp10 > > (omitting the negate rule) > > or shorter: "infixexp -> { fexp qop } exp10" > Assuming that braces are properly inserted, my above (too restrictive) rule can be extended to include case- and do-expressions to "cdexp" (in order to allow operators between them): cdexp -> fexp | - fexp (negation) | do { stmts } | case exp of { alts } exp10 -> cdexp | \ apat1 ... apatn -> exp (n>=1) | let decls in exp | if exp then exp else exp infixexp -> cdexp qop infixexp | exp10 (or: infixexp -> { cdexp qop } exp10") > Left sections should look like: > > ( {fexp qop} fexp qop ) > > It would be even possible to avoid parenthesis around sections, because > a leading or trailing operator (or just a single operator) uniquely > determines the kind of expression. The need to put sections into parenthesis is one cause for the current confusion. Inside the parenthesis the following expressions "iexp" are expected: iexp -> qop (operator turned to prefix-function) | infixexp (parenthesized expression) | infixexp :: [context =>] type (parenthesized typed expression) | qop infixexp (right section) | { cdexp qop } cdexp qop (left section) So another solution would be, to make such expression globally legal in the grammar and reject a single operator, left-, and right sections during a separate infix analysis in a similar way as "a == b == c" is first fully parsed but rejected later, because "==" is non-associative. In fact any (non-empty) sequence of qop and exp10 expressions could be made a legal expression (for the parser only) that is further subject to infix resolution. (This would for example also allow outfix operators via: iexp -> qop { cdexp qop } | ... if desirable for haskell prime.) Is this better now? Cheers Christian > > Negation should be added independently to fexp (and possibly to exp10, too) > > fexp -> [fexp] aexp (function application) > minusexp -> fexp | - fexp > > infixexp -> minusexp qop infixexp > | exp10 > | - exp10 > > (unless some wants the old FORTRAN behaviour of unary "-" to bind weaker > than infix multiplication and exponentiation.) > > Cheers Christian > From nbowler at elliptictech.com Fri Feb 19 14:48:48 2010 From: nbowler at elliptictech.com (Nick Bowler) Date: Fri Feb 19 14:19:29 2010 Subject: Proposal: Hexadecimal floating point constants Message-ID: <20100219194848.GA1193@emergent.ellipticsemi.com> I'd like to propose what I believe is a simple but valuable extension to Haskell that I haven't seen proposed elsewhere. C has something it calls hexadecimal floating constants, and it would be very nice if Haskell had it too. For floating point systems where the radix is a power of two (very common), they offer a means of clearly and exactly specifying any finite floating point value. For example, suppose we want to write the least positive value of an IEEE754 double. With hexadecimal floating constants, we write 0x0.0000000000001p-1022 and a reader can immediately tell what this is. One could equivalently write this in a normalized fashion as 0x1p-1074. The exact representation of this value in base 10 is very, very long (there are over 750 significant digits), but we can abuse roundoff to write it succinctly as 5e-324, which is much less clear about which value was intended. Similarly, the greatest finite double value can be written as 0x1.fffffffffffffp+1023. These constants have the form 0x[HH][.HHHHH]p[+/-]DDD where we have the hexadecimal prefix 0x, zero or more hexadecimal digits, and an optional fractional separator followed by zero or more hexadecimal digits. There must be at least one hexadecimal digit. Finally, there is a p followed by an (optionally signed) exponent encoded in decimal. The hexadecimal digits are interpreted in the obvious way and then scaled by 2 raised to the given exponent. Implementing this proposal would change the meaning of expressions like let p4 = 5 in (+) 0x5p4 I don't believe anyone writes code like that, but it's resolved by adding a space, as in let p4 = 5 in (+) 0x5 p4 -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) From apfelmus at quantentunnel.de Sat Feb 20 06:26:32 2010 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Sat Feb 20 05:57:40 2010 Subject: Proposal: Hexadecimal floating point constants In-Reply-To: <20100219194848.GA1193@emergent.ellipticsemi.com> References: <20100219194848.GA1193@emergent.ellipticsemi.com> Message-ID: Nick Bowler wrote: > I'd like to propose what I believe is a simple but valuable extension to > Haskell that I haven't seen proposed elsewhere. > > C has something it calls hexadecimal floating constants, and it would be > very nice if Haskell had it too. For floating point systems where the > radix is a power of two (very common), they offer a means of clearly and > exactly specifying any finite floating point value. > > [..] > > Similarly, the greatest finite double value can be written as > 0x1.fffffffffffffp+1023. > > These constants have the form > > 0x[HH][.HHHHH]p[+/-]DDD If you don't want to wait on an (uncertain) inclusion into the Haskell standard, you can implement a small helper function to that effect yourself; essentially using encodeFloat . Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From cgibbard at gmail.com Sun Feb 21 20:17:24 2010 From: cgibbard at gmail.com (Cale Gibbard) Date: Sun Feb 21 19:48:00 2010 Subject: Negation In-Reply-To: <20100208165958.GA14892@soi.city.ac.uk> References: <59543203684B2244980D7E4057D5FBC10AFD2CFE@DB3EX14MBXC306.europe.corp.microsoft.com> <20100208165958.GA14892@soi.city.ac.uk> Message-ID: <89ca3d1f1002211717o5feab66cm85648cbc4d76bc50@mail.gmail.com> > But I agree they should all be legal, i.e. that unary minus should bind > more tightly than any infix operator (as in C). I'd just like to interject that I disagree, and think that the current behaviour is about as good as one could hope for. Negation is an additive operation, and thus has lower precedence than multiplication and exponentiation. -x^2 must be interpreted as -(x^2), not as (-x)^2. Similarly, though it seems to confuse some people, it makes more sense that - x `mod` y is parsed as - (x `mod` y) since mod has to do with multiplication, so it should bind more tightly than additive operations. - Cale From simonpj at microsoft.com Mon Feb 22 08:15:46 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Feb 22 07:46:42 2010 Subject: Proposal: Hexadecimal floating point constants In-Reply-To: References: <20100219194848.GA1193@emergent.ellipticsemi.com> Message-ID: <59543203684B2244980D7E4057D5FBC10B0707FA@DB3EX14MBXC306.europe.corp.microsoft.com> | > Similarly, the greatest finite double value can be written as | > 0x1.fffffffffffffp+1023. | > | > These constants have the form | > | > 0x[HH][.HHHHH]p[+/-]DDD | | If you don't want to wait on an (uncertain) inclusion into the Haskell | standard, you can implement a small helper function to that effect | yourself; essentially using encodeFloat . Or, alternatively, use quasiquoting [hex| 1.fffffp+1023 |] where 'hex' is a Haskell function that parses the string. http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.html#th-quasiquotation This has the advantage that you can use the constant in patterns too. (In GHC 6.12 you have to say [$hex| 1.ffffp+1023 |], with a "$", but we're changing that for 6.14. There's a thread on ghc-users about it.) Simon From Malcolm.Wallace at cs.york.ac.uk Mon Feb 22 12:08:14 2010 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Feb 22 11:39:25 2010 Subject: Haskell prime: the sequel (2011) Message-ID: <3BACDBA9-A0ED-4B1D-B8E2-CA7D5F24CDF3@cs.york.ac.uk> http://hackage.haskell.org/trac/haskell-prime The new committee for Haskell language standardisation has been appointed, based on public nominations. I am the new chair. http://hackage.haskell.org/trac/haskell-prime/wiki/Committee In case you missed it, the previous committee resulted in the minor revision of the language called Haskell 2010. The next revision (Haskell 2011) is due to be decided later this year, around October- November, and published by the beginning of 2011. I would like to emphasise that the future of Haskell is in the hands of the whole community - and that means you. The committee's role is to make decisions, but the task of making and refining proposals belongs with the language's users. Please cogitate, agitate, and formulate! Here is how to get your language idea accepted: http://hackage.haskell.org/trac/haskell-prime/wiki/Process (Don't forget that you can propose _removal_ of features, as well as additions.) Regards, Malcolm From ross at soi.city.ac.uk Mon Feb 22 17:10:57 2010 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Feb 22 16:42:00 2010 Subject: Haskell prime: the sequel (2011) In-Reply-To: <3BACDBA9-A0ED-4B1D-B8E2-CA7D5F24CDF3@cs.york.ac.uk> References: <3BACDBA9-A0ED-4B1D-B8E2-CA7D5F24CDF3@cs.york.ac.uk> Message-ID: <20100222221057.GA8162@soi.city.ac.uk> On Mon, Feb 22, 2010 at 05:08:14PM +0000, Malcolm Wallace wrote: > In case you missed it, the previous committee resulted in the minor > revision of the language called Haskell 2010. Is the revised report available somewhere? From marlowsd at gmail.com Mon Feb 22 18:02:54 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 22 17:33:28 2010 Subject: Haskell prime: the sequel (2011) In-Reply-To: <20100222221057.GA8162@soi.city.ac.uk> References: <3BACDBA9-A0ED-4B1D-B8E2-CA7D5F24CDF3@cs.york.ac.uk> <20100222221057.GA8162@soi.city.ac.uk> Message-ID: <4B830D1E.8030204@gmail.com> On 22/02/10 22:10, Ross Paterson wrote: > On Mon, Feb 22, 2010 at 05:08:14PM +0000, Malcolm Wallace wrote: >> In case you missed it, the previous committee resulted in the minor >> revision of the language called Haskell 2010. > > Is the revised report available somewhere? Not yet, I plan to start work on it next month. Cheers, Simon From phercek at gmail.com Tue Feb 23 04:55:14 2010 From: phercek at gmail.com (Peter Hercek) Date: Tue Feb 23 04:26:01 2010 Subject: location of Haskell reports Message-ID: Should not be there a link to Haskell 2010 report on this page? http://haskell.org/haskellwiki/Language_and_library_specification That is if Haskell 2010 is finalized. Where is the standard location to find "Haskel Prime" reports? Peter. From nbowler at elliptictech.com Tue Feb 23 09:56:30 2010 From: nbowler at elliptictech.com (Nick Bowler) Date: Tue Feb 23 09:27:01 2010 Subject: Proposal: Hexadecimal floating point constants In-Reply-To: <59543203684B2244980D7E4057D5FBC10B0707FA@DB3EX14MBXC306.europe.corp.microsoft.com> References: <20100219194848.GA1193@emergent.ellipticsemi.com> <59543203684B2244980D7E4057D5FBC10B0707FA@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <20100223145630.GA20728@emergent.ellipticsemi.com> On 12:26 Sat 20 Feb , Heinrich Apfelmus wrote: > Nick Bowler wrote: > > Similarly, the greatest finite double value can be written as > > 0x1.fffffffffffffp+1023. > > > > These constants have the form > > > > 0x[HH][.HHHHH]p[+/-]DDD > > If you don't want to wait on an (uncertain) inclusion into the Haskell > standard, you can implement a small helper function to that effect > yourself; essentially using encodeFloat . Indeed, I have already implemented such a function. My gripe here is that it's extremely cumbersome to use such a function in a program, and it adds the possibily of programs crashing due to syntax errors at runtime. On 13:15 Mon 22 Feb , Simon Peyton-Jones wrote: > Or, alternatively, use quasiquoting > > [hex| 1.fffffp+1023 |] Ah, I was not aware of this feature. It does seem like a decent solution, in that it allows errors to be caught at compile time. Somewhat more verbose than I had hoped, but it's probably fine. Thanks. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) From dav.vire+haskell at gmail.com Tue Feb 23 10:04:51 2010 From: dav.vire+haskell at gmail.com (David Virebayre) Date: Tue Feb 23 09:35:20 2010 Subject: location of Haskell reports In-Reply-To: References: Message-ID: <4c88418c1002230704v2309fb8aj6ba278b16653fcd6@mail.gmail.com> On Tue, Feb 23, 2010 at 10:55 AM, Peter Hercek wrote: > Should not be there a link to Haskell 2010 report on this page? > Simon wrote on another thread that he plans to work on it next month. David. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20100223/cd60af36/attachment.html From iavor.diatchki at gmail.com Tue Feb 23 22:07:30 2010 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Feb 23 21:37:57 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 Message-ID: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> Hello, I'd like to propose that we add record punning to Haskell 2011. I think that this is a useful feature which makes working with record fields easier, and reduces clutter in definitions, both in patterns and expressions. Furthermore, this features has been implemented in GHC for a long time (it used to be in Hugs too, once) and we've had plenty of time to iron out dark corners in the design. Thoughts, objections, suggestions? -Iavor From malcolm.wallace at cs.york.ac.uk Wed Feb 24 04:35:52 2010 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Feb 24 04:06:18 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 In-Reply-To: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> Message-ID: <03C8BDD4-814D-45F2-BB8C-7268AD7CFB43@cs.york.ac.uk> > I'd like to propose that we add record punning to Haskell 2011. Can you be more specific? Do you propose to re-instate punning exactly as it was specified in Haskell 1.3? Or do you propose in addition some of the newer extensions that have been recently implemented in ghc (but not other compilers), such as record wildcards? Regards, Malcolm From iavor.diatchki at gmail.com Wed Feb 24 13:14:49 2010 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Feb 24 12:45:14 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 In-Reply-To: <5ab17e791002241013m48c6b144lb6911ed311e50970@mail.gmail.com> References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <03C8BDD4-814D-45F2-BB8C-7268AD7CFB43@cs.york.ac.uk> <5ab17e791002241013m48c6b144lb6911ed311e50970@mail.gmail.com> Message-ID: <5ab17e791002241014p363574d8j3603e957cf5b4494@mail.gmail.com> Hello, (Malcolm, sorry for the double post, I forgot to CC the list) I was thinking mostly about the "old-time"-y punning, where I can write a label, say "theField", and it automatically gets expanded to "theField = theField", in record patterns and record constructing expressions. The only corner case that I can remember about this is the interaction with qualified names, the issue being what happens if a label in a pun is qualified? ?I think that in such cases we should just used the unqualified form for the variable associated with the label. ?In patterns, I can't think of any other sensible alternative. ?In expressions, I could imaging expanding "A.theField" to "A.theField = A.theField" but it seems that this would almost never be what we want, while in all the uses I've had "A.theField = theField" is what was needed. I think that this is exactly what GHC implements, at least based on the following example: module A where data T = C { f :: Int } {-# LANGUAGE NamedFieldPuns #-} module B where import qualified A testPattern (A.C { A.f }) = f testExpr f ? ? ? ? ? ? ? ?= A.C { A.f } I imagine that this is fairly close to what was in Haskell 1.3? ? As far as wild-cards are concerned, I don't feel particularly strongly about them either way (I can see some benefits and some drawbacks) so I'd be happy to leave them for a separate proposal or add them to this one, depending on how the rest of the community feels. -Iavor On Wed, Feb 24, 2010 at 1:35 AM, Malcolm Wallace wrote: >> I'd like to propose that we add record punning to Haskell 2011. > > Can you be more specific? ?Do you propose to re-instate punning exactly as > it was specified in Haskell 1.3? ?Or do you propose in addition some of the > newer extensions that have been recently implemented in ghc (but not other > compilers), such as record wildcards? > > Regards, > ? ?Malcolm > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From igloo at earth.li Wed Feb 24 13:23:39 2010 From: igloo at earth.li (Ian Lynagh) Date: Wed Feb 24 12:54:08 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 In-Reply-To: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> Message-ID: <20100224182339.GA1120@matrix.chaos.earth.li> On Tue, Feb 23, 2010 at 07:07:30PM -0800, Iavor Diatchki wrote: > > I'd like to propose that we add record punning to Haskell 2011. > > Thoughts, objections, suggestions? I have a feeling I'm in the minority, but I find record punning an ugly feature. Given data T = C { f :: Int } we implicitly get f :: T -> Int which punning shadows with f :: Int whereas I generally avoid shadowing completely. Thanks Ian From martijn at van.steenbergen.nl Wed Feb 24 13:40:37 2010 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Wed Feb 24 13:11:12 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 In-Reply-To: <20100224182339.GA1120@matrix.chaos.earth.li> References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> Message-ID: <4B8572A5.4000305@van.steenbergen.nl> Ian Lynagh wrote: > I have a feeling I'm in the minority, but I find record punning an ugly > feature. > > Given > data T = C { f :: Int } > we implicitly get > f :: T -> Int > which punning shadows with > f :: Int > whereas I generally avoid shadowing completely. I agree with Ian. Groetjes, Martijn. From john at repetae.net Wed Feb 24 13:52:08 2010 From: john at repetae.net (John Meacham) Date: Wed Feb 24 13:22:37 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 In-Reply-To: <20100224182339.GA1120@matrix.chaos.earth.li> References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> Message-ID: <20100224185207.GB1714@sliver.repetae.net> On Wed, Feb 24, 2010 at 06:23:39PM +0000, Ian Lynagh wrote: > On Tue, Feb 23, 2010 at 07:07:30PM -0800, Iavor Diatchki wrote: > I have a feeling I'm in the minority, but I find record punning an ugly > feature. > > Given > data T = C { f :: Int } > we implicitly get > f :: T -> Int > which punning shadows with > f :: Int > whereas I generally avoid shadowing completely. I can see the thinking here, but I don't like for the language to try to enforce 'style' or make decisions based on it. I think it is more in the spirit of haskell to provide multiple mechanisms when it makes sense and let the users figure out what works for them stylistically. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From tatd2 at kent.ac.uk Wed Feb 24 13:54:44 2010 From: tatd2 at kent.ac.uk (Thomas Davie) Date: Wed Feb 24 13:25:16 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 In-Reply-To: <20100224185207.GB1714@sliver.repetae.net> References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> <20100224185207.GB1714@sliver.repetae.net> Message-ID: On 24 Feb 2010, at 18:52, John Meacham wrote: > On Wed, Feb 24, 2010 at 06:23:39PM +0000, Ian Lynagh wrote: >> On Tue, Feb 23, 2010 at 07:07:30PM -0800, Iavor Diatchki wrote: >> I have a feeling I'm in the minority, but I find record punning an ugly >> feature. >> >> Given >> data T = C { f :: Int } >> we implicitly get >> f :: T -> Int >> which punning shadows with >> f :: Int >> whereas I generally avoid shadowing completely. > > I can see the thinking here, but I don't like for the language to try to > enforce 'style' or make decisions based on it. I think it is more in the > spirit of haskell to provide multiple mechanisms when it makes sense and > let the users figure out what works for them stylistically. The problem though, unless I'm misunderstanding, is that you *must* enforce one or other convention here. Either you force everyone who's style is to never shadow things to do so because of this language feature, or you remove the language feature and trample on the other crowd. For what it's worth, I'd side with Ian on this one. Bob From john at repetae.net Wed Feb 24 14:03:23 2010 From: john at repetae.net (John Meacham) Date: Wed Feb 24 13:33:51 2010 Subject: RECOMMENDATION: Use 'labeled fields' rather than records when talking about labeled fields Message-ID: <20100224190321.GC1714@sliver.repetae.net> This isn't so much a proposal as a recommendation for terminology we use when talking about things on the list and proposals in general. Calling haskell's labeled field mechanism 'records' leads to all sorts of confusion for people that come from other languages where 'records' means something else, this is compounded by the fact there are several actual record proposals out there that are orthogonal to labeled fields, but calling fields 'records' confuses this issue. I believe we have already gotten rid of every reference to 'record' in the report in favor of 'labeled field' or just 'field', so it would be good if we could use the same terminology in all discussions. Not only will it help avoid confusion but it is a more accurate description of what Haskell actually provides and is in line with the report. So, let's call 'record puns' 'field puns' as a first step. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From john at repetae.net Wed Feb 24 14:06:03 2010 From: john at repetae.net (John Meacham) Date: Wed Feb 24 13:36:28 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 In-Reply-To: References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> <20100224185207.GB1714@sliver.repetae.net> Message-ID: <20100224190603.GD1714@sliver.repetae.net> On Wed, Feb 24, 2010 at 06:54:44PM +0000, Thomas Davie wrote: > The problem though, unless I'm misunderstanding, is that you *must* > enforce one or other convention here. Either you force everyone who's > style is to never shadow things to do so because of this language > feature, or you remove the language feature and trample on the other > crowd. Hmm? I don't see how this language feature forces shadowing any more than allowing shadowing anywhere else in the language. It is not proposed that field punning replace the previous mechanism for assigning or pulling values from fields, just that it be added as an option. Just as it has always been an option to shadow variables in do notation. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From qdunkan at gmail.com Wed Feb 24 14:35:44 2010 From: qdunkan at gmail.com (Evan Laforge) Date: Wed Feb 24 14:06:08 2010 Subject: RECOMMENDATION: Use 'labeled fields' rather than records when talking about labeled fields In-Reply-To: <20100224190321.GC1714@sliver.repetae.net> References: <20100224190321.GC1714@sliver.repetae.net> Message-ID: <2518b95d1002241135w2e61de2di2bc2f8a8512fd72@mail.gmail.com> On Wed, Feb 24, 2010 at 11:03 AM, John Meacham wrote: > This isn't so much a proposal as a recommendation for terminology we use > when talking about things on the list and proposals in general. Calling > haskell's labeled field mechanism 'records' leads to all sorts of > confusion for people that come from other languages where 'records' > means something else, this is compounded by the fact there are several > actual record proposals out there that are orthogonal to labeled fields, > but calling fields 'records' confuses this issue. Just out of curiosity, what are the attributes associated with "labeled fields" and what are the ones associated with "records"? From john at repetae.net Wed Feb 24 14:50:58 2010 From: john at repetae.net (John Meacham) Date: Wed Feb 24 14:21:25 2010 Subject: RECOMMENDATION: Use 'labeled fields' rather than records when talking about labeled fields In-Reply-To: <2518b95d1002241135w2e61de2di2bc2f8a8512fd72@mail.gmail.com> References: <20100224190321.GC1714@sliver.repetae.net> <2518b95d1002241135w2e61de2di2bc2f8a8512fd72@mail.gmail.com> Message-ID: <20100224195058.GA9898@sliver.repetae.net> On Wed, Feb 24, 2010 at 11:35:44AM -0800, Evan Laforge wrote: > On Wed, Feb 24, 2010 at 11:03 AM, John Meacham wrote: > > This isn't so much a proposal as a recommendation for terminology we use > > when talking about things on the list and proposals in general. Calling > > haskell's labeled field mechanism 'records' leads to all sorts of > > confusion for people that come from other languages where 'records' > > means something else, this is compounded by the fact there are several > > actual record proposals out there that are orthogonal to labeled fields, > > but calling fields 'records' confuses this issue. > > Just out of curiosity, what are the attributes associated with > "labeled fields" and what are the ones associated with "records"? Well, when you have a data constructor like data Foo = Foo Int Char your Int and Char are the two fields of your data constructor Foo, labeled fields are exactly that, a way to refer to them by labels rather than positionally. in particular, the run-time implementation and ability for optimization is exactly the same. it is simply a more convienient way to work with a construct that already exists in Haskell with no overhead, like a newtype. A record system generally implies labels that can be easily re-usued between different types and is extensible in nature. They may not need to be pre-declared. Allowing these may require compromises at run-time creating a tension between their utility and performance. I like to think of them more analogous to tuples with labels than declared data types. Of course, not all record proposals for haskell embody the exact same thing, but these features seem to be what people coming to haskell expect out of something called a 'record' system and are more or less what the various proposals provide. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From qdunkan at gmail.com Wed Feb 24 15:21:30 2010 From: qdunkan at gmail.com (Evan Laforge) Date: Wed Feb 24 14:51:53 2010 Subject: RECOMMENDATION: Use 'labeled fields' rather than records when talking about labeled fields In-Reply-To: <20100224195058.GA9898@sliver.repetae.net> References: <20100224190321.GC1714@sliver.repetae.net> <2518b95d1002241135w2e61de2di2bc2f8a8512fd72@mail.gmail.com> <20100224195058.GA9898@sliver.repetae.net> Message-ID: <2518b95d1002241221q7e9dc148v67e18b2ac9a6efe4@mail.gmail.com> On Wed, Feb 24, 2010 at 11:50 AM, John Meacham wrote: > On Wed, Feb 24, 2010 at 11:35:44AM -0800, Evan Laforge wrote: >> On Wed, Feb 24, 2010 at 11:03 AM, John Meacham wrote: >> > This isn't so much a proposal as a recommendation for terminology we use >> > when talking about things on the list and proposals in general. Calling >> > haskell's labeled field mechanism 'records' leads to all sorts of >> > confusion for people that come from other languages where 'records' >> > means something else, this is compounded by the fact there are several >> > actual record proposals out there that are orthogonal to labeled fields, >> > but calling fields 'records' confuses this issue. >> >> Just out of curiosity, what are the attributes associated with >> "labeled fields" and what are the ones associated with "records"? > > Well, when you have a data constructor like > > data Foo = Foo Int Char > > your Int and Char are the two fields of your data constructor Foo, > labeled fields are exactly that, a way to refer to them by labels rather > than positionally. in particular, the run-time implementation and > ability for optimization is exactly the same. it is simply a more > convienient way to work with a construct that already exists in Haskell > with no overhead, like a newtype. Ah, so to paraphrase, fields are just syntax sugar for an ADT + access functions + update syntax. Update syntax is just sugar for a "\b -> A a _ c -> A a b c" expression. Pure sugar. Records are basically "anything more substantial than sugar" but may imply a new "label" concept (i.e. not just reusing functions), literal syntax, extensibility, type system support for subtyping, etc. etc. This seems like a reasonable distinction. From ml at isaac.cedarswampstudios.org Wed Feb 24 15:31:05 2010 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Wed Feb 24 15:01:43 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 In-Reply-To: <4B8572A5.4000305@van.steenbergen.nl> References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> <4B8572A5.4000305@van.steenbergen.nl> Message-ID: <4B858C89.9030507@isaac.cedarswampstudios.org> On 02/24/10 13:40, Martijn van Steenbergen wrote: > Ian Lynagh wrote: >> I have a feeling I'm in the minority, but I find record punning an ugly >> feature. >> >> Given >> data T = C { f :: Int } >> we implicitly get >> f :: T -> Int >> which punning shadows with >> f :: Int >> whereas I generally avoid shadowing completely. > > I agree with Ian. I tend to agree. I don't mind if a few files that use a ton of label-operations are marked with NamedFieldPuns and use that feature a lot. But, funnily, if it were put in the standard then it would be enabled in un-marked source files, and then I personally wouldn't like it as much. (Any decision is acceptable to me though.) -Isaac From marlowsd at gmail.com Wed Feb 24 15:50:42 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Feb 24 15:21:26 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 In-Reply-To: <20100224182339.GA1120@matrix.chaos.earth.li> References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> Message-ID: <4B859122.2020100@gmail.com> On 24/02/10 18:23, Ian Lynagh wrote: > On Tue, Feb 23, 2010 at 07:07:30PM -0800, Iavor Diatchki wrote: >> >> I'd like to propose that we add record punning to Haskell 2011. >> >> Thoughts, objections, suggestions? > > I have a feeling I'm in the minority, but I find record punning an ugly > feature. > > Given > data T = C { f :: Int } > we implicitly get > f :: T -> Int > which punning shadows with > f :: Int > whereas I generally avoid shadowing completely. While I agree with these points, I was converted to record punning (actually record wildcards) when I rewrote the GHC IO library. Handle is a record with 12 or so fields, and there are literally dozens of functions that start like this: flushWriteBuffer :: Handle -> IO () flushWriteBuffer Handle{..} = do if I had to write out the field names I use each time, and even worse, think up names to bind to each of them, it would be hideous. There are reasons to find this distasteful, yes, but I think the alternative is much worse. I'm not proposing record wildcards (yet) *cough* labelled-field wildcards, but punning is a step in the right direction. Cheers, Simon From john at repetae.net Wed Feb 24 16:01:38 2010 From: john at repetae.net (John Meacham) Date: Wed Feb 24 15:32:07 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 In-Reply-To: <4B859122.2020100@gmail.com> References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> <4B859122.2020100@gmail.com> Message-ID: <20100224210138.GB9898@sliver.repetae.net> On Wed, Feb 24, 2010 at 08:50:42PM +0000, Simon Marlow wrote: > On 24/02/10 18:23, Ian Lynagh wrote: > While I agree with these points, I was converted to record punning > (actually record wildcards) when I rewrote the GHC IO library. Handle > is a record with 12 or so fields, and there are literally dozens of > functions that start like this: > > flushWriteBuffer :: Handle -> IO () > flushWriteBuffer Handle{..} = do > > if I had to write out the field names I use each time, and even worse, > think up names to bind to each of them, it would be hideous. > > There are reasons to find this distasteful, yes, but I think the > alternative is much worse. > > I'm not proposing record wildcards (yet) *cough* labelled-field > wildcards, but punning is a step in the right direction. Yes. I too have had this issue with jhc and am a big fan of GHC's field wildcards. It is motivation enough for me to require a newer version of ghc for compiling jhc. I'd support field wildcards in 2011, but would understand if people thought it was too soon. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From simonpj at microsoft.com Thu Feb 25 03:33:47 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Feb 25 03:04:27 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 In-Reply-To: <4B858C89.9030507@isaac.cedarswampstudios.org> References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> <4B8572A5.4000305@van.steenbergen.nl> <4B858C89.9030507@isaac.cedarswampstudios.org> Message-ID: <59543203684B2244980D7E4057D5FBC10B08F953@DB3EX14MBXC312.europe.corp.microsoft.com> | >> we implicitly get | >> f :: T -> Int | >> which punning shadows with | >> f :: Int | >> whereas I generally avoid shadowing completely. | > | > I agree with Ian. | | I tend to agree. I originally had field puns in GHC, and then took them out when Haskell 98 removed them, after a discussion very like this one. I put them back in because some people really wanted them. Actually GHC has three separate extensions to do with named fields: field disambiguation (Section 7.3.14) field puns (Section 7.3.15) field wildcards (Section 7.3.16) Look here http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#disambiguate-fields Opinions differ. I'm rather with John: let the programmer choose, rather than enforcing a style in the language. For punning, the programmer can certainly choose on a case by case basis. If you use Haskell 98's existing syntax, there is no change to the semantics if you switch on field puns: data T = C { f :: Int } foo (C {f = x}) = ... -- No punning bar (C {f}) = ... -- Punning It would help this discussion if someone created a ticket to explain the actual proposal, so that we are all discussing the same thing. Simon From doug at cs.dartmouth.edu Thu Feb 25 09:54:04 2010 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu Feb 25 09:24:35 2010 Subject: showing Ratios Message-ID: <201002251454.o1PEs4lW024614@tecumseh.cs.dartmouth.edu> Very minor library change to promote readability of output: eliminate spaces in the string representation of Ratios. Currently, a Ratio appears as a pair separated by " % ". The spaces that flank "%" make for confusing output. Example: [1 % 2,1 % 3,1 % 4,1 % 5,1 % 6] The spaces suggest that "," binds more tightly than "%". I claim that [1%2,1%3,1%4,1%5,1%6] is much more readable. It also saves paper and/or screen area. I suspect that the spaces came in to make it easier to find the division point in a lugubrious Ratio like 123456789%987654321 True enough, but such numbers are too incomprehensible to get much scrutiny anyway. I, at least, find that all I do with Ratios much more complicated than 355%113 is squirrel them away in tables that only a computer is likely to read seriously, or edit them into some other form, e.g. for Sloane's Encyclopedia of Integer Sequences. Doug McIlroy From igloo at earth.li Thu Feb 25 10:07:46 2010 From: igloo at earth.li (Ian Lynagh) Date: Thu Feb 25 09:38:10 2010 Subject: showing Ratios In-Reply-To: <201002251454.o1PEs4lW024614@tecumseh.cs.dartmouth.edu> References: <201002251454.o1PEs4lW024614@tecumseh.cs.dartmouth.edu> Message-ID: <20100225150746.GA3554@matrix.chaos.earth.li> On Thu, Feb 25, 2010 at 09:54:04AM -0500, Doug McIlroy wrote: > Very minor library change to promote readability of output: > eliminate spaces in the string representation of Ratios. > > Currently, a Ratio appears as a pair separated by " % ". > The spaces that flank "%" make for confusing output. > Example: > > [1 % 2,1 % 3,1 % 4,1 % 5,1 % 6] > > The spaces suggest that "," binds more tightly than "%". > I claim that > > [1%2,1%3,1%4,1%5,1%6] See also: http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg14853.html http://hackage.haskell.org/trac/ghc/ticket/1920 A comment in the code says: -- H98 report has spaces round the % -- but we removed them [May 04] -- and added them again for consistency with -- Haskell 98 [Sep 08, #1920] Thanks Ian From nbowler at elliptictech.com Thu Feb 25 10:40:48 2010 From: nbowler at elliptictech.com (Nick Bowler) Date: Thu Feb 25 10:11:10 2010 Subject: RFC: Fixing floating point conversions. Message-ID: <20100225154048.GA19958@emergent.ellipticsemi.com> Currently, Haskell does not provide any mechanism for converting one floating type to another, since realToFrac appears to be fundamentally broken in this regard. For details on that matter, see the discussion at http://hackage.haskell.org/trac/ghc/ticket/3676. Essentially, realToFrac does not preserve floating values which are not representable as a Rational. I'd like to start discussing improvements to this situation by submitting some ideas which I have considered for comments. First though, two proposals: * Codify a requirement that Double values are a superset of Float values. C demands this, as it makes it possible to define Float to Double conversions as value-preserving. I couldn't find such a statement in the report; idea #1 below requires this. * Define toRational as throwing an exception on non-finite input. Infinities magically turning into integers is simply not nice. I personally feel that floating types should not be instances of the Real class, but that discussion can be saved for another day. *** Idea #0 *** Fix realToFrac. This seems to be impossible without highly undesirable consequences, see the trac ticket linked above for details. *** Idea #1 *** Add two methods to the RealFloat class: toDouble :: RealFloat a => a -> Double fromDouble :: RealFloat a => Double -> a and a function: toFloating :: (RealFloat a, RealFloat b) => a -> b toFloating = fromDouble . toDouble Advantages: * No extensions (other than this one) beyond Haskell 98 are required. * Simple to define instances, exactly two functions per floating type. * Trivial to implement. Disadvantages: * It encodes directly into the RealFloat class the knowledge that Double can represent values of any other floating type. This makes it difficult or impossible to create new floating types later. *** Idea #2 *** Similar to #1, except using a "generic" type instead of Double. Define a new type, call it FloatConvert, which represents "rational plus other values". Something along the lines of: data FloatConvert = FCZero Bool -- Signed zero | FCInfinity Bool -- Signed infinity | FCNaN Integer -- Generic NaN | FCFinite Rational -- Finite, non-zero value Add two new methods to the RealFloat class: toFloatConvert :: RealFloat a => a -> FloatConvert fromFloatConvert :: RealFloat a => FloatConvert -> a and a function: toFloating :: (RealFloat a, RealFloat b) => a -> b toFloating = fromFloatConvert . toFloatConvert Advantages: * No extensions (other than this one) beyond Haskell 98 are required. * Simple to define instances, exactly two functions per floating type. * Easy to add floating types to the language, and easy for users to define their own in libraries. Disadvantages: * A data type whose sole purpose is to convert floating types seems like a wart. * While the free-form encoding of NaN values will allow conversion from a type to itself to be the identity function, it may make it tricky to perform the "ideal" conversion between different types. *** Idea #3 *** Use a multi-parameter type class: class FloatConvert a b where toFloating :: a -> b Advantages: * Can define any conversion imaginable without constraints. * Straightforward to add floating types to the language. Disadvantages: * Requires multi-parameter type classes. * Not practical for library authors to define their own instances of this class except in special circumstances, since it requires knowledge of all other floating types. Of these three ideas, I think #2 (or something similar) is the most workable. What do others think? -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) From ganesh.sittampalam at credit-suisse.com Thu Feb 25 10:46:56 2010 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Feb 25 10:17:29 2010 Subject: Fixing floating point conversions. In-Reply-To: <20100225154048.GA19958@emergent.ellipticsemi.com> References: <20100225154048.GA19958@emergent.ellipticsemi.com> Message-ID: Nick Bowler wrote: > > *** Idea #3 *** > > Use a multi-parameter type class: We couldn't go down this route until MPTCs themselves are added to the language, which I think is unlikely to be soon as the whole fundeps/type families issue is still unresolved. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From Christian.Maeder at dfki.de Thu Feb 25 11:30:50 2010 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 25 11:01:13 2010 Subject: RFC: Fixing floating point conversions. In-Reply-To: <20100225154048.GA19958@emergent.ellipticsemi.com> References: <20100225154048.GA19958@emergent.ellipticsemi.com> Message-ID: <4B86A5BA.1040008@dfki.de> Nick Bowler schrieb: > *** Idea #2 *** > > Similar to #1, except using a "generic" type instead of Double. > > Define a new type, call it FloatConvert, which represents "rational plus > other values". Something along the lines of: > > data FloatConvert > = FCZero Bool -- Signed zero > | FCInfinity Bool -- Signed infinity > | FCNaN Integer -- Generic NaN > | FCFinite Rational -- Finite, non-zero value interesting. What is the Integer in FCNaN for? > Add two new methods to the RealFloat class: > > toFloatConvert :: RealFloat a => a -> FloatConvert > fromFloatConvert :: RealFloat a => FloatConvert -> a > > and a function: > > toFloating :: (RealFloat a, RealFloat b) => a -> b > toFloating = fromFloatConvert . toFloatConvert > > Advantages: > * No extensions (other than this one) beyond Haskell 98 are required. > * Simple to define instances, exactly two functions per floating type. > * Easy to add floating types to the language, and easy for users to > define their own in libraries. > > Disadvantages: > * A data type whose sole purpose is to convert floating types seems > like a wart. > * While the free-form encoding of NaN values will allow conversion > from a type to itself to be the identity function, it may make > it tricky to perform the "ideal" conversion between different > types. I don't understand this last point about "free-form encoding of NaN" I would come up with a data type like: data ExtNum a = NegativeZero | NaN | Infinity Bool | Num a add instances for the classes, Eq, Ord, Num, .... (depending on "a" that must be at least from the class Num for "0") and use "ExtNum Rational" for floating point conversions. Cheers Christian From nbowler at elliptictech.com Thu Feb 25 11:59:05 2010 From: nbowler at elliptictech.com (Nick Bowler) Date: Thu Feb 25 11:29:27 2010 Subject: RFC: Fixing floating point conversions. In-Reply-To: <4B86A5BA.1040008@dfki.de> References: <20100225154048.GA19958@emergent.ellipticsemi.com> <4B86A5BA.1040008@dfki.de> Message-ID: <20100225165905.GA20743@emergent.ellipticsemi.com> On 17:30 Thu 25 Feb , Christian Maeder wrote: > Nick Bowler schrieb: > > *** Idea #2 *** > > > > Similar to #1, except using a "generic" type instead of Double. > > > > Define a new type, call it FloatConvert, which represents "rational plus > > other values". Something along the lines of: > > > > data FloatConvert > > = FCZero Bool -- Signed zero > > | FCInfinity Bool -- Signed infinity > > | FCNaN Integer -- Generic NaN > > | FCFinite Rational -- Finite, non-zero value > > interesting. What is the Integer in FCNaN for? Many floating point formats have multiple NaNs. In the IEEE 754 binary formats, a NaN is specified by a maximum exponent and *any* non-zero significand. The extra bits are sometimes used for diagnostic information. There are signaling and quiet NaNs, and they have a sign bit. IEEE 754 recommends that operations involving NaNs preserve as much of this information as possible. I chose Integer since it can encode all of this information. It is desirable for conversions from a type to itself to be the identity function, even in the presence of multiple NaNs. I'm sure many other encodings are workable. > > * While the free-form encoding of NaN values will allow conversion > > from a type to itself to be the identity function, it may make > > it tricky to perform the "ideal" conversion between different > > types. > > I don't understand this last point about "free-form encoding of NaN" It's free-form in that, as I specified it, it's up to the particular RealFloat instance to decide how the Integer is used. This might make conversions which preserve, say, signaling NaNs trickier to implement. > I would come up with a data type like: > > data ExtNum a > = NegativeZero > | NaN > | Infinity Bool > | Num a > > add instances for the classes, Eq, Ord, Num, .... > (depending on "a" that must be at least from the class Num for "0") > > and use "ExtNum Rational" for floating point conversions. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) From john at repetae.net Thu Feb 25 17:23:59 2010 From: john at repetae.net (John Meacham) Date: Thu Feb 25 16:54:24 2010 Subject: RFC: Fixing floating point conversions. In-Reply-To: <20100225154048.GA19958@emergent.ellipticsemi.com> References: <20100225154048.GA19958@emergent.ellipticsemi.com> Message-ID: <20100225222359.GI9898@sliver.repetae.net> On Thu, Feb 25, 2010 at 10:40:48AM -0500, Nick Bowler wrote: > *** Idea #1 *** > > Add two methods to the RealFloat class: > > toDouble :: RealFloat a => a -> Double > fromDouble :: RealFloat a => Double -> a > > and a function: > > toFloating :: (RealFloat a, RealFloat b) => a -> b > toFloating = fromDouble . toDouble That is exactly how I solved it in the jhc libraries. Though, I may switch to using a 'FloatMax' type that is always aliased to the largest floating point type available, now that Float128 and Float80 are potentially available. (but it would just be an alias for Double for now) John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From anthony_clayden at clear.net.nz Thu Feb 25 20:55:58 2010 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Thu Feb 25 20:30:24 2010 Subject: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011 References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> <4B8572A5.4000305@van.steenbergen.nl> <4B858C89.9030507@isaac.cedarswampstudios.org> Message-ID: >Isaac Dupree writes: > On 02/24/10 13:40, Martijn van Steenbergen wrote: > > Ian Lynagh wrote: > >> I have a feeling I'm in the minority, but I find record punning an ugly > >> feature. > >> > >> Given > >> data T = C { f :: Int } > >> we implicitly get > >> f :: T -> Int > >> which punning shadows with > >> f :: Int > >> whereas I generally avoid shadowing completely. > > > > I agree with Ian. > > I tend to agree. > > > > -Isaac > (I know how you're always looking for things to take out of Haskell ...) I can see the ugliness of having a name with two incompatible types (especially in the same scope). I wonder: if a programmer from Mars landed into Haskell a la GHC 2010 (that is, unburdened by history back to v1.3), wouldn't it be the scare-quotes 'implicit' field selector that seems the odd man out? After all, the program text declares { f :: Int }, and in all uses of the field label apart from selecting, it _is_ an Int. Where does this function thing come from? By the way, it seems you can arrive at the same level of confusion like this (declared in a distinct scope): > f (C { f }) = f -- f :: T -> Int - Anthony From qdunkan at gmail.com Fri Feb 26 00:07:18 2010 From: qdunkan at gmail.com (Evan Laforge) Date: Thu Feb 25 23:37:49 2010 Subject: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011 In-Reply-To: References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> <4B8572A5.4000305@van.steenbergen.nl> <4B858C89.9030507@isaac.cedarswampstudios.org> Message-ID: <2518b95d1002252107s161a807bie3f46e1e717fc965@mail.gmail.com> > (I know how you're always looking for things to take out of > Haskell ...) > > I can see the ugliness of having a name with two > incompatible types (especially in the same scope). That's a good point, but even if not totally logical I think the automatic "Rec -> X" function is more important than the X meaning. Functions are more resistant to change (for instance, I changed from String to Data.Text but could keep the old recString as a function when the field named changed), so while I think the sugar to bring names into scope is handy, I think functional access should be encouraged as the "main" way to do it. The whole tension between syntactic convenience of pattern matching and the flexibility of function accessors in the face of change is kind of unfortunate. It mirrors the OO dilemma of x.y vs. x.y(), which some OO languages do away with altogether. So I'd want to go the other way by making functional access and update more convenient and prominent rather than syntactical. Maybe we could have a little extension of view patterns where "f (field ->) = y" is transformed to "f (field -> field) = y". It's still a shadow, but at least now it works with any function. It might be nice to do the same with update functions, but those aren't even generated automatically (anyone got a generics thing that cranks those out?). From apfelmus at quantentunnel.de Fri Feb 26 05:59:14 2010 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Fri Feb 26 05:30:07 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 In-Reply-To: <4B859122.2020100@gmail.com> References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> <4B859122.2020100@gmail.com> Message-ID: Simon Marlow wrote: > While I agree with these points, I was converted to record punning > (actually record wildcards) when I rewrote the GHC IO library. Handle > is a record with 12 or so fields, and there are literally dozens of > functions that start like this: > > flushWriteBuffer :: Handle -> IO () > flushWriteBuffer Handle{..} = do > > if I had to write out the field names I use each time, and even worse, > think up names to bind to each of them, it would be hideous. What about using field names as functions? flushWriteBuffer h@(Handle {}) = do ... buffer h ... Of course, you always have to drag h around. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From iavor.diatchki at gmail.com Fri Feb 26 14:06:02 2010 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri Feb 26 13:36:21 2010 Subject: PROPOSAL: Include record puns in Haskell 2011 In-Reply-To: References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> <4B859122.2020100@gmail.com> Message-ID: <5ab17e791002261106n6e176624oa7c90b03ae3ddbec@mail.gmail.com> Hello, In order to keep the discussion structured I have created two tickets in the haskell-prime trac system (http://hackage.haskell.org/trac/haskell-prime): * Proposal 1: Add pre-Haskell'98 style punning and record disambiguation (ticket #136) * Proposal 2: Add record-wildcards (ticket #137) I decided to split the two into separate tickets because, at least in my mind, there are different things that we might discuss about the two, and also they make sense independent of each other (although record wildcards without punning might be a bit weird :-). I think that both proposals are worth considering for Haskell 2011 because there are situations where they can significantly improve the readability of code involving record manipulation. I disagree with the stylistic issues that were brought up in the discussion because I do not believe that variable "shadowing" should be avoided at all costs: at least for me, avoiding shadowing is a means to an end rather then an end in itself. In the case of record puns, I think that the clarity of the notation far surpasses any confusion that might be introduced by the shadowing. Furthermore, as other participants in the discussion pointed out, the proposed features are orthogonal to the rest of the language, so their use is entirely optional. -Iavor On Fri, Feb 26, 2010 at 2:59 AM, Heinrich Apfelmus wrote: > Simon Marlow wrote: >> While I agree with these points, I was converted to record punning >> (actually record wildcards) when I rewrote the GHC IO library. ?Handle >> is a record with 12 or so fields, and there are literally dozens of >> functions that start like this: >> >> ? flushWriteBuffer :: Handle -> IO () >> ? flushWriteBuffer Handle{..} = do >> >> if I had to write out the field names I use each time, and even worse, >> think up names to bind to each of them, it would be hideous. > > What about using field names as functions? > > ? ?flushWriteBuffer h@(Handle {}) = do > ? ? ? ?... buffer h ... > > Of course, you always have to drag ?h ?around. > > > Regards, > Heinrich Apfelmus > > -- > http://apfelmus.nfshost.com > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From nbowler at elliptictech.com Fri Feb 26 17:37:04 2010 From: nbowler at elliptictech.com (Nick Bowler) Date: Fri Feb 26 17:07:22 2010 Subject: RFC: Fixing floating point conversions. In-Reply-To: <20100225222359.GI9898@sliver.repetae.net> References: <20100225154048.GA19958@emergent.ellipticsemi.com> <20100225222359.GI9898@sliver.repetae.net> Message-ID: <20100226223704.GA13366@emergent.ellipticsemi.com> On 14:23 Thu 25 Feb , John Meacham wrote: > On Thu, Feb 25, 2010 at 10:40:48AM -0500, Nick Bowler wrote: > > *** Idea #1 *** > > > > Add two methods to the RealFloat class: > > > > toDouble :: RealFloat a => a -> Double > > fromDouble :: RealFloat a => Double -> a > > > > and a function: > > > > toFloating :: (RealFloat a, RealFloat b) => a -> b > > toFloating = fromDouble . toDouble > > That is exactly how I solved it in the jhc libraries. > > Though, I may switch to using a 'FloatMax' type that is always aliased > to the largest floating point type available, now that Float128 and > Float80 are potentially available. (but it would just be an alias for > Double for now) Indeed, a type alias sounds like a good improvement to idea #1 for exactly the reasons that you mention. However, for an actual amendment to the standard, I'd like to see a solution which allows libraries to define their own instances of the numeric classes. Imagine that someone wants to create a library which implements decimal floating point arithmetic. With something like toDouble or toFloatMax, the author is faced with two major obstacles: * After creating new types, 'FloatMax' (which can't be redefined) might not be the "max" anymore. * When 'FloatMax' has a different radix, there is going to be loss of information when converting to it. For example, 1/5 is exactly representable in decimal floating point, but not in binary floating point with any finite number of significand digits. The end result is that 'toFloating' is not suitable for the decimal floating point library, so the author would have to invent her own conversion method. It is for this reason that I prefer something along the lines of idea #2 with a "generic" intermediate type. Nevertheless, #1 (with or without FloatMax) is still a /huge/ improvement over the status quo. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) From jon.fairbairn at cl.cam.ac.uk Sat Feb 27 05:52:53 2010 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sat Feb 27 05:23:29 2010 Subject: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011 References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> <4B8572A5.4000305@van.steenbergen.nl> <4B858C89.9030507@isaac.cedarswampstudios.org> Message-ID: Anthony Clayden writes: > (I know how you're always looking for things to take out of > Haskell ...) > > I can see the ugliness of having a name with two > incompatible types (especially in the same scope). Granted. > After all, the program text declares { f :: Int }, and in > all uses of the field label apart from selecting, it _is_ an Int. It's not; it's shorthand for something else (a bare f in a programme doesn't get you an Int -- which one would it be?). One of the nice things about Haskell is that if you know the name of something and the something has a type, then you know something about all the possible values it can have. In current Haskell, f here isn't a name in that sense, which is a big pity (you can't pass a field label as an argument to a function, for example). > Where does this function thing come from? It comes (as you imply) from it's use as a field selector. I'd say that (and field update) were its primary uses. It would be far better to make field labels proper first-class entities that have a translation into lambda calculus (or System F as you will). I would much rather see field labels having their own type, so that data F t = F {f:: H t} declares the type F, the constructor F and a name f:: Selector (F t) (H t) the language definition needn't make whatever is inside Selector directly visible to the programmer, but we can think of it as secretly being a pair of functions ((F t -> H t), (H t -> F t -> F t)) Now f x would be an overloaded meaning of application?. And r{f=g} would be shorthand for (magic-snd f g r), where magic-snd is just snd made suitable for application to Selector. (Frankly, I'd rather lose the r{f=g} syntax and provide an operator that accesses the second part of f so that it can be applied as a function, eg (f?g) r. This (f?g) would then also be a first class function.) Doing it this way would get rid of the peculiar multiple type issue, make it completely clear what field labels translate to and give us field labels as proper first class entities. [1] as it currently is, and I'm not suggesting allowing general overloading of application, but at least this way we'd know what f was -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From jon.fairbairn at cl.cam.ac.uk Sat Feb 27 05:54:00 2010 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sat Feb 27 05:25:22 2010 Subject: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011 References: <5ab17e791002231907y4acd8d89v40ee81e6e4e2e5a3@mail.gmail.com> <20100224182339.GA1120@matrix.chaos.earth.li> <4B8572A5.4000305@van.steenbergen.nl> <4B858C89.9030507@isaac.cedarswampstudios.org> <2518b95d1002252107s161a807bie3f46e1e717fc965@mail.gmail.com> Message-ID: Evan Laforge writes: > That's a good point, but even if not totally logical I think the > automatic "Rec -> X" function is more important than the X meaning. [...] > It might be nice to do the same with update functions, but those > aren't even generated automatically (anyone got a generics thing that > cranks those out?). See my other post for a way of doing both of these. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From qdunkan at gmail.com Sun Feb 28 22:03:44 2010 From: qdunkan at gmail.com (Evan Laforge) Date: Sun Feb 28 21:33:55 2010 Subject: showing Ratios In-Reply-To: <20100225150746.GA3554@matrix.chaos.earth.li> References: <201002251454.o1PEs4lW024614@tecumseh.cs.dartmouth.edu> <20100225150746.GA3554@matrix.chaos.earth.li> Message-ID: <2518b95d1002281903u664466dbmfd3ce6a46700cbe7@mail.gmail.com> This must be explained somewhere, but I can't find it.? I've always been curious why ghc's Show avoids all unnecessary spaces.? It's contrary to how most people format source so it can't be pasted into source, and can be hard to read. Other languages tend to put in spaces. I don't see anything in http://www.haskell.org/onlinereport/basic.html specifying the whitespace usage of Show. I notice that the examples don't use spaces, but those are just examples, right? What's the rationale? From iavor.diatchki at gmail.com Sun Feb 28 22:56:21 2010 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Feb 28 22:26:33 2010 Subject: showing Ratios In-Reply-To: <2518b95d1002281903u664466dbmfd3ce6a46700cbe7@mail.gmail.com> References: <201002251454.o1PEs4lW024614@tecumseh.cs.dartmouth.edu> <20100225150746.GA3554@matrix.chaos.earth.li> <2518b95d1002281903u664466dbmfd3ce6a46700cbe7@mail.gmail.com> Message-ID: <5ab17e791002281956h7505d3fehc1d51426283ea053@mail.gmail.com> Hi, I am not sure about the rationale but if you need a program/library which re-renders Show-able values with more spaces, so that they are more human readable, I wrote one (http://hackage.haskell.org/package/pretty-show). I find it very useful for debugging. -Iavor On Sun, Feb 28, 2010 at 7:03 PM, Evan Laforge wrote: > This must be explained somewhere, but I can't find it.? I've always > been curious why ghc's Show avoids all unnecessary spaces.? It's > contrary to how most people format source so it can't be pasted into > source, and can be hard to read. ?Other languages tend to put in > spaces. ?I don't see anything in > http://www.haskell.org/onlinereport/basic.html specifying the > whitespace usage of Show. ?I notice that the examples don't use > spaces, but those are just examples, right? > > What's the rationale? > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From qdunkan at gmail.com Sun Feb 28 23:03:41 2010 From: qdunkan at gmail.com (Evan Laforge) Date: Sun Feb 28 22:33:53 2010 Subject: showing Ratios In-Reply-To: <5ab17e791002281956h7505d3fehc1d51426283ea053@mail.gmail.com> References: <201002251454.o1PEs4lW024614@tecumseh.cs.dartmouth.edu> <20100225150746.GA3554@matrix.chaos.earth.li> <2518b95d1002281903u664466dbmfd3ce6a46700cbe7@mail.gmail.com> <5ab17e791002281956h7505d3fehc1d51426283ea053@mail.gmail.com> Message-ID: <2518b95d1002282003h53feb917ofb1ed652b1a793c4@mail.gmail.com> On Sun, Feb 28, 2010 at 7:56 PM, Iavor Diatchki wrote: > Hi, > I am not sure about the rationale but if you need a program/library > which re-renders Show-able values with more spaces, so that they are > more human readable, ?I wrote one > (http://hackage.haskell.org/package/pretty-show). ?I find it very > useful for debugging. Oh nice, I'll take a look. I'm currently using a hacked up version of ipprint which works pretty well. The only reason I had to hack it was to change the hardcoded 137 column line length to 80. And to output Strings directly, which is a hack needed for my specific application.