Re: PROPOSAL: Include record puns in Haskell 2011
Simon Marlow wrote:
While I agree with these points, I was converted to record punning
(actually record wildcards) when I rewrote the GHC IO library. Handle
is a record with 12 or so fields, and there are literally dozens of
functions that start like this:
flushWriteBuffer :: Handle - IO ()
flushWriteBuffer Handle{..} = do
if I had to write out the field names I use each time, and even worse,
think up names to bind to each of them, it would be hideous.
What about using field names as functions?
flushWriteBuffer h@(Handle {}) = do
... buffer h ...
Of course, you always have to drag h around.
Regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: Include record puns in Haskell 2011
Hello,
In order to keep the discussion structured I have created two tickets
in the haskell-prime trac system
(http://hackage.haskell.org/trac/haskell-prime):
* Proposal 1: Add pre-Haskell'98 style punning and record
disambiguation (ticket #136)
* Proposal 2: Add record-wildcards (ticket #137)
I decided to split the two into separate tickets because, at least in
my mind, there are different things that we might discuss about the
two, and also they make sense independent of each other (although
record wildcards without punning might be a bit weird :-).
I think that both proposals are worth considering for Haskell 2011
because there are situations where they can significantly improve the
readability of code involving record manipulation. I disagree with
the stylistic issues that were brought up in the discussion because I
do not believe that variable shadowing should be avoided at all
costs: at least for me, avoiding shadowing is a means to an end
rather then an end in itself. In the case of record puns, I think
that the clarity of the notation far surpasses any confusion that
might be introduced by the shadowing. Furthermore, as other
participants in the discussion pointed out, the proposed features are
orthogonal to the rest of the language, so their use is entirely
optional.
-Iavor
On Fri, Feb 26, 2010 at 2:59 AM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
Simon Marlow wrote:
While I agree with these points, I was converted to record punning
(actually record wildcards) when I rewrote the GHC IO library. Handle
is a record with 12 or so fields, and there are literally dozens of
functions that start like this:
flushWriteBuffer :: Handle - IO ()
flushWriteBuffer Handle{..} = do
if I had to write out the field names I use each time, and even worse,
think up names to bind to each of them, it would be hideous.
What about using field names as functions?
flushWriteBuffer h@(Handle {}) = do
... buffer h ...
Of course, you always have to drag h around.
Regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
___
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: RFC: Fixing floating point conversions.
On 14:23 Thu 25 Feb , John Meacham wrote: On Thu, Feb 25, 2010 at 10:40:48AM -0500, Nick Bowler wrote: *** 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 That is exactly how I solved it in the jhc libraries. Though, I may switch to using a 'FloatMax' type that is always aliased to the largest floating point type available, now that Float128 and Float80 are potentially available. (but it would just be an alias for Double for now) Indeed, a type alias sounds like a good improvement to idea #1 for exactly the reasons that you mention. However, for an actual amendment to the standard, I'd like to see a solution which allows libraries to define their own instances of the numeric classes. Imagine that someone wants to create a library which implements decimal floating point arithmetic. With something like toDouble or toFloatMax, the author is faced with two major obstacles: * After creating new types, 'FloatMax' (which can't be redefined) might not be the max anymore. * When 'FloatMax' has a different radix, there is going to be loss of information when converting to it. For example, 1/5 is exactly representable in decimal floating point, but not in binary floating point with any finite number of significand digits. The end result is that 'toFloating' is not suitable for the decimal floating point library, so the author would have to invent her own conversion method. It is for this reason that I prefer something along the lines of idea #2 with a generic intermediate type. Nevertheless, #1 (with or without FloatMax) is still a /huge/ improvement over the status quo. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
