February 2010 - Haskell-prime

showing Ratios
by Doug McIlroy 02 Mar '10

02 Mar '10

Very minor library change to promote readability of output: eliminate spaces in the string representation of Ratios. Currently, a Ratio appears as a pair separated by " % ". The spaces that flank "%" make for confusing output. Example: [1 % 2,1 % 3,1 % 4,1 % 5,1 % 6] The spaces suggest that "," binds more tightly than "%". I claim that [1%2,1%3,1%4,1%5,1%6] is much more readable. It also saves paper and/or screen area. I suspect that the spaces came in to make it easier to find the division point in a lugubrious Ratio like 123456789%987654321 True enough, but such numbers are too incomprehensible to get much scrutiny anyway. I, at least, find that all I do with Ratios much more complicated than 355%113 is squirrel them away in tables that only a computer is likely to read seriously, or edit them into some other form, e.g. for Sloane's Encyclopedia of Integer Sequences. Doug McIlroy

5 7

PROPOSAL: Include record puns in Haskell 2011
by Iavor Diatchki 27 Feb '10

27 Feb '10

Hello, I'd like to propose that we add record punning to Haskell 2011. I think that this is a useful feature which makes working with record fields easier, and reduces clutter in definitions, both in patterns and expressions. Furthermore, this features has been implemented in GHC for a long time (it used to be in Hugs too, once) and we've had plenty of time to iron out dark corners in the design. Thoughts, objections, suggestions? -Iavor

13 16

RFC: Fixing floating point conversions.
by Nick Bowler 26 Feb '10

26 Feb '10

Currently, Haskell does not provide any mechanism for converting one floating type to another, since realToFrac appears to be fundamentally broken in this regard. For details on that matter, see the discussion at http://hackage.haskell.org/trac/ghc/ticket/3676. Essentially, realToFrac does not preserve floating values which are not representable as a Rational. I'd like to start discussing improvements to this situation by submitting some ideas which I have considered for comments. First though, two proposals: * Codify a requirement that Double values are a superset of Float values. C demands this, as it makes it possible to define Float to Double conversions as value-preserving. I couldn't find such a statement in the report; idea #1 below requires this. * Define toRational as throwing an exception on non-finite input. Infinities magically turning into integers is simply not nice. I personally feel that floating types should not be instances of the Real class, but that discussion can be saved for another day. *** Idea #0 *** Fix realToFrac. This seems to be impossible without highly undesirable consequences, see the trac ticket linked above for details. *** Idea #1 *** Add two methods to the RealFloat class: toDouble :: RealFloat a => a -> Double fromDouble :: RealFloat a => Double -> a and a function: toFloating :: (RealFloat a, RealFloat b) => a -> b toFloating = fromDouble . toDouble Advantages: * No extensions (other than this one) beyond Haskell 98 are required. * Simple to define instances, exactly two functions per floating type. * Trivial to implement. Disadvantages: * It encodes directly into the RealFloat class the knowledge that Double can represent values of any other floating type. This makes it difficult or impossible to create new floating types later. *** Idea #2 *** Similar to #1, except using a "generic" type instead of Double. Define a new type, call it FloatConvert, which represents "rational plus other values". Something along the lines of: data FloatConvert = FCZero Bool -- Signed zero | FCInfinity Bool -- Signed infinity | FCNaN Integer -- Generic NaN | FCFinite Rational -- Finite, non-zero value Add two new methods to the RealFloat class: toFloatConvert :: RealFloat a => a -> FloatConvert fromFloatConvert :: RealFloat a => FloatConvert -> a and a function: toFloating :: (RealFloat a, RealFloat b) => a -> b toFloating = fromFloatConvert . toFloatConvert Advantages: * No extensions (other than this one) beyond Haskell 98 are required. * Simple to define instances, exactly two functions per floating type. * Easy to add floating types to the language, and easy for users to define their own in libraries. Disadvantages: * A data type whose sole purpose is to convert floating types seems like a wart. * While the free-form encoding of NaN values will allow conversion from a type to itself to be the identity function, it may make it tricky to perform the "ideal" conversion between different types. *** Idea #3 *** Use a multi-parameter type class: class FloatConvert a b where toFloating :: a -> b Advantages: * Can define any conversion imaginable without constraints. * Straightforward to add floating types to the language. Disadvantages: * Requires multi-parameter type classes. * Not practical for library authors to define their own instances of this class except in special circumstances, since it requires knowledge of all other floating types. Of these three ideas, I think #2 (or something similar) is the most workable. What do others think? -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

4 5

RECOMMENDATION: Use 'labeled fields' rather than records when talking about labeled fields
by John Meacham 24 Feb '10

24 Feb '10

This isn't so much a proposal as a recommendation for terminology we use when talking about things on the list and proposals in general. Calling haskell's labeled field mechanism 'records' leads to all sorts of confusion for people that come from other languages where 'records' means something else, this is compounded by the fact there are several actual record proposals out there that are orthogonal to labeled fields, but calling fields 'records' confuses this issue. I believe we have already gotten rid of every reference to 'record' in the report in favor of 'labeled field' or just 'field', so it would be good if we could use the same terminology in all discussions. Not only will it help avoid confusion but it is a more accurate description of what Haskell actually provides and is in line with the report. So, let's call 'record puns' 'field puns' as a first step. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

2 3

PROPOSAL: Include record puns in Haskell 2011
by Iavor Diatchki 24 Feb '10

24 Feb '10

Hello, (Malcolm, sorry for the double post, I forgot to CC the list) I was thinking mostly about the "old-time"-y punning, where I can write a label, say "theField", and it automatically gets expanded to "theField = theField", in record patterns and record constructing expressions. The only corner case that I can remember about this is the interaction with qualified names, the issue being what happens if a label in a pun is qualified? I think that in such cases we should just used the unqualified form for the variable associated with the label. In patterns, I can't think of any other sensible alternative. In expressions, I could imaging expanding "A.theField" to "A.theField = A.theField" but it seems that this would almost never be what we want, while in all the uses I've had "A.theField = theField" is what was needed. I think that this is exactly what GHC implements, at least based on the following example: module A where data T = C { f :: Int } {-# LANGUAGE NamedFieldPuns #-} module B where import qualified A testPattern (A.C { A.f }) = f testExpr f = A.C { A.f } I imagine that this is fairly close to what was in Haskell 1.3? As far as wild-cards are concerned, I don't feel particularly strongly about them either way (I can see some benefits and some drawbacks) so I'd be happy to leave them for a separate proposal or add them to this one, depending on how the rest of the community feels. -Iavor On Wed, Feb 24, 2010 at 1:35 AM, Malcolm Wallace <malcolm.wallace(a)cs.york.ac.uk> wrote: >> I'd like to propose that we add record punning to Haskell 2011. > > Can you be more specific? Do you propose to re-instate punning exactly as > it was specified in Haskell 1.3? Or do you propose in addition some of the > newer extensions that have been recently implemented in ghc (but not other > compilers), such as record wildcards? > > Regards, > Malcolm > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime >

1 0

location of Haskell reports
by Peter Hercek 23 Feb '10

23 Feb '10

Should not be there a link to Haskell 2010 report on this page? http://haskell.org/haskellwiki/Language_and_library_specification That is if Haskell 2010 is finalized. Where is the standard location to find "Haskel Prime" reports? Peter.

2 1

Proposal: Hexadecimal floating point constants
by Nick Bowler 23 Feb '10

23 Feb '10

I'd like to propose what I believe is a simple but valuable extension to Haskell that I haven't seen proposed elsewhere. C has something it calls hexadecimal floating constants, and it would be very nice if Haskell had it too. For floating point systems where the radix is a power of two (very common), they offer a means of clearly and exactly specifying any finite floating point value. For example, suppose we want to write the least positive value of an IEEE754 double. With hexadecimal floating constants, we write 0x0.0000000000001p-1022 and a reader can immediately tell what this is. One could equivalently write this in a normalized fashion as 0x1p-1074. The exact representation of this value in base 10 is very, very long (there are over 750 significant digits), but we can abuse roundoff to write it succinctly as 5e-324, which is much less clear about which value was intended. Similarly, the greatest finite double value can be written as 0x1.fffffffffffffp+1023. These constants have the form 0x[HH][.HHHHH]p[+/-]DDD where we have the hexadecimal prefix 0x, zero or more hexadecimal digits, and an optional fractional separator followed by zero or more hexadecimal digits. There must be at least one hexadecimal digit. Finally, there is a p followed by an (optionally signed) exponent encoded in decimal. The hexadecimal digits are interpreted in the obvious way and then scaled by 2 raised to the given exponent. Implementing this proposal would change the meaning of expressions like let p4 = 5 in (+) 0x5p4 I don't believe anyone writes code like that, but it's resolved by adding a space, as in let p4 = 5 in (+) 0x5 p4 -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

3 3

Haskell prime: the sequel (2011)
by Malcolm Wallace 22 Feb '10

22 Feb '10

http://hackage.haskell.org/trac/haskell-prime The new committee for Haskell language standardisation has been appointed, based on public nominations. I am the new chair. http://hackage.haskell.org/trac/haskell-prime/wiki/Committee In case you missed it, the previous committee resulted in the minor revision of the language called Haskell 2010. The next revision (Haskell 2011) is due to be decided later this year, around October- November, and published by the beginning of 2011. I would like to emphasise that the future of Haskell is in the hands of the whole community - and that means you. The committee's role is to make decisions, but the task of making and refining proposals belongs with the language's users. Please cogitate, agitate, and formulate! Here is how to get your language idea accepted: http://hackage.haskell.org/trac/haskell-prime/wiki/Process (Don't forget that you can propose _removal_ of features, as well as additions.) Regards, Malcolm

3 2

Negation
by Simon Peyton-Jones 21 Feb '10

21 Feb '10

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

19 34