Re: [GHC] #4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions
#4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions ---+ Reporter: maeder| Owner: Type: bug | Status: new Priority: normal| Milestone: 7.2.1 Component: Compiler |Version: 7.2.1 Resolution:| Keywords: fixity resolution Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Comment(by simonpj): Could someone summarise exactly what the problem is here? It looks like a fiddly corner case so it would help to have a precise, standalone description of the problem. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4176#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions
#4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions ---+ Reporter: maeder| Owner: Type: bug | Status: new Priority: normal| Milestone: 7.2.1 Component: Compiler |Version: 7.2.1 Resolution:| Keywords: fixity resolution Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Comment(by maeder): When converting a pat or a funlhs into a sequence for the fixity resolution, prefix minus signs are currently wrongly ignored as more atomic lpats. If fixity resolution succeeds with these minus signs considered, then it should be checked if the argument of all minus signs is (still) a plain integer or float (as required by the grammar for lpat). The current parsing of patterns (with minus signs deeper in the trees) is rather unhelpful, though. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4176#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions
#4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions ---+ Reporter: maeder| Owner: Type: bug | Status: new Priority: normal| Milestone: 7.2.1 Component: Compiler |Version: 7.2.1 Resolution:| Keywords: fixity resolution Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Comment(by maeder): P.S. you need to be able to distinguish -1 from (-1) when constructing the sequence for fixity resolution (the latter case is really atomic). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4176#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions
#4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions ---+ Reporter: maeder| Owner: Type: bug | Status: new Priority: normal| Milestone: 7.2.1 Component: Compiler |Version: 7.2.1 Resolution:| Keywords: fixity resolution Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by maeder): * status: closed = new * version: 6.12.3 = 7.2.1 * resolution: wontfix = Comment: not the parser but fixity resolution (10.6) should reject this case. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4176#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions
#4176: reject unary minus in infix left hand side function bindings that resolve
differently as expressions
---+
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: normal| Milestone: 7.2.1
Component: Compiler |Version: 7.2.1
Resolution:| Keywords: fixity resolution
Testcase:| Blockedby:
Difficulty:| Os: Unknown/Multiple
Blocking:| Architecture: Unknown/Multiple
Failure: None/Unknown |
---+
Comment(by maeder):
I agree it requires extra code for patterns, but considering that a
missing fixity defaults to 9 (the highest) it would even make sense to
always require parens around - (integer | float) to the left of infix
ops. But I suppose there are not many patterns like:
{{{
-1 `op` ...
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4176#comment:7
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions
#4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions ---+ Reporter: maeder| Owner: Type: bug | Status: new Priority: normal| Milestone: 7.2.1 Component: Compiler |Version: 7.2.1 Resolution:| Keywords: fixity resolution Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Comment(by maeder): I just strikes me that `a + -1` is legal as pattern, but illegal as expression. (Apart from `_`, legal patterns should be a subset of legal expressions). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4176#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions
#4176: reject unary minus in infix left hand side function bindings that resolve
differently as expressions
---+
Reporter: maeder| Owner:
Type: bug | Status: closed
Priority: normal| Milestone: 7.2.1
Component: Compiler |Version: 6.12.3
Resolution: wontfix | Keywords: fixity resolution
Testcase:| Blockedby:
Difficulty:| Os: Unknown/Multiple
Blocking:| Architecture: Unknown/Multiple
Failure: None/Unknown |
---+
Changes (by igloo):
* status: new = closed
* resolution: = wontfix
Comment:
hugs September 2006 rejects this with:
{{{
ERROR b.hs:4 - Illegal pattern syntax
}}}
but as far as I can tell it is legal according to the Haskell 2010 report:
{{{
decl - (funlhs | var) rhs
funlhs - pat varop pat
pat - lpat
lpat - - (integer | float)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4176#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4180: do not consider associativity for unary minus for fixity resolution
#4180: do not consider associativity for unary minus for fixity resolution --+- Reporter: maeder |Owner: Type: feature request| Status: new Priority: normal |Milestone: 6.16.1 Component: Compiler (Parser) | Version: 6.12.3 Keywords: fixity resolution | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Changes (by igloo): * type: proposal = feature request * component: Compiler = Compiler (Parser) * milestone: = 6.16.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4180#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions
#4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions --+- Reporter: maeder |Owner: Type: bug| Status: new Priority: normal |Milestone: 6.14.1 Component: Compiler | Version: 6.12.3 Keywords: fixity resolution | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Changes (by igloo): * milestone: = 6.14.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4176#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4180: do not consider associativity for unary minus for fixity resolution
#4180: do not consider associativity for unary minus for fixity resolution --+- Reporter: maeder |Owner: Type: proposal | Status: new Priority: normal |Milestone: Component: Compiler | Version: 6.12.3 Keywords: fixity resolution | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Comment(by maeder): also see http://hackage.haskell.org/trac/haskell- prime/wiki/PrefixMinusResolution (as positive answer to b) The simple mental model is: prefix minus applications extend as far to the right as long as infix operators have higher precedence. (This happens in my recent Resolve.hs attachment by `resolveNegExpr`.) Therefore - 1 ## 1 should resolve as (- 1) ## 1, too. Both attached versions (Fixity.hs and Resolve.hs) resolve identically (and identically to Simon's version http://darcs.haskell.org/haskell- prime/fixity/resolve.hs, if guard (prec1 6) is omitted and the constructed precedence for unary minus is increased to 6.5 in parseNeg (Op - 6 Leftfix) rest, which also requires to change type Prec = Int to Float.) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4180#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4180: do not consider associativity for unary minus for fixity resolution
#4180: do not consider associativity for unary minus for fixity resolution --+- Reporter: maeder |Owner: Type: proposal | Status: new Priority: normal |Milestone: Component: Compiler | Version: 6.12.3 Keywords: fixity resolution | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Comment(by maeder): I've added a clearer resolution algorithm. I don't think the proposal is worth an extra language extension or compiler flag. I rather consider my proposal as a bug fix of the language description (that ghc conformed to), whereas various (all?) other compilers implemented resolution differently. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4180#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4180: do not consider associativity for unary minus for fixity resolution
#4180: do not consider associativity for unary minus for fixity resolution --+- Reporter: maeder |Owner: Type: proposal | Status: new Priority: normal |Milestone: Component: Compiler | Version: 6.12.3 Keywords: fixity resolution | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Comment(by maeder): I would rather propose a flag to get the old haskell98 resolution but make the default my proposed improvement. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4180#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4180: do not consider associativity for unary minus for fixity resolution
#4180: do not consider associativity for unary minus for fixity resolution --+- Reporter: maeder |Owner: Type: proposal | Status: new Priority: normal |Milestone: Component: Compiler | Version: 6.12.3 Keywords: fixity resolution | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Comment(by simonmar): If we made it the default then we would not be implementing Haskell 2010. That's ok, but we have to document very carefully the ways in which we diverge from the standard, which we do in the User's Guide: [http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/bugs-and- infelicities.html#vs-Haskell-defn]. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4180#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4180: do not consider associativity for unary minus for fixity resolution
#4180: do not consider associativity for unary minus for fixity resolution --+- Reporter: maeder |Owner: Type: proposal | Status: new Priority: normal |Milestone: Component: Compiler | Version: 6.12.3 Keywords: fixity resolution | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Comment(by maeder): I've proposed the improvement for Haskell 2010 (however final the description may be). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4180#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4180: do not consider associativity for unary minus for fixity resolution
#4180: do not consider associativity for unary minus for fixity resolution --+- Reporter: maeder |Owner: Type: proposal | Status: new Priority: normal |Milestone: Component: Compiler | Version: 6.12.3 Keywords: fixity resolution | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Comment(by simonmar): Once the Haskell prime proposal reaches some stability we should implement it as a GHC extension. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4180#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4180: do not consider associativity for unary minus for fixity resolution
#4180: do not consider associativity for unary minus for fixity resolution -+-- Reporter: maeder| Owner: Type: proposal | Status: new Priority: normal| Component: Compiler Version: 6.12.3|Keywords: fixity resolution Os: Unknown/Multiple |Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by maeder): see http://www.haskell.org/pipermail/haskell-prime/2010-July/003229.html for more explanations -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4180#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #4180: do not consider associativity for unary minus for fixity resolution
#4180: do not consider associativity for unary minus for fixity resolution -+-- Reporter: maeder| Owner: Type: proposal | Status: new Priority: normal| Component: Compiler Version: 6.12.3|Keywords: fixity resolution Os: Unknown/Multiple |Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- 1. currently an expression 1 + - 1 is rejected, because 1 + (-1) looks as being bracketed to the right, whereas + and - are left associative. However, no other bracketing is possible, so 1 + - 1 is unambiguous and should not be subject to further fixity resolution. 2. if an infix expressions starts with an unary minus, the associativity should not matter for the unary minus. Why should - 1 ## 1 be rejected for a right- or non-assoc operator ##? Precedence alone is sufficient to decide between (- 1) ## 1 and - (1 ## 1). The latter choice is taken for a higher precedence of the infix operator and the former choice should always be taken for an equal or lower precedence as is done for - 1 + 1, but without looking at associativity! I'll attach an alternative fixity resolution in the spirit of 10.6 of http://www.haskell.org/~simonmar/haskell-2010-draft- report-2/haskellch10.html -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4180 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions
#4176: reject unary minus in infix left hand side function bindings that resolve
differently as expressions
-+--
Reporter: maeder| Owner:
Type: proposal | Status: new
Priority: normal| Component: Compiler
Version: 6.12.3|Keywords: fixity resolution
Os: Unknown/Multiple |Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
a program like:
{{{
infix 7 ##
(##) :: Int - Int - Int
- 1 ## 0 = 0
_ ## _ = 1
}}}
evaluates (unexpectedly) as
{{{
*Main - 1 ## 0
-1
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4176
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions
#4176: reject unary minus in infix left hand side function bindings that resolve differently as expressions -+-- Reporter: maeder| Owner: Type: bug | Status: new Priority: normal| Component: Compiler Version: 6.12.3|Keywords: fixity resolution Os: Unknown/Multiple |Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by maeder): * type: proposal = bug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4176#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell-cafe] Unary Minus
If I use :info (-) I get information on the binary minus. Is unary minus also a function? Thanks, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unary Minus
If I use :info (-) I get information on the binary minus. Is unary minus also a function? You can define it yourself or use negate from the Prelude. Wouter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unary Minus
Paul Keir wrote: If I use :info (-) I get information on the binary minus. Is unary minus also a function? No, as far as I know the unary minus is part of the number literals. You can use negate if you want it as a function. Hope this helps, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Unary Minus
On Mon, 6 Apr 2009 12:13:09 +0200, Roel van Dijk vandijk.r...@gmail.com wrote: On Mon, Apr 6, 2009 at 12:04 PM, Benjamin L.Russell dekudekup...@yahoo.com wrote: Interesting. ?How is this hack implemented? This seems to be the relevant grammar: lexp6 - - exp7 lpat6 - - (integer | float)(negative literal) The '6's and the '7' are superscripts. Perhaps the hack is in the precedence of the expression in which an unary minus is allowed. Yes, I see it now. It's under 9.5 Context-Free Syntax, instead of being under 9.2 Lexical Syntax, so it's a syntactic rule, rather than a lexical rule. According to the rule, a left-expression of precedence level 6 consists of '-' followed by an expression of precedence level 7, and a left-pattern of precedence level 6 consists of '-' followed by (an integer or a float), and by definition, this is a negative literal. Integers and floats, in turn, are part of the lexical syntax. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Unary Minus
On Mon, 6 Apr 2009 12:13:09 +0200, Roel van Dijk vandijk.r...@gmail.com wrote: On Mon, Apr 6, 2009 at 12:04 PM, Benjamin L.Russell dekudekup...@yahoo.com wrote: Interesting. ?How is this hack implemented? This seems to be the relevant grammar: lexp6 - - exp7 lpat6 - - (integer | float)(negative literal) The '6's and the '7' are superscripts. Perhaps the hack is in the precedence of the expression in which an unary minus is allowed. What's interesting are the following definitions of the functions '-' (binary minus) and negate given in 8 Standard Prelude (see http://www.haskell.org/onlinereport/standard-prelude.html#$tNum): class (Eq a, Show a) = Num a where (+), (-), (*):: a - a - a negate :: a - a abs, signum :: a - a fromInteger :: Integer - a -- Minimal complete definition: -- All, except negate or (-) x - y= x + negate y negate x = 0 - x The type of negate, a - a, where a is a Num, is precisely what is needed for a unary minus. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unary Minus
Unary minus is a hack in the syntax for allowing the function negate to be written as prefix -. On Mon, Apr 6, 2009 at 10:36 AM, Martijn van Steenbergen mart...@van.steenbergen.nl wrote: Paul Keir wrote: If I use :info (-) I get information on the binary minus. Is unary minus also a function? No, as far as I know the unary minus is part of the number literals. You can use negate if you want it as a function. Hope this helps, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unary Minus
On Mon, Apr 6, 2009 at 12:04 PM, Benjamin L.Russell dekudekup...@yahoo.com wrote: Interesting. How is this hack implemented? This seems to be the relevant grammar: lexp6 - - exp7 lpat6 - - (integer | float)(negative literal) The '6's and the '7' are superscripts. Perhaps the hack is in the precedence of the expression in which an unary minus is allowed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Unary Minus
Interesting. How is this hack implemented? I just checked the BNF grammar for the lexical syntax of Haskell in The Haskell 98 Language Report (see the BNF grammer given under 9.2 Lexical Syntax under 9 Syntax Reference at http://www.haskell.org/onlinereport/syntax-iso.html), but had difficulty in deriving a unary minus. Could somebody please enlighten me on how to derive the expression -1 (a unary minus followed the the ascDigit 1) from the above-mentioned BNF grammar? Or is a unary minus not part of this grammar? -- Benjamin L. Russell On Mon, 6 Apr 2009 11:14:52 +0200, Lennart Augustsson lenn...@augustsson.net wrote: Unary minus is a hack in the syntax for allowing the function negate to be written as prefix -. On Mon, Apr 6, 2009 at 10:36 AM, Martijn van Steenbergen mart...@van.steenbergen.nl wrote: Paul Keir wrote: If I use :info (-) I get information on the binary minus. Is unary minus also a function? No, as far as I know the unary minus is part of the number literals. You can use negate if you want it as a function. Hope this helps, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Wanted: warning option for usages of unary minus
John Meacham wrote: On Mon, May 14, 2007 at 10:19:07AM +0100, Simon Marlow wrote: Really? I'm beginning to have second thoughts about the proposed change to negation for Haskell'. The main reason, and this isn't pointed out as well as it should be on the wiki, is that x-1 will cease to be an infix application of (-), it will parse as x applied to the literal (-1). And this is different from x - 1 (syntax in which whitespace matters should be avoided like the plague, IMO). I think this would be worse than the current situation. White space already matters when it comes to numbers quite a bit 0 x 123 vs 0x123 1.5 vs 1 . 5 3e4 vs 3 e 4 etc. Yes, I happen to think that whitespcae should only be significant where it separates two lexemes of the same category. I'm prepared to make an exception for numbers, because the syntax of numbers is already so familiar to almost everyone. I think that we could easily remove the '3e4' lexical syntax though, since '3*10^^4' works just as well (I often write the latter anyway) (and guess what, I just had to look up the difference between ^ and ^^, only to discover I picked the wrong one). The '3e4' syntax is a common source of compiler bugs, becuase it is rarely used and hence rarely tested. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
On Mon, May 21, 2007 at 10:33:56AM +0100, Simon Marlow wrote: I think that we could easily remove the '3e4' lexical syntax though, since '3*10^^4' works just as well (I often write the latter anyway) (and guess what, I just had to look up the difference between ^ and ^^, only to discover I picked the wrong one). The '3e4' syntax is a common source of compiler bugs, becuase it is rarely used and hence rarely tested. but they have substantially different translations. 3e2 - fromRational (300 % 1) 3*10^^2 - (fromInteger 3) * (fromInteger 10) ^^ (2 :: Foo) where Foo is whatever 4 defaults to, probably Integer, but could be a compile error if defaulting is off or changed. Though, the current floating point support in haskell is pretty funky as is... John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
On Mon, May 21, 2007 at 10:33:56AM +0100, Simon Marlow wrote: I think that we could easily remove the '3e4' lexical syntax though, since '3*10^^4' works just as well (I often write the latter anyway) (and guess what, I just had to look up the difference between ^ and ^^, only to discover I picked the wrong one). The '3e4' syntax is a common source of compiler bugs, becuase it is rarely used and hence rarely tested. but they have substantially different translations. 3e2 - fromRational (300 % 1) 3*10^^2 - (fromInteger 3) * (fromInteger 10) ^^ (2 :: Foo) where Foo is whatever 4 defaults to, probably Integer, but could be a compile error if defaulting is off or changed. Though, the current floating point support in haskell is pretty funky as is... John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Meacham wrote: another option would be to only count it as a negative if there is a non-identifier character preceeding it. A little ugly. but still better than the current situation IMHO. I think Ghc's lexer Alex can do this although this functionality is not used anywhere else... it seems a little out of character. I don't really like that (3-2)-1 would be parsed differently because it's a parenthesized expression; consider 3^2-1 vs. (3^2)-1 ... Isaac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTwMCHgcxvIWYTTURAkzHAKCdekuA6rUw4QcnIV3Qq9WJ8ZkljQCfTH5G c0jDDrAGLtBVZ4WVRdTDJu8= =1BDf -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Meacham wrote: another option would be to only count it as a negative if there is a non-identifier character preceeding it. A little ugly. but still better than the current situation IMHO. I think Ghc's lexer Alex can do this although this functionality is not used anywhere else... it seems a little out of character. I don't really like that (3-2)-1 would be parsed differently because it's a parenthesized expression; consider 3^2-1 vs. (3^2)-1 ... Isaac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTwMCHgcxvIWYTTURAkzHAKCdekuA6rUw4QcnIV3Qq9WJ8ZkljQCfTH5G c0jDDrAGLtBVZ4WVRdTDJu8= =1BDf -END PGP SIGNATURE- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Wanted: warning option for usages of unary minus
On Mon, May 14, 2007 at 10:19:07AM +0100, Simon Marlow wrote: Really? I'm beginning to have second thoughts about the proposed change to negation for Haskell'. The main reason, and this isn't pointed out as well as it should be on the wiki, is that x-1 will cease to be an infix application of (-), it will parse as x applied to the literal (-1). And this is different from x - 1 (syntax in which whitespace matters should be avoided like the plague, IMO). I think this would be worse than the current situation. White space already matters when it comes to numbers quite a bit 0 x 123 vs 0x123 1.5 vs 1 . 5 3e4 vs 3 e 4 etc. I think this change is more than worth it. I mean, having to write (-4) everywhere is bad enough, but when writing polymorphic code, (fromInteger (-4)) is horrific to embed everywhere. :) another option would be to only count it as a negative if there is a non-identifier character preceeding it. A little ugly. but still better than the current situation IMHO. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
On Thu, May 17, 2007 at 06:40:04PM +0200, Twan van Laarhoven wrote:
Simon Marlow wrote:
...
Really? I'm beginning to have second thoughts about the proposed change
to negation for Haskell'. The main reason, and this isn't pointed out
as well as it should be on the wiki, is that x-1 will cease to be an
infix application of (-), it will parse as x applied to the literal
(-1). And this is different from x - 1
There is one other alternative for parsing:
- is a unary minus if and only if it is
a) preceded by whitespace or one of [({;,, and
b) not followed by whitespace.
So:
x - 1 ==(-) x 1
x-1 ==(-) x 1
x -1 ==x (negate 1)
x -(1)==x (negate 1)
x (-1)==x (negate 1)
x (- 1) ==x (\y - y - 1)
also
(c) has a digit after it.
also note that a big point of this is that we can get rid of 'negate' in
the translation, so the literal
-1 now desugars to
(fromInteger -1)
rather than the current
(negate (fromInteger 1))
(which requires 2 dictionary lookups for a simple constant! sigh.
we also have the option of removing negate from the 'Num' class if so
desired.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Taral wrote: On 5/17/07, Joseph H. Fasel [EMAIL PROTECTED] wrote: *Sigh* The problems with unary minus were discussed in the dim mists of time before we published the first Haskell report. We considered then using a separate symbol for unary negation (as does APL, for example), but (IIRC) this was regarded as unfriendly to Fortran programmers. [breaking cc list] Would this kind of thing be eligible for Haskell'? I never had a problem with _1 in APL-type languages... and I think it's best to be very clear about intent. Haskell' is supposed to be a conservative standard describing mostly-already-implemented features. (of course that is why to implement features like this efficiently if there is a good reason for them) underscore seems like a bad candidate in haskell because: _1 is presently a lowercase haskell identifier some people want mid-number underscores 1_048_576 ... Isaac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTXVBHgcxvIWYTTURAv+HAJ4mCqpXLLUEHaYeHrw8l6lx3eBr4QCgnTNl +g5Rllpuk/8s6p+1hTxi4Ew= =IvPt -END PGP SIGNATURE- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Iavor Diatchki wrote:
Hello,
I agree with Simon on this one: x-1 should parse as expected (i.e.,
the infix operator - applied to two arguments x and 1). Having
this result in a type error would be confusing to both beginners and
working Haskell programmers.
I think that if we want to change anything at all, we should simply
eliminate the unary negation operator without changing the lexer
(i.e., we would have only positive literals). Then we would have to
be explicit about what is currently happening implicitly in
Haskell98---we would write negate 1 instead of -1.
However, I don't thinks that this change is justified---as far as I
can see, the only benefit is that it simplifies the parser. However,
the change is not backward compatible and may break some programs.
Simplifies the _mental_ parser, much more important than the compilers'
parsers which are already implemented.
Here is what I am thinking to do:
In my own code, since there seems to be so much difficulty with the
matter, don't use (-X) to mean negative for any kind of X whatsoever.
For this I want a warning for ALL usages of the unary minus operator.
I'll define a function for my negative literals that calls fromInteger
and negate in the order I would prefer to my sensibilities, which is
actually different from the order that the Report specifies for (-x) :
{-# INLINE negative #-}
negative :: Num a = Integer - a
negative a = fromInteger (negate a)
I might feel like having a parallel
{-# INLINE positive #-}
positive :: Num a = Integer - a
positive a = fromInteger a
(e.g. C has a unary + operator... and positive even has the same
number-of-characters length as negative!).
For GHC's unboxed negative literals I think I will still change the
lexer/parser since the current way it's done is rather confusing anyway
(as previously described)
I don't know what else is worth implementing... NOT an option to turn
off parsing of unary minus, since warnings are good and it would just
create more incompatibility. John Meacham, since you seem to be
interested, what are your thoughts now? Advice on flag names - or any
other discussion! is anyone interested in having something, say so? -
would be appreciated.
Isaac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGTDBQHgcxvIWYTTURAt14AJ9+Avd3FJ54+f0eNzUBFM7tOPy5TgCfRys8
usEFDx9uNH2UjUHBbG9kyGs=
=M3CU
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wrote: negative :: Num a = Integer - a negative a = fromInteger (negate a) Oops, I forgot Rational literals, they make things a little more complicated :( Isaac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTJKxHgcxvIWYTTURAtGMAJ9oetioh1rfTF1o+bqCWqWxG/LSiwCgghq9 pOBHdfUp625ll1lpTbW0X+w= =X0oP -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Twan van Laarhoven wrote:
There is one other alternative for parsing:
- is a unary minus if and only if it is
a) preceded by whitespace or one of [({;,, and
b) not followed by whitespace.
So:
x - 1 ==(-) x 1
x-1 ==(-) x 1
x -1 ==x (negate 1)
x -(1)==x (negate 1)
x (-1)==x (negate 1)
x (- 1) ==x (\y - y - 1)
Just an idea.
Indeed, and in some language syntax designs it would certainly be a good
system for prefix operators.
Existing parsers may have some difficulty. How about
{-comment-}-1
?
how about
WeirdNumber{value=2,weird=True}-1
?
Although likely to make any actual code work, it seems a bit complicated
from the mindset of current Haskell parsing/lexing.
(b) not followed by whitespace. can be replaced by
(b) followed by a digit
if desired not to allow it for negating arbitrary expressions.
Isaac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGTJRgHgcxvIWYTTURAqpMAJ9rpCFwzOG/ZSF0qpM/hD/mFKrQ1wCfSRCK
2nKiBzRs/8thmgrdBT+SowA=
=lFCl
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Iavor Diatchki wrote:
Hello,
I agree with Simon on this one: x-1 should parse as expected (i.e.,
the infix operator - applied to two arguments x and 1). Having
this result in a type error would be confusing to both beginners and
working Haskell programmers.
I think that if we want to change anything at all, we should simply
eliminate the unary negation operator without changing the lexer
(i.e., we would have only positive literals). Then we would have to
be explicit about what is currently happening implicitly in
Haskell98---we would write negate 1 instead of -1.
However, I don't thinks that this change is justified---as far as I
can see, the only benefit is that it simplifies the parser. However,
the change is not backward compatible and may break some programs.
Simplifies the _mental_ parser, much more important than the compilers'
parsers which are already implemented.
Here is what I am thinking to do:
In my own code, since there seems to be so much difficulty with the
matter, don't use (-X) to mean negative for any kind of X whatsoever.
For this I want a warning for ALL usages of the unary minus operator.
I'll define a function for my negative literals that calls fromInteger
and negate in the order I would prefer to my sensibilities, which is
actually different from the order that the Report specifies for (-x) :
{-# INLINE negative #-}
negative :: Num a = Integer - a
negative a = fromInteger (negate a)
I might feel like having a parallel
{-# INLINE positive #-}
positive :: Num a = Integer - a
positive a = fromInteger a
(e.g. C has a unary + operator... and positive even has the same
number-of-characters length as negative!).
For GHC's unboxed negative literals I think I will still change the
lexer/parser since the current way it's done is rather confusing anyway
(as previously described)
I don't know what else is worth implementing... NOT an option to turn
off parsing of unary minus, since warnings are good and it would just
create more incompatibility. John Meacham, since you seem to be
interested, what are your thoughts now? Advice on flag names - or any
other discussion! is anyone interested in having something, say so? -
would be appreciated.
Isaac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGTDBQHgcxvIWYTTURAt14AJ9+Avd3FJ54+f0eNzUBFM7tOPy5TgCfRys8
usEFDx9uNH2UjUHBbG9kyGs=
=M3CU
-END PGP SIGNATURE-
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Wanted: warning option for usages of unary minus
*Sigh* The problems with unary minus were discussed in the dim mists of
time before we published the first Haskell report. We considered then
using a separate symbol for unary negation (as does APL, for example),
but (IIRC) this was regarded as unfriendly to Fortran programmers.
Cheers,
--Joe
On Thu, 2007-05-17 at 04:37, Isaac Dupree wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Iavor Diatchki wrote:
Hello,
I agree with Simon on this one: x-1 should parse as expected (i.e.,
the infix operator - applied to two arguments x and 1). Having
this result in a type error would be confusing to both beginners and
working Haskell programmers.
I think that if we want to change anything at all, we should simply
eliminate the unary negation operator without changing the lexer
(i.e., we would have only positive literals). Then we would have to
be explicit about what is currently happening implicitly in
Haskell98---we would write negate 1 instead of -1.
However, I don't thinks that this change is justified---as far as I
can see, the only benefit is that it simplifies the parser. However,
the change is not backward compatible and may break some programs.
Simplifies the _mental_ parser, much more important than the compilers'
parsers which are already implemented.
Here is what I am thinking to do:
In my own code, since there seems to be so much difficulty with the
matter, don't use (-X) to mean negative for any kind of X whatsoever.
For this I want a warning for ALL usages of the unary minus operator.
I'll define a function for my negative literals that calls fromInteger
and negate in the order I would prefer to my sensibilities, which is
actually different from the order that the Report specifies for (-x) :
{-# INLINE negative #-}
negative :: Num a = Integer - a
negative a = fromInteger (negate a)
I might feel like having a parallel
{-# INLINE positive #-}
positive :: Num a = Integer - a
positive a = fromInteger a
(e.g. C has a unary + operator... and positive even has the same
number-of-characters length as negative!).
For GHC's unboxed negative literals I think I will still change the
lexer/parser since the current way it's done is rather confusing anyway
(as previously described)
I don't know what else is worth implementing... NOT an option to turn
off parsing of unary minus, since warnings are good and it would just
create more incompatibility. John Meacham, since you seem to be
interested, what are your thoughts now? Advice on flag names - or any
other discussion! is anyone interested in having something, say so? -
would be appreciated.
Isaac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGTDBQHgcxvIWYTTURAt14AJ9+Avd3FJ54+f0eNzUBFM7tOPy5TgCfRys8
usEFDx9uNH2UjUHBbG9kyGs=
=M3CU
-END PGP SIGNATURE-
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
--
Joseph H. Fasel, Ph.D.
Process Modeling and Analysis
AET-2, MS F609
Los Alamos National Laboratory
Los Alamos, NM 87545
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Wanted: warning option for usages of unary minus
Simon Marlow wrote:
...
Really? I'm beginning to have second thoughts about the proposed change
to negation for Haskell'. The main reason, and this isn't pointed out
as well as it should be on the wiki, is that x-1 will cease to be an
infix application of (-), it will parse as x applied to the literal
(-1). And this is different from x - 1
There is one other alternative for parsing:
- is a unary minus if and only if it is
a) preceded by whitespace or one of [({;,, and
b) not followed by whitespace.
So:
x - 1 ==(-) x 1
x-1 ==(-) x 1
x -1 ==x (negate 1)
x -(1)==x (negate 1)
x (-1)==x (negate 1)
x (- 1) ==x (\y - y - 1)
Just an idea.
Twan
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Twan van Laarhoven wrote:
There is one other alternative for parsing:
- is a unary minus if and only if it is
a) preceded by whitespace or one of [({;,, and
b) not followed by whitespace.
So:
x - 1 ==(-) x 1
x-1 ==(-) x 1
x -1 ==x (negate 1)
x -(1)==x (negate 1)
x (-1)==x (negate 1)
x (- 1) ==x (\y - y - 1)
Just an idea.
Indeed, and in some language syntax designs it would certainly be a good
system for prefix operators.
Existing parsers may have some difficulty. How about
{-comment-}-1
?
how about
WeirdNumber{value=2,weird=True}-1
?
Although likely to make any actual code work, it seems a bit complicated
from the mindset of current Haskell parsing/lexing.
(b) not followed by whitespace. can be replaced by
(b) followed by a digit
if desired not to allow it for negating arbitrary expressions.
Isaac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGTJRgHgcxvIWYTTURAqpMAJ9rpCFwzOG/ZSF0qpM/hD/mFKrQ1wCfSRCK
2nKiBzRs/8thmgrdBT+SowA=
=lFCl
-END PGP SIGNATURE-
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Wanted: warning option for usages of unary minus
On 5/17/07, Joseph H. Fasel [EMAIL PROTECTED] wrote: *Sigh* The problems with unary minus were discussed in the dim mists of time before we published the first Haskell report. We considered then using a separate symbol for unary negation (as does APL, for example), but (IIRC) this was regarded as unfriendly to Fortran programmers. [breaking cc list] Would this kind of thing be eligible for Haskell'? I never had a problem with _1 in APL-type languages... and I think it's best to be very clear about intent. -- Taral [EMAIL PROTECTED] Please let me know if there's any further trouble I can give you. -- Unknown ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Wanted: warning option for usages of unary minus
John Meacham wrote: On Wed, Apr 11, 2007 at 09:05:21AM +0100, Simon Marlow wrote: I definitely think that -1# should be parsed as a single lexeme. Presumably it was easier at the time to do it the way it is, I don't remember exactly. I'd support a warning for use of prefix negation, or alternatively you could implement the Haskell' proposal to remove prefix negation completely - treat the unary minus as part of a numeric literal in the lexer only. This would have to be optional for now, so that we can continue to support Haskell 98 of course. yes please! odd that I look forward to such a minor change in the big scheme of things, but the current treatment of negation has annoyed me more than any other misfeature I think. Really? I'm beginning to have second thoughts about the proposed change to negation for Haskell'. The main reason, and this isn't pointed out as well as it should be on the wiki, is that x-1 will cease to be an infix application of (-), it will parse as x applied to the literal (-1). And this is different from x - 1 (syntax in which whitespace matters should be avoided like the plague, IMO). I think this would be worse than the current situation. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
Hello, I agree with Simon on this one: x-1 should parse as expected (i.e., the infix operator - applied to two arguments x and 1). Having this result in a type error would be confusing to both beginners and working Haskell programmers. I think that if we want to change anything at all, we should simply eliminate the unary negation operator without changing the lexer (i.e., we would have only positive literals). Then we would have to be explicit about what is currently happening implicitly in Haskell98---we would write negate 1 instead of -1. However, I don't thinks that this change is justified---as far as I can see, the only benefit is that it simplifies the parser. However, the change is not backward compatible and may break some programs. -Iavor On 5/14/07, Simon Marlow [EMAIL PROTECTED] wrote: John Meacham wrote: On Wed, Apr 11, 2007 at 09:05:21AM +0100, Simon Marlow wrote: I definitely think that -1# should be parsed as a single lexeme. Presumably it was easier at the time to do it the way it is, I don't remember exactly. I'd support a warning for use of prefix negation, or alternatively you could implement the Haskell' proposal to remove prefix negation completely - treat the unary minus as part of a numeric literal in the lexer only. This would have to be optional for now, so that we can continue to support Haskell 98 of course. yes please! odd that I look forward to such a minor change in the big scheme of things, but the current treatment of negation has annoyed me more than any other misfeature I think. Really? I'm beginning to have second thoughts about the proposed change to negation for Haskell'. The main reason, and this isn't pointed out as well as it should be on the wiki, is that x-1 will cease to be an infix application of (-), it will parse as x applied to the literal (-1). And this is different from x - 1 (syntax in which whitespace matters should be avoided like the plague, IMO). I think this would be worse than the current situation. Cheers, Simon ___ Haskell-prime mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-prime ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
John Meacham wrote: On Wed, Apr 11, 2007 at 09:05:21AM +0100, Simon Marlow wrote: I definitely think that -1# should be parsed as a single lexeme. Presumably it was easier at the time to do it the way it is, I don't remember exactly. I'd support a warning for use of prefix negation, or alternatively you could implement the Haskell' proposal to remove prefix negation completely - treat the unary minus as part of a numeric literal in the lexer only. This would have to be optional for now, so that we can continue to support Haskell 98 of course. yes please! odd that I look forward to such a minor change in the big scheme of things, but the current treatment of negation has annoyed me more than any other misfeature I think. Really? I'm beginning to have second thoughts about the proposed change to negation for Haskell'. The main reason, and this isn't pointed out as well as it should be on the wiki, is that x-1 will cease to be an infix application of (-), it will parse as x applied to the literal (-1). And this is different from x - 1 (syntax in which whitespace matters should be avoided like the plague, IMO). I think this would be worse than the current situation. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Wanted: warning option for usages of unary minus
Hello, I agree with Simon on this one: x-1 should parse as expected (i.e., the infix operator - applied to two arguments x and 1). Having this result in a type error would be confusing to both beginners and working Haskell programmers. I think that if we want to change anything at all, we should simply eliminate the unary negation operator without changing the lexer (i.e., we would have only positive literals). Then we would have to be explicit about what is currently happening implicitly in Haskell98---we would write negate 1 instead of -1. However, I don't thinks that this change is justified---as far as I can see, the only benefit is that it simplifies the parser. However, the change is not backward compatible and may break some programs. -Iavor On 5/14/07, Simon Marlow [EMAIL PROTECTED] wrote: John Meacham wrote: On Wed, Apr 11, 2007 at 09:05:21AM +0100, Simon Marlow wrote: I definitely think that -1# should be parsed as a single lexeme. Presumably it was easier at the time to do it the way it is, I don't remember exactly. I'd support a warning for use of prefix negation, or alternatively you could implement the Haskell' proposal to remove prefix negation completely - treat the unary minus as part of a numeric literal in the lexer only. This would have to be optional for now, so that we can continue to support Haskell 98 of course. yes please! odd that I look forward to such a minor change in the big scheme of things, but the current treatment of negation has annoyed me more than any other misfeature I think. Really? I'm beginning to have second thoughts about the proposed change to negation for Haskell'. The main reason, and this isn't pointed out as well as it should be on the wiki, is that x-1 will cease to be an infix application of (-), it will parse as x applied to the literal (-1). And this is different from x - 1 (syntax in which whitespace matters should be avoided like the plague, IMO). I think this would be worse than the current situation. 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: Wanted: warning option for usages of unary minus
On Wed, Apr 11, 2007 at 09:05:21AM +0100, Simon Marlow wrote: I definitely think that -1# should be parsed as a single lexeme. Presumably it was easier at the time to do it the way it is, I don't remember exactly. I'd support a warning for use of prefix negation, or alternatively you could implement the Haskell' proposal to remove prefix negation completely - treat the unary minus as part of a numeric literal in the lexer only. This would have to be optional for now, so that we can continue to support Haskell 98 of course. yes please! odd that I look forward to such a minor change in the big scheme of things, but the current treatment of negation has annoyed me more than any other misfeature I think. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
Okay, first steps:
1. A Trac ticket (#1318,
http://hackage.haskell.org/trac/ghc/ticket/1318) (is feature request a
good category, versus task?)
2. A test-case to make sure I don't break anything with existing '-'
syntax. I'm guessing it should go in
testsuite/tests/ghc-regress/parser/should_run/, although maybe since it
checks Haskell-98 compatibility it should go in the testsuite/tests/h98
directory? (tested ghc and hugs, which both pass)
Isaac
(test-case attached in case anyone wants to look at or review it; I'll
send a darcs patch adding the testcase once I know where to put it)
-- !!! Haskell-98 prefix negate operator
-- Make sure the parsing is actually the correct
-- one by running this after it's compiled.
negatedExpression = - (3 + 4)
negatedTightlyBinding = -3^4
negatedNonSection = (- 3)
negatedNonSectionWithHighPrecedenceOp =
let { f = (+); infix 9 `f` } in ( -3 `f` 4 )
negatedNonSectionWithLowPrecedenceOp =
let { f = (+); infix 1 `f` } in ( -3 `f` 4 )
negatedRightHandSide =
-- This is actually not legal syntax: 3 * - 4
-- However, lower-precedence binary ops work.
-- (see H98 syntax for exp, or imagine it's because it
-- would parse differently as 3 * 0 - 4)
let { f = (+); infix 1 `f` } in ( 3 `f` - 4 )
subtractionNotNegation = 3 -4
negativePattern =
case -3 of { (- 3) -
case -4 of { - 4 -
True } }
-- not legal H98 syntax: case -4 of { _x @ -4 -
-- (parentheses needed)case -5 of { ~ -5 -
subtractionNotNegationPattern =
-- defines infix '-' (shadowing Prelude definition)
let { 3 -4 = True } in (3 - 4)
precedenceOfNegationCantBeChanged =
let { (-) = undefined; infix 9 - } in (- 3 * 4)
negationCantBeQualified =
(Prelude.-3) 4
main = do
print negatedExpression
print negatedTightlyBinding
print negatedNonSection
print negatedNonSectionWithHighPrecedenceOp
print negatedNonSectionWithLowPrecedenceOp
print negatedRightHandSide
print subtractionNotNegation
print negativePattern
print subtractionNotNegationPattern
print precedenceOfNegationCantBeChanged
print negationCantBeQualified
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Isaac Dupree wrote:
Simon Marlow wrote:
I definitely think that -1# should be parsed as a single lexeme.
Presumably it was easier at the time to do it the way it is, I don't
remember exactly.
I'd support a warning for use of prefix negation, or alternatively you
could implement the Haskell' proposal to remove prefix negation
completely - treat the unary minus as part of a numeric literal in the
lexer only. This would have to be optional for now, so that we can
continue to support Haskell 98 of course.
Cheers,
Simon
Yes, I've been thinking about how to implement both - details will come
later when I have more time. I think I have a reasonably working idea
of how to divide up the cases for warnings for ambiguous-looking use of
both infix and prefix minus, as well as actual syntax changes...
not considering warnings, just syntax: 123abc is two valid Haskell
tokens. for example:
\begin{code}
main = (\n c - print (n,c)) 123Abc
data Abc = Abc deriving Show
\end{code}
prints (123,Abc).
So does this suggest that under a negation-is-part-of-numeric-token
regime, 123-456 should be two tokens (a positive number then a negative
number, here), as is signum-456 ...
Presently, GHC doesn't even warn about the first thing (123abc) ^_^
Isaac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGHgT9HgcxvIWYTTURAmhLAJ0Zwd8fRYWRIWDjsTRaPx84x80RBwCgjsMA
RxcCEg+2T/fraJmnsBYVEhE=
=HsSp
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
Isaac Dupree wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Isaac Dupree wrote:
Simon Marlow wrote:
I definitely think that -1# should be parsed as a single lexeme.
Presumably it was easier at the time to do it the way it is, I don't
remember exactly.
I'd support a warning for use of prefix negation, or alternatively you
could implement the Haskell' proposal to remove prefix negation
completely - treat the unary minus as part of a numeric literal in the
lexer only. This would have to be optional for now, so that we can
continue to support Haskell 98 of course.
Cheers,
Simon
Yes, I've been thinking about how to implement both - details will come
later when I have more time. I think I have a reasonably working idea
of how to divide up the cases for warnings for ambiguous-looking use of
both infix and prefix minus, as well as actual syntax changes...
not considering warnings, just syntax: 123abc is two valid Haskell
tokens. for example:
\begin{code}
main = (\n c - print (n,c)) 123Abc
data Abc = Abc deriving Show
\end{code}
prints (123,Abc).
So does this suggest that under a negation-is-part-of-numeric-token
regime, 123-456 should be two tokens (a positive number then a negative
number, here), as is signum-456 ...
Yes, absolutely.
Presently, GHC doesn't even warn about the first thing (123abc) ^_^
and remember that while '123e 4' is 3 tokens, '123e4' is only 1.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Marlow wrote:
So does this suggest that under a negation-is-part-of-numeric-token
regime, 123-456 should be two tokens (a positive number then a negative
number, here), as is signum-456 ...
Yes, absolutely.
[see note 1 at the end responding irrelevantly to that]
Okay, here we go with the through descriptions...
Warn about any - that precedes without spaces a numeric literal, that
is not an application of negate to that literal. This includes when
it's infix (n-1) and when it's out-precedenced (-2^6). === A file that
does not trigger this warning is safe to have negative numeric literals
added to the syntax / lexer. [see Note 2 at the end about how commonly
this warning might occur in practice]
Warn about any - that DOES NOT precede-without-spaces a numeric
literal, that nonetheless means negate. === A file that triggers
neither this nor the previous warning is safe to have negative numeric
literals added AND interpretation of unqualified operator - as negate
removed.
Reverse warnings, for those who want to take advantage of negative
numeric literal syntax and then possibly convert to Haskell98 syntax easily:
If a - isn't followed immediately by a numeric literal, the only thing
to watch out for (and warn about) is the forbidden section (- 1),
which could mean an actual section (\x - x - 1) in the new syntax.
For actual negative literals: warn when literal is the left-hand-side an
infix expression with relevant precedence (( 6, which changes program
behaviour) or (= 6 and not left-associative, which causes a parse
error)). (being on the right-hand side, e.g. (x ^^ -1) is completely
unambiguous, and expressions like (-1 + 2) mean the same thing either
way). Also, warn if the literal is part of a function application:
either it would become infix in '98 syntax (e.g. (signum -2)) or just
negate multiple things to the right (e.g. (-1 foo)) (some of these are
type errors assuming (-) isn't made an instance of Num, but that's a
later stage in the compilation process).
Should we allow positive numeric literals +37 as well, for symmetry,
so we can also break (n+1) as well as (n-1)? (and also break (+1), which
is actually an asymmetric problem since that isn't a section in the
first place in Haskell98)
Implementation notes:
I haven't looked at the part of GHC's code where it deals with fixity
resolution yet, but I'm concerned that GHC might throw away information
about where parentheses were in the original code at the same time -
which is important information for determining whether some of the
warnings are valid, it seems.
For the purpose of warnings, I would explicitly keep track, for
unqualified operator -, whether it was followed by a digit (which is
the unique and certain determiner that a numeric literal follows. Octal
and hexadecimal start with 0c for some c and floating-point always
starts with a decimal digit). This would probably involve adding an
argument isomorphic to Bool to the constructor ITminus. Then in
compiler/parser/Lexer.x just before the @varsym rule (since alex is
first maximal-munch, then top-to-bottom in the .x file, in matching
choice), add rules
- / [0-9] { minus followed by number }
- { minus not followed by number }
( the [0-9] pattern could be refined perhaps... )
Then this notation has to be carried on through the Parser.y, which
shouldn't be too hard.
For negative numeric literals, I think extra rules in the lexer would be
added, '-' followed by the various numeric literal types (this seems a
little repetitious, is there an easier way?). The varieties of literals
that were standard in the first place (i.e. non-unboxed) will get / {
extension is on } qualifications to their patterns. mkHsNegApp (in
RdrHsSyn.lhs) will be simplified or removed, since we are moving towards
a more sensible treatment of negative literals. Another implementation
choice could be to recognize the minus followed by number in the
parser, but then it might be hard to distinguish between '98-syntax
negate, subtraction, and negative unboxed literals, without ambiguity in
the parser?
(Negative) numeric literals can occur in patterns, not just expressions;
that may or may not need tweaks specific to it.
Test cases I suppose I should make a bunch of them, that deal with
every oddity I can think of, since I have already been thinking about
them... (1 Prelude.-1) is infix with either syntax, and shouldn't
(probably) be warned about, etc., etc. -- which explain better what the
intended behaviour is anyway.
Note 1: I happen to think it's silly to allow two such tokens such that
one begins at the same character-location that the previous one ends,
but that's clearly a completely separate issue. I have been bitten by
- -fglasgow-exts and x$y z (template haskell syntax $identifier, which is
rather similar to the proposed negative literal syntax) before; maybe I
don't even want infix operators adjacent to
Re: Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Er,
For the purpose of warnings, I would explicitly keep track, for
unqualified operator -, whether it was followed by a digit (which is
the unique and certain determiner that a numeric literal follows. Octal
and hexadecimal start with 0c for some c and floating-point always
starts with a decimal digit). This would probably involve adding an
argument isomorphic to Bool to the constructor ITminus. Then in
compiler/parser/Lexer.x just before the @varsym rule (since alex is
first maximal-munch, then top-to-bottom in the .x file, in matching
choice), add rules
- / [0-9] { minus followed by number }
- { minus not followed by number }
( the [0-9] pattern could be refined perhaps... )
Then this notation has to be carried on through the Parser.y, which
shouldn't be too hard.
For negative numeric literals, I think extra rules in the lexer would be
added, '-' followed by the various numeric literal types (this seems a
little repetitious, is there an easier way?). The varieties of literals
that were standard in the first place (i.e. non-unboxed) will get / {
extension is on } qualifications to their patterns. mkHsNegApp (in
RdrHsSyn.lhs) will be simplified or removed, since we are moving towards
a more sensible treatment of negative literals. Another implementation
choice could be to recognize the minus followed by number in the
parser, but then it might be hard to distinguish between '98-syntax
negate, subtraction, and negative unboxed literals, without ambiguity in
the parser?
When the new syntax is switched on, assuming this includes removing
- as general prefix negate, ITminus would always be not followed by a
number (by design; those become single negative-number tokens).
Furthermore, we don't really want to treat - specially in this case.
So I guess the rule
- { minus not followed by number }
should be more like
- / { not new syntax } { minus not followed by number }
, and the case that interprets .., =, -, etc. would have its -
case removed (whether new syntax or not).
The only this this don't treat '-' specially in this case might fall
afoul of is this proposed warning option:
If a - isn't followed immediately by a numeric literal, the only
thing to watch out for (and warn about) is the forbidden section
(- 1), which could mean an actual section (\x - x - 1) in the new
syntax.
, if it proves difficult to detect at the appropriate point whether an
infix-operator was written as the unqualified -.
Isaac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGHsG+HgcxvIWYTTURAl7sAJsFFNEcjTA6l5iPSwSqbx8zs6IkSQCcCyJY
F2ng1MXJ0WN1v2scSDe72gM=
=JHlF
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
I definitely think that -1# should be parsed as a single lexeme. Presumably it
was easier at the time to do it the way it is, I don't remember exactly.
I'd support a warning for use of prefix negation, or alternatively you could
implement the Haskell' proposal to remove prefix negation completely - treat the
unary minus as part of a numeric literal in the lexer only. This would have to
be optional for now, so that we can continue to support Haskell 98 of course.
Cheers,
Simon
Isaac Dupree wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Now I understand why negative unboxed numeric literals are parsed
weirdly, after poking around a little!
The parser parses all infix applications as right-associative,
regardless of fixity.
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Renamer
A negative sign on the left of an expression is parsed as a special
case, binding tighter than all infix ops (until the renamer reassociates
it) (but '-' is not parsed that way when it _follows_ an expression: (
process -1# ) is treated as _infix_ minus, i.e. subtraction, i.e. likely
compile error).
Then, before reassociating based on fixity, negation of an unboxed
number is performed (in order to allow a sort of numeric literals that
are negative and unboxed). Here is a result of this funny treatment:
\begin{code}
{-# OPTIONS_GHC -fglasgow-exts #-}
import GHC.Base
main = do
putStrLn $ boxed:++ show (( - 2 ^ 6 ) :: Int )
-- output: boxed: -64 -- === ( -(2 ^ 6 ))
putStrLn $ unboxed: ++ show ( I# ( - 2# ^# 6# ) )
-- output: unboxed: 64-- === ((- 2#)^# 6# )
infixr 8 ^# --just like ^, binds tighter than - (which is infixl 6)
( ^# ) :: Int# - Int# - Int#
base ^# 0# = 1#
base ^# exponent = base *# (base ^# ( exponent -# 1# ))
\end{code}
This particular combination of behavior, unfortunately, doesn't seem
useful for implementing sensible numeric literals, IMHO. My desired
warning scheme would have to wait for the renamer to sort out
fixities... unless I want to warn about (-1==1) which is ((-1)==1), as
well (do I want that warning? how about (1 == -1), or (1 ^^ -1), which
both must parse with negation being tightly binding? I hadn't considered
those very well yet...).
Isaac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGGOF8HgcxvIWYTTURAiT5AKC1Zl9JYuSLBPdey/YdmCriY7FaUQCgqzNQ
clHWTS162IZWHhlXKJR8NhQ=
=zqzy
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Marlow wrote: I definitely think that -1# should be parsed as a single lexeme. Presumably it was easier at the time to do it the way it is, I don't remember exactly. I'd support a warning for use of prefix negation, or alternatively you could implement the Haskell' proposal to remove prefix negation completely - treat the unary minus as part of a numeric literal in the lexer only. This would have to be optional for now, so that we can continue to support Haskell 98 of course. Cheers, Simon Yes, I've been thinking about how to implement both - details will come later when I have more time. I think I have a reasonably working idea of how to divide up the cases for warnings for ambiguous-looking use of both infix and prefix minus, as well as actual syntax changes... Isaac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHLqHHgcxvIWYTTURAu4YAJ9v7fd8tkJLztqQxCblRGZy21UxfwCgn7++ OvLrEoLJtP9Uq8oQGeVhwA8= =hTdv -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Now I understand why negative unboxed numeric literals are parsed
weirdly, after poking around a little!
The parser parses all infix applications as right-associative,
regardless of fixity.
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Renamer
A negative sign on the left of an expression is parsed as a special
case, binding tighter than all infix ops (until the renamer reassociates
it) (but '-' is not parsed that way when it _follows_ an expression: (
process -1# ) is treated as _infix_ minus, i.e. subtraction, i.e. likely
compile error).
Then, before reassociating based on fixity, negation of an unboxed
number is performed (in order to allow a sort of numeric literals that
are negative and unboxed). Here is a result of this funny treatment:
\begin{code}
{-# OPTIONS_GHC -fglasgow-exts #-}
import GHC.Base
main = do
putStrLn $ boxed:++ show (( - 2 ^ 6 ) :: Int )
-- output: boxed: -64 -- === ( -(2 ^ 6 ))
putStrLn $ unboxed: ++ show ( I# ( - 2# ^# 6# ) )
-- output: unboxed: 64-- === ((- 2#)^# 6# )
infixr 8 ^# --just like ^, binds tighter than - (which is infixl 6)
( ^# ) :: Int# - Int# - Int#
base ^# 0# = 1#
base ^# exponent = base *# (base ^# ( exponent -# 1# ))
\end{code}
This particular combination of behavior, unfortunately, doesn't seem
useful for implementing sensible numeric literals, IMHO. My desired
warning scheme would have to wait for the renamer to sort out
fixities... unless I want to warn about (-1==1) which is ((-1)==1), as
well (do I want that warning? how about (1 == -1), or (1 ^^ -1), which
both must parse with negation being tightly binding? I hadn't considered
those very well yet...).
Isaac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGGOF8HgcxvIWYTTURAiT5AKC1Zl9JYuSLBPdey/YdmCriY7FaUQCgqzNQ
clHWTS162IZWHhlXKJR8NhQ=
=zqzy
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Wanted: warning option for usages of unary minus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since the unary negation operator `-' is often considered a wart in Haskell's syntax and in many cases saying negate is arguably clearer anyway, I propose adding options to GHC to warn about its use. The only case I don't normally want to be warned about is negative numeric literals, e.g. (-1), even if in current Haskell they do mean (negate (fromInteger 1)) not (fromInteger (negate 1)) (or equivalently, (fromInteger (negate (fromInteger 1))) as the inner fromInteger === id). I know this would be useful to someone since I caught myself manually cleaning some of my code in this way without the help of warning messages :) Proposed flag names and descriptions (could use a little tidying up) : - -fwarn-unary-minus Causes a warning to be emitted for all usages of the unary operator `-', except those in which its argument is a numeric literal that is not separated from the minus sign by any space (space includes comments). - -fwarn-all-unary-minus For those who hate it with a passion, this option warns about ALL uses of the unary `-' operator, even code like `(-1)'. Opinions? (Should I put a feature request in Trac? Is that what I perhaps should have done in the first place?) Is this simple enough to try to implement myself so I can start getting to know GHC's internals? (I suspect that detecting the adjacency of the - to a numeric literal without changing the actual precedence may be a little tricky... -2^6 parses as negate(2^6) and should get a warning, as should (- 2), IMO) Oh, the actual warning message... file:line:column: Warning: Unary minus in expression foo (or, on the next line, In the expression: foo ?) for an appropriate foo, which has parentheses added to describe the effects of operator precedence, as usual for GHC diagnostic messages (it's just particularly important for making this one easy to understand in some cases) Isaac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGGBpSHgcxvIWYTTURAt5sAKCEIohHMiuUy9AofhWKzvDOf4rwmgCeJcbj e2RmW+UX2E6omuLpFfIH9fs= =1SnR -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unary minus
I wrote: I wonder why Haskell only allows the unary minus on the left side of an expression (lexp in the grammar). The unary minus may also occur on the right hand side (rule: exp - lexp). So -1 == -1 is correct, because == has lower precedence than -. Also -1*2 is correct although it is parsed as -(1*2) because * has higher precedence. There should be no problem to uniquely recognize an unary minus right beside an operation symbol (qop). Does the grammar allow two consecutive qops in other cases? This would allow 1 * - 1 to be correct (which I think is sort of standard), while 1 - 1 clearly is the infix minus. Hugs accepts 1 * - 1, 1+ -1 1- -1, whereas ghc rejects these as precedence parsing error! I think, ghc's behaviour corresponds to the grammar of the report, but hugs behaves more like I would expect. Christian ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
unary minus
Hi, I wonder why Haskell only allows the unary minus on the left side of an expression (lexp in the grammar). There should be no problem to uniquely recognize an unary minus right beside an operation symbol (qop). Does the grammar allow two consecutive qops in other cases? This would allow 1 * - 1 to be correct (which I think is sort of standard), while 1 - 1 clearly is the infix minus. What was the rational for the current restriction of the unary minus? Do I oversee something? Christian ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Unary minus (was: micro-rant)
Folks I suggest we transfer this discussion about unary minus to [EMAIL PROTECTED] As the original poster noted, it is not a subject on which the existing Haskell report is ambiguous or inconsistent, so I don't propose to make any change in Haskell 98. The next version of Haskell, maybe. Simon | -Original Message- | From: Jerzy Karczmarczuk [mailto:[EMAIL PROTECTED]] | Sent: 13 August 2001 16:12 | Cc: [EMAIL PROTECTED] | Subject: Unary minus (was: micro-rant) | | | matt hellige: | | ... i think people would | be pretty frustrated if -56.2 worked but not -x... | | Weell, the Cleaners around have to live with it. -5 works. | For variables they write ~x. But - in front of a number is | not a lexical entity, but a syntactic one, so f -5 and f (-5) | are a bit different. | | I didn't follow this discussion, but please avoid this mess | in Haskell. | | Jerzy Karczmarczuk | | ___ | Haskell mailing list | [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell | ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Unary minus (was: micro-rant)
matt hellige: ... i think people would be pretty frustrated if -56.2 worked but not -x... Weell, the Cleaners around have to live with it. -5 works. For variables they write ~x. But - in front of a number is not a lexical entity, but a syntactic one, so f -5 and f (-5) are a bit different. I didn't follow this discussion, but please avoid this mess in Haskell. Jerzy Karczmarczuk ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
