Record wildcard

[Simon Peyton-Jones]

I've had a look.  It's important for the renamer to resolve this stuff, else how can you report errors from
        f (C {..}) = x+1
How would you know if x was in scope?  I have not applied your patch, so I'm not sure how it would work, but it looks dodgy in the extreme!

What you want is a mapping from constructor -> [field name].  Precisely such a mapping is built in RnNames.exports_from_avail, and again in RnNames.reportUnusedNames.   The comments already remark that this is duplicated work!

I think the easiest thing to do would be to add a new field to the TcGblEnv (in TcRnTypes), next to tcg_rdr_env, which gives the result of applying mkChildEnv to the GblRdrEnv.  You can initialise it in TcRnDriver, about line 157.

Once you have that, everything is easy I think.  Both ConPatDotDot and HsRecordDotDot can be expanded during renaming.

Would you like to add Malcolm's suggestion while you are at it?

Simon



| -----Original Message-----
| From: Lennart Augustsson [mailto:lennart at augustsson.net]
| Sent: 05 February 2007 21:55
| To: Simon Peyton-Jones
| Cc: cvs-ghc at haskell.org
| Subject: Re: Record wildcard
|
| 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.
| >