Record wildcard

[Simon Peyton-Jones]

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.