Negation
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
Re: Negation
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
On Mon, Feb 08, 2010 at 04:18:07PM +, 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
Re: Negation
On Mon, Feb 08, 2010 at 04:59:59PM +, 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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 +, 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 > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
On Mon, Feb 08, 2010 at 04:18:07PM +, 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/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Negation
| 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Negation
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 === ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
"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.fairba...@cl.cam.ac.uk ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
> | 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
Re: Negation
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
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 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
Re: Negation
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 > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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: a...@cs.uu.nl / |___\ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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.) ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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.) ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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
Re: Negation
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
Re: Negation
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 > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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
Re: Negation
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Negation
> 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Fixity was: Negation
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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Fixity was: Negation
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. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
