I'm not sure there's a "good" reason; it seems a reasonable idea. But it's certainly not in Haskell today, and my feeling is that's it's not sufficiently compelling to implement as "yet another GHC feature". But if loads of people say it'd transform their lives, I might reconsider :-) Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Ian Lynagh | Sent: 16 November 2004 21:10 | To: Malcolm Wallace | Cc: haskell@haskell.org | Subject: Re: [Haskell] Unnamed fields | | On Tue, Nov 16, 2004 at 04:07:48PM +0000, Malcolm Wallace wrote: | > On Tue, 16 Nov 2004 15:04:02 +0000, Ian Lynagh <igloo@earth.li> wrote: | > | > > > Is there a good reason why I can't say | > > > | > > > data Bar = Bar { _ :: Int, _ :: Char, x :: Bool } | | In case it wasn't clear, there is an x :: Bool in lots of alternatives, | so I really want | | data Bar = Bar { _ :: Int, _ :: Char, x :: Bool } | | Baz { _ :: String, x :: Bool } | | ... | | > Since you only want one field out of many, what is the difficulty in | > simply defining the projection/updating functions separately? | > | > data Bar = Bar Int Char Bool | > x (Bar _ _ b) = b | > (Bar i c _) `updX` b = Bar i c b | | Then I have to write twice as much again (2n if there are n fields I do | want to name). I'm not denying it's possible to do without it, but it | would make life easier if we had the above. I also think that it feels | inconsistent that it isn't possible. | | | Thanks | Ian | | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell