[Chicken-users] Re: Compiling files that 'import' eggs that aren't installed?

[Felix]

From: Alejandro Forero Cuervo <address@hidden>
Subject: Compiling files that 'import' eggs that aren't installed?
Date: Sat, 3 Jul 2010 15:16:39 +0200

> How does one compile a file that requires an extension which is not
> currently installed?  I couldn't find the answer looking at The
> Chicken Manual.  Obviously, the file being compiled does not depend on
> macros from the module, it just depends on it at runtime.
> 
> In Chicken 3 this was not an issue.  In Chicken 4, I'm getting:
> 
>> Syntax error (import): cannot import from undefined module
> 
> I know one can do something like:
> 
>   (load (string-append (repository-path) module-name ".so"))
> 
> But I'm thinking about something cleaner than that (that, because it
> uses the normal code that loads eggs at runtime, will, for instance,
> not load the module if it had already been loaded by another
> extension).
> 
> This is a problem for me because (1) I have files that want to execute
> different codepaths depending on which eggs are available (loading
> those that are) and (2) I have mutually dependent eggs (which now I
> can't install in Chicken 4).
> 
> Is there a way to do this?
> 

You can use

  (require-library NAME)

which is just like `require-extension' but doesn't do an `import'.

Note that if the extension is compiled as a module, you will not be
able to access its exported bindings, which doesn't help you a lot, I
guess.

Otherwise this is not possible. The compiler doesn't know that the
require'd extension doesn't export any syntax. What I would do for
(1) is to write a macro that expands into the right thing, 
depending on the availability of an extension:

(define-syntax (maybe-require-extension x r c)
  (let ((name (strip-syntax (cadr x))))
    (if (extension-information name)
        `(,(r 'require-extension) ,name)
        `(,(r 'begin)))))

(2) is problematic: it actually indicates a design flaw in your module
structure (if you allow me to say so). Couldn't you extract the
mutually-recursive part into a third module to break up the
circularity? It should be possible to handle this by using some sort
of intermediate module, but it's too damn hot in this room to think of
an example (it may also because I'm too dim, but taking the heat as an
excuse looks better, of course).


cheers,
felix