[plt-scheme] Importing a signature in unit as import-id

On 5/14/06, Matthias Felleisen <matthias at ccs.neu.edu> wrote:
>
> On May 14, 2006, at 8:13 AM, Evangelos Tsagkas wrote:
>
> > (define result@
> >  (unit  (import a-signature^
> >                 a-module@)
> >         (export res@)
> >         (define res@
> >           (compound-unit/sig (import)
> >                              (link (MOD : (open a-signature^)
> > (a-module@))
> >                                    (GENERIC : generic^ (generic@ MOD)))
> >                              (export (open GENERIC))))))
>
> Do you really want to export a unit from a unit? Where are a-signature^
> defined? a-module@

I'm sorry, I was unclear about my intention. A mistake in the res@
unit's export clause made my case all the more confusing. That should
have read (export (open MOD)).

What I'm after is, writing a framework of configurable "generic"
units. The signature a-signature^ contains definitions required to
configure the generic unit plus some more and is not known at compile
time (the part of it that's not required by the generic module)


> > (define-values/invoke-unit (res@) result@ m wbf^ wbf@)
>
> This contains another undefined name: m.

Isn't this the prefix to the defined values?


> If you just want to link wbf@ and generic@ and then run, that's easy.
> You're just one layer of stuff off.

No, I 've managed to do that already. What I'm asking I guess is:

Is it possible to construct one composite signed unit that exports
different signatures depending on client invocation?

...however, I think this probably defies that purpose of signed units.

> -- Matthias

Evangelos Tsagkas


-- 
if feeling is first who pays any attention to the syntax of things
will never wholly kiss you
-- ee cummings