[plt-scheme] Using one signature in place of two

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Thu Jan 1 16:20:18 EST 2009

At Tue, 30 Dec 2008 16:33:28 -0600, Matthew Flatt wrote:
> At Tue, 30 Dec 2008 16:57:16 +0000, "Noel Welsh" wrote:
> > I'm having some fun with the unit system.
> > 
> > I have two signatures a^ and b^ which are used by mutually recursive
> > units.  The consumers of the resulting compound unit always want to
> > use the union of a^ and b^, so I defined a signature thus:
> > 
> > (define-signature c^ extends a^
> >   ((open b^)))
> > 
> > and consumers specify they import c^ and I invoke thus:
> > 
> > (define-values/invoke-unit [email protected]
> >   (import c^)
> >   (export consumer^))
> > 
> > This, however, doesn't work.  I get complaints about duplicate
> > identifiers.  E.g.:
> > 
> > :unit: rename created duplicate identifier row-col->idx40 at: (rename
> > row^ (struct:row22 struct:row) (make-row23 make-row) ...
> I'm fairly certain that this is a bug in the unit system (related to
> the expansion of `open' within a signature), but I don't yet know how
> to fix it. I'm still thinking about it.

My solution involved changing the meaning of `rename', `only', and
`except' in signatures. Now, when you write

 (rename [new old])

then `old' must be equal to the old binding in the `bound-identifier=?'
sense instead of `free-identifier=?'. (There should be some way to say
that without appealing to syntax-object operations...)

This change fixes `open' because `open' is implemented using `rename'.
For the same reason that it fixes `open', I think it's a sensible
change in general. Let me know, of course, if the change breaks
anything else in your use of `scheme/unit'.


Posted on the users mailing list.