Re: PROPOSAL: Include record puns in Haskell 2011
On Wed, Feb 24, 2010 at 08:50:42PM +, Simon Marlow wrote:
> On 24/02/10 18:23, Ian Lynagh 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.
>
> 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.
Yes. I too have had this issue with jhc and am a big fan of GHC's field
wildcards. It is motivation enough for me to require a newer version of
ghc for compiling jhc. I'd support field wildcards in 2011, but would
understand if people thought it was too soon.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
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
Re: PROPOSAL: Include record puns in Haskell 2011
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.
I don't mind if a few files that use a ton of label-operations are
marked with NamedFieldPuns and use that feature a lot. But, funnily, if
it were put in the standard then it would be enabled in un-marked source
files, and then I personally wouldn't like it as much. (Any decision is
acceptable to me though.)
-Isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: RECOMMENDATION: Use 'labeled fields' rather than records when talking about labeled fields
On Wed, Feb 24, 2010 at 11:50 AM, John Meacham wrote: > On Wed, Feb 24, 2010 at 11:35:44AM -0800, Evan Laforge wrote: >> On Wed, Feb 24, 2010 at 11:03 AM, John Meacham wrote: >> > 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. >> >> Just out of curiosity, what are the attributes associated with >> "labeled fields" and what are the ones associated with "records"? > > Well, when you have a data constructor like > > data Foo = Foo Int Char > > your Int and Char are the two fields of your data constructor Foo, > labeled fields are exactly that, a way to refer to them by labels rather > than positionally. in particular, the run-time implementation and > ability for optimization is exactly the same. it is simply a more > convienient way to work with a construct that already exists in Haskell > with no overhead, like a newtype. Ah, so to paraphrase, fields are just syntax sugar for an ADT + access functions + update syntax. Update syntax is just sugar for a "\b -> A a _ c -> A a b c" expression. Pure sugar. Records are basically "anything more substantial than sugar" but may imply a new "label" concept (i.e. not just reusing functions), literal syntax, extensibility, type system support for subtyping, etc. etc. This seems like a reasonable distinction. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: RECOMMENDATION: Use 'labeled fields' rather than records when talking about labeled fields
On Wed, Feb 24, 2010 at 11:35:44AM -0800, Evan Laforge wrote: > On Wed, Feb 24, 2010 at 11:03 AM, John Meacham wrote: > > 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. > > Just out of curiosity, what are the attributes associated with > "labeled fields" and what are the ones associated with "records"? Well, when you have a data constructor like data Foo = Foo Int Char your Int and Char are the two fields of your data constructor Foo, labeled fields are exactly that, a way to refer to them by labels rather than positionally. in particular, the run-time implementation and ability for optimization is exactly the same. it is simply a more convienient way to work with a construct that already exists in Haskell with no overhead, like a newtype. A record system generally implies labels that can be easily re-usued between different types and is extensible in nature. They may not need to be pre-declared. Allowing these may require compromises at run-time creating a tension between their utility and performance. I like to think of them more analogous to tuples with labels than declared data types. Of course, not all record proposals for haskell embody the exact same thing, but these features seem to be what people coming to haskell expect out of something called a 'record' system and are more or less what the various proposals provide. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: RECOMMENDATION: Use 'labeled fields' rather than records when talking about labeled fields
On Wed, Feb 24, 2010 at 11:03 AM, John Meacham wrote: > 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. Just out of curiosity, what are the attributes associated with "labeled fields" and what are the ones associated with "records"? ___ 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 Wed, Feb 24, 2010 at 06:54:44PM +, Thomas Davie wrote: > The problem though, unless I'm misunderstanding, is that you *must* > enforce one or other convention here. Either you force everyone who's > style is to never shadow things to do so because of this language > feature, or you remove the language feature and trample on the other > crowd. Hmm? I don't see how this language feature forces shadowing any more than allowing shadowing anywhere else in the language. It is not proposed that field punning replace the previous mechanism for assigning or pulling values from fields, just that it be added as an option. Just as it has always been an option to shadow variables in do notation. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RECOMMENDATION: Use 'labeled fields' rather than records when talking about labeled fields
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/ ___ 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 Feb 2010, at 18:52, John Meacham wrote:
> On Wed, Feb 24, 2010 at 06:23:39PM +, Ian Lynagh wrote:
>> On Tue, Feb 23, 2010 at 07:07:30PM -0800, Iavor Diatchki 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 can see the thinking here, but I don't like for the language to try to
> enforce 'style' or make decisions based on it. I think it is more in the
> spirit of haskell to provide multiple mechanisms when it makes sense and
> let the users figure out what works for them stylistically.
The problem though, unless I'm misunderstanding, is that you *must* enforce one
or other convention here. Either you force everyone who's style is to never
shadow things to do so because of this language feature, or you remove the
language feature and trample on the other crowd.
For what it's worth, I'd side with Ian on this one.
Bob___
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 Wed, Feb 24, 2010 at 06:23:39PM +, Ian Lynagh wrote:
> On Tue, Feb 23, 2010 at 07:07:30PM -0800, Iavor Diatchki 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 can see the thinking here, but I don't like for the language to try to
enforce 'style' or make decisions based on it. I think it is more in the
spirit of haskell to provide multiple mechanisms when it makes sense and
let the users figure out what works for them stylistically.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
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 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.
Thanks
Ian
___
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
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
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
