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: 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
PROPOSAL: Include record puns in Haskell 2011
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.wall...@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@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: PROPOSAL: Include record puns in Haskell 2011
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.
Groetjes,
Martijn.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: Include record puns in Haskell 2011
On 24/02/10 18:23, Ian Lynagh wrote:
On Tue, Feb 23, 2010 at 07:07:30PM -0800, Iavor Diatchki wrote:
I'd like to propose that we add record punning to Haskell 2011.
Thoughts, objections, suggestions?
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.
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.
There are reasons to find this distasteful, yes, but I think the
alternative is much worse.
I'm not proposing record wildcards (yet) *cough* labelled-field
wildcards, but punning is a step in the right direction.
Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
