RE: [Haskell] Unnamed fields
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Ian Lynagh
| Sent: 16 November 2004 21:10
| To: Malcolm Wallace
| Cc: [EMAIL PROTECTED]
| Subject: Re: [Haskell] Unnamed fields
|
| On Tue, Nov 16, 2004 at 04:07:48PM +, Malcolm Wallace wrote:
| > On Tue, 16 Nov 2004 15:04:02 +, Ian Lynagh <[EMAIL PROTECTED]>
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
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Unnamed fields
On Tue, Nov 16, 2004 at 04:07:48PM +, Malcolm Wallace wrote:
> On Tue, 16 Nov 2004 15:04:02 +, Ian Lynagh <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Unnamed fields
Martin Sjögren wrote:
>On Tue, 16 Nov 2004 15:04:02 +, Ian Lynagh <[EMAIL PROTECTED]> wrote:
>
>>Hi all,
>>
>>Is there a good reason why I can't say
>>
>>data Bar = Bar { _ :: Int, _ :: Char, x :: Bool }
>>
>>?
>
>I agree that it would be useful, but wouldn't
> data Bar = Bar Int Char { x :: Bool }
>make more sense as far as syntax goes?
It's a bit problematic because of the current all-at-once behavior of
labeled construction. One would presumably want to construct a Bar with
an expression like
Bar 3 'c' { x = False }
But that won't work because the brace notation has a higher precedence
than function application (!). You'd have to write
(Bar 3 'c') { x = False }
I guess you could give Bar the type (Int -> Char -> Bar), with the
understanding that it initializes x to _|_, and treat the { x = False }
as an update. But to be consistent, the data constructor in a
declaration like
data Quux = Quux { x :: Int, y :: Char, z :: Bool }
ought to have the type Quux then, not (Int -> Char -> Bool -> Quux) as
it does currently. And none of this is going to work if your labeled
field is in any position except the last.
-- Ben
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Unnamed fields
On Tue, 16 Nov 2004 15:04:02 +, Ian Lynagh <[EMAIL PROTECTED]> wrote:
> > Is there a good reason why I can't say
> >
> > data Bar = Bar { _ :: Int, _ :: Char, 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
Regards,
Malcolm
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Unnamed fields
On Tue, 16 Nov 2004 15:04:02 +, Ian Lynagh <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> Is there a good reason why I can't say
>
> data Bar = Bar { _ :: Int, _ :: Char, x :: Bool }
>
> ?
> (Or "data Bar = Bar { Int, Char, x :: Bool }" if you prefer, but that's
> susceptible to typos of the "x, y, z :: Int" syntax causing confusion).
I agree that it would be useful, but wouldn't
data Bar = Bar Int Char { x :: Bool }
make more sense as far as syntax goes?
/Martin
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
