[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Scope problem?

From: Peter Bex
Subject: Re: [Chicken-users] Scope problem?
Date: Mon, 1 Jun 2009 11:05:03 +0200
User-agent: Mutt/

On Sun, May 31, 2009 at 05:44:10PM -0600, Matt Gushee wrote:
> Well, it helps me to investigate further. But I don't think the actual 
> behavior I have observed quite matches your explanation. For example, it 
> appears that just about any FastCGI request will access symbols defined 
> in foreigners and matchable, yet I have not seen any errors related to 
> those extensions (or rather, I did at first, but not after I added the 
> declarations to import them).

This is caused by a technicality; the symbols from these eggs that you
are using map to macros.  Macros are eliminated at compile time, and
therefore not part of the library itself, but they're part of the import
library, instead.  You can see this if you compile foreigners or
matchable with -j and take a peek at the generated import.scm file.
The macro code is right there.

In fact, the shared library is almost completely empty;
the compiled stuff all ends up in the import library!  This is why
your code still works even though you're not loading the actual
libraries for matchable and foreigners.

It's a good habit to load the library even if you know that the library
has only macros, for this reason: a macro might expand to code that uses
helper procedures which are defined in the library.  Even if they're not
doing that currently, they might in the future.

> Also, I notice that matchable and foreigners are eggs, while srfi-1, -4, 
> and -13 are ... umm, what are they? They are installed with the core 
> distribution, and listed in the Supported Language section of the Manual
> --but you say they should be treated as extensions?

They're shared libraries.  Just as matchable and foreigners are.  Don't
be confused by the fact that eggs can install shared libraries; the
libraries _are not_ the eggs themselves!  eggs are just packages with
stuff inside, like an RPM or DEB file.  For some libraries, the library
could be the only thing in the egg, but there are also several eggs that
install multiple shared libraries or even scripts.  And there are also
some shared libraries that ship with Chicken; these are the ones you
just mentioned.

I agree that it is confusing; especially the distinction between units
that you have to load and units that you only have to import.  This line
is drawn fairly arbitrarily; what ends up in libchicken is what you only
have to import, what ends up in separate libraries is what you also need
to load.  Here too, I think it's a good habit to always load any unit
that's not "scheme" or "chicken".

Hope this helps some more ;)

"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

Attachment: pgpTkffILCBtC.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]