RE: PROPOSAL: Include record puns in Haskell 2011
| we implicitly get
| f :: T - Int
| which punning shadows with
| f :: Int
| whereas I generally avoid shadowing completely.
|
| I agree with Ian.
|
| I tend to agree.
I originally had field puns in GHC, and then took them out when Haskell 98
removed them, after a discussion very like this one. I put them back in
because some people really wanted them.
Actually GHC has three separate extensions to do with named fields:
field disambiguation (Section 7.3.14)
field puns (Section 7.3.15)
field wildcards (Section 7.3.16)
Look here
http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#disambiguate-fields
Opinions differ. I'm rather with John: let the programmer choose, rather than
enforcing a style in the language. For punning, the programmer can certainly
choose on a case by case basis. If you use Haskell 98's existing syntax, there
is no change to the semantics if you switch on field puns:
data T = C { f :: Int }
foo (C {f = x}) = ... -- No punning
bar (C {f}) = ... -- Punning
It would help this discussion if someone created a ticket to explain the actual
proposal, so that we are all discussing the same thing.
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
showing Ratios
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Fixing floating point conversions.
Nick Bowler wrote: *** Idea #3 *** Use a multi-parameter type class: We couldn't go down this route until MPTCs themselves are added to the language, which I think is unlikely to be soon as the whole fundeps/type families issue is still unresolved. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: RFC: Fixing floating point conversions.
Nick Bowler schrieb: *** 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 interesting. What is the Integer in FCNaN for? 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. I don't understand this last point about free-form encoding of NaN I would come up with a data type like: data ExtNum a = NegativeZero | NaN | Infinity Bool | Num a add instances for the classes, Eq, Ord, Num, (depending on a that must be at least from the class Num for 0) and use ExtNum Rational for floating point conversions. Cheers Christian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011
Isaac Dupree m...@... writes:
On 02/24/10 13:40, Martijn van Steenbergen wrote:
Ian Lynagh wrote:
I have a feeling I'm in the minority, but I find record punning an ugly
feature.
Given
data T = C { f :: Int }
we implicitly get
f :: T - Int
which punning shadows with
f :: Int
whereas I generally avoid shadowing completely.
I agree with Ian.
I tend to agree.
snip
-Isaac
(I know how you're always looking for things to take out of
Haskell ...)
I can see the ugliness of having a name with two
incompatible types (especially in the same scope).
I wonder: if a programmer from Mars landed into Haskell a la
GHC 2010 (that is, unburdened by history back to v1.3),
wouldn't it be the scare-quotes 'implicit' field selector
that seems the odd man out?
After all, the program text declares { f :: Int }, and in
all uses of the field label apart from selecting, it _is_ an Int.
Where does this function thing come from?
By the way, it seems you can arrive at the same
level of confusion like this (declared in a distinct scope):
f (C { f }) = f-- f :: T - Int
- Anthony
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011
(I know how you're always looking for things to take out of Haskell ...) I can see the ugliness of having a name with two incompatible types (especially in the same scope). That's a good point, but even if not totally logical I think the automatic Rec - X function is more important than the X meaning. Functions are more resistant to change (for instance, I changed from String to Data.Text but could keep the old recString as a function when the field named changed), so while I think the sugar to bring names into scope is handy, I think functional access should be encouraged as the main way to do it. The whole tension between syntactic convenience of pattern matching and the flexibility of function accessors in the face of change is kind of unfortunate. It mirrors the OO dilemma of x.y vs. x.y(), which some OO languages do away with altogether. So I'd want to go the other way by making functional access and update more convenient and prominent rather than syntactical. Maybe we could have a little extension of view patterns where f (field -) = y is transformed to f (field - field) = y. It's still a shadow, but at least now it works with any function. It might be nice to do the same with update functions, but those aren't even generated automatically (anyone got a generics thing that cranks those out?). ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
