*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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Taral wrote:

On 5/17/07, Joseph H. Fasel 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-----

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⑈

-----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-----

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⑈