Record wildcard

[Lennart Augustsson]

Thanks!  I'll have a look at using the available info.

The patch I have is very dodgy, but it does work (kind of).
In 'f C{..} = x+1', in case x is bound in C{..} then it is
in scope, because it's available as a selector function. :)
Devious, huh?  Horrible!

	-- Lennart

On Feb 6, 2007, at 09:05 , Simon Peyton-Jones wrote:

> 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.
> | >
>