Record wildcard

[Lennart Augustsson]

It could be my lack of knowledge.  But during rename I was not able  
to find the field names.  But that could have been pure oversight on  
my part.  If they can be found I'm happy to have it expanded.

	-- Lennart

On Feb 5, 2007, at 09:42 , Simon Peyton-Jones wrote:

> I've applied all except the main patch.
>
> I don't yet understand the difficulty.  Why can't the renamer replace
>         C {..}
> by
>         C {x1=x2, ...,xn=nx}
> and behave *exactly* as if the latter had been written?  Why this  
> stuff with the lookup function?
>
> Admittedly, the typechecker might then emit a message showing code  
> the programmer didn't write, but we could take a bit of care to  
> make sure that didn't happen.
>
> Simon
>
> | -----Original Message-----
> | From: cvs-ghc-bounces at haskell.org [mailto:cvs-ghc- 
> bounces at haskell.org] On Behalf Of Lennart Augustsson
> | Sent: 05 February 2007 00:11
> | To: cvs-ghc at haskell.org
> | Subject: Record wildcard
> |
> | Here's the complete record wildcard patch.
> | Even if you don't accept the (somewhat ugly) patch to implement the
> | wildcarding it
> | would be nice if you could apply all the minor ones (i.e., all but
> | the last).
> |
> |         -- Lennart
> |
> | Implement C{..} notation for expressions and patterns.
> |
> | The C{..} notation is used as a short hand for C{x1=x1, x2=x2, ...}
> | where xn are all the fields of the constructor C.
> | This features is activated by using the -frecord-wildcard flag.
> | For example, the following is valid:
> | data C = C { x :: Int, y :: Int }
> | f a =
> |       let x = 1
> |           y = x + a
> |       in  C{..}
> | g C{..} = x + y
> | The C{..} in a pattern is a little dubious since it introduces bound
> | variables
> | with no obvious binding site.  But it is extremely handy for
> | accessing records
> | with a large number of components.  (The construct has a long
> | tradition with
> | names like open/with/use.)
> | The implementation for C{..} in expressions is reasonable clean.   
> But
> | the
> | implementation for patterns really needs fixing.  It only barely  
> works
> | because it is able to hijack the globally bound field selector  
> names.
> | It also interacts very badly with any feature that uses
> | collectPatBinders
> | since this function does not return the correct set when C{..} is  
> used.
>