[plt-scheme] Unit won't Import

From: Stevie Strickland (sstrickl at ccs.neu.edu)
Date: Thu Aug 6 14:35:14 EDT 2009

On Aug 6, 2009, at 2:14 PM, Synx wrote:
> The 'thing unit has a procedure to test and create a dummy struct,  
> given
> funny names because I wasn't sure if the default struct bindings were
> exporting right. The 'test unit imports the 'thing unit, only has a  
> test
> procedure, which creates and tests a dummy 'thing struct. And finally
> "test.ss" does a 'define-values/invoke-unit/infer on the test unit and
> attempts to apply the subsequently defined value 'test.

The short answer to your problem is that you need to link together the  
[email protected] and [email protected] units before invoking the result.  You can do this by:

(define-compound-unit/infer [email protected]
   (import)
   (export test^)
   (link [email protected] [email protected]))

(define-values/invoke-unit/infer [email protected])

or, if available in the version of PLT Scheme you're using,

(define-values/invoke-unit/infer (link [email protected] [email protected]))

-----

The longer answer to your problem is that test imports the thing^  
_signature_.  This doesn't automatically link it with the [email protected] unit,  
but instead specifies that it expects to be linked in some way that  
fulfills this signature (whether it be the [email protected] unit or another unit  
that exports the thing^ signature).

When you call define-values/invoke-unit/infer with a unit that imports  
signatures, it attempts to satisfy those signatures with values from  
the current environment.  For example, if we have a signature and unit:

(define-signature print^ (print))
(define-unit [email protected]
   (import print^)
   (export)
   (print 1))

Then we can just define print locally:

(define (print x) (display x))

and then use define-values/invoke-unit/infer to satisfy the imports  
for [email protected] from our local definitions:

(define-values/invoke-unit/infer [email protected])

So the "unbound identifier" errors you're getting are due to the fact  
that you don't have local definitions of the imported names.  However,  
in your case, you aren't trying to import them from local definitions,  
but rather from the [email protected] unit, and thus should follow the short  
answer above.

Stevie


Posted on the users mailing list.