chicken-users
[Top][All Lists]
Advanced

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

[Chicken-users] Re: let-location & modules - modules for srfi-34&35 - 2


From: felix winkelmann
Subject: [Chicken-users] Re: let-location & modules - modules for srfi-34&35 - 2 questions
Date: Sun, 12 Oct 2008 22:49:57 +0200

On Fri, Oct 10, 2008 at 9:48 PM, Jörg F. Wittenberger
<address@hidden> wrote:
> Thanks - forget about this one.
>
> I've successfully thrown together two (attached) files containing a
> compilation unit each, which contain modules for srfi-34&35.  Those
> replaced the module-unaware define-macro versions I used before.
> Works!!!

Congratulations!

>
> BUT 1st (minor) Question:  it appears that I'm unable to find the
> correct csc invocation to compile those files as units.  I tried -t
> <filename-without-extension> -u <filename-without-extension> but
> eventually resorted to insert a (declare (unit srfi-XX)) at the begin of
> the files.

"-u" means unsafe. You should use "csc -t srfi-34.scm -unit srfi-34".

> Sorry for my momentary reluctance to convert my build process to use
> eggs etc. straight from svn or some chicken aware environment.  This
> ground is shaky enough at the moment and I'm pretty late with my port to
> chicken "3".  Or became it 4 now?  So I better change one thing at a
> time.

The ground is indeed shaky, but this will improve. "4" is the hygienic
chicken. "3" is the currently released one.

> everything works as I want it.  The question remains: what do I do with
> my list, where bindings come from several modules?

There currently is not API to access module-bindings at runtime,
but this will be addressed. In the meantime you can hack around it
by accessing the global variables named "<modulename>#<binding>"
either via the accessors for globals in the lolevel unit or by direct
slot access.

>
> PS: If the attached code is useful, take it under the standard chicken
> BSD licence or GPL or public domain at your discretion (and let me know
> if this would be in conflict with the underlying reference
> implementations - I really did not to anything but wrap them into a
> module clause and find the right import trick to rebind a global
> identifier -- plus this ugly "declare" statement I'd like you to help me
> get rid of anyway).
>

We can make an egg of them. Thanks!


cheers,
felix




reply via email to

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