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 ganesh.sittampa...@credit-suisse.com 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
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, johndea...@cox.net 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 christian.mae...@dfki.de 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 doai...@cs.uu.nl 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 doai...@cs.uu.nl 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
