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

[F. Wittenberger]

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!!!

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.

BTW: Thanks Felix for the correct pointer into svn.  The matchable case
has been resolved by the current version.  (But somehow the same thing,
to compile it, I had to insert that (declare (unit matchable)) at the
begin.

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.

2nd (real) Question:  [Background: My program implements sort of a
Scheme interpreter, mostly passing though the compiled primitives from
the underlying Scheme system (so right now rscheme and chicken).]  Upon
initialisation I used to pass the bindings from a list of symbols like
this:

(for-each
 (lambda (binding-name)
   (export-to-my-own-envt (eval binding-name) binding-name))
 '(<list of r5rs and some more top level variables>))

As said: this used to work and works for all the top level bindings
except those two I moved into the srfi-35 module!

Now the no-option is to write:

(for-each
(lambda (binding-name)
   (export-to-my-own-envt (eval `(begin (import srfi-35) ,binding-name))
binding-name))
'(<list of r5rs and some more top level variables>))

Or some such.  Since that would evaluate the import statement (and soon
to be multiple statements) so many times upon startup for no value.
Man, I was already contemplating to use cryopid or something to
freeze&restart the chicken built process after initialisation (similar
to rscheme's, LaTeX's or emacs's dumped heap feature).  No, please to
not make me "import" at runtime.  Not at all - because I noticed that
this will try to load those dynamic import libraries.  A) Eventually I
want to be able to link the whole thing statically or at least be
absolutely sure it will not load any *single* file I did not know
before.  B) Startup time.

So: I know the process did the import work before.  If I compile

 (export-to-my-own-envt binding-name 'binding-name)

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

a) I could expand it at compile time into the unrolled for-each loop.
That's quite a lot of code to be executed just once, isn't it?  (Not the
typing, that's a macro's one time work.  The run time code is my concern
here; maybe it's not that much of a damage - that's what I don't know.)

b) Use whatever means to pass all the top level bindings named by list
of symbols from the ???current???, "compile time" environment (where
it's obviously bound already) -- and not the one "eval" sees (where it's
unbound and would require yet another import) -- into my
export-to-my-own-envt procedure (which currently happens to be a
hash-table-set! with intentionally reversed arguments to better catch
accidental misuse; but that might change any time).

* I can do (a), but I'm afraid that's stupid.  Is it?
* If (b) is better (or simply easier, since (a) is to be some rewrite
work in several files), how could I do it?

Thanks a lot

/Jörg

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).

Am Donnerstag, den 09.10.2008, 17:46 +0200 schrieb Jörg F. Wittenberger:
> Am Donnerstag, den 09.10.2008, 12:07 +0200 schrieb felix winkelmann:
> > On Wed, Oct 8, 2008 at 12:45 PM, Jörg F. Wittenberger
> > <address@hidden> wrote:
> > >
> > > Yesterday I tried to convert my code to the module system.  But
> that
> > > failed.  For the time being I managed to get along without
> modules.
> > >
> > > I've got the impression - though this is probably wrong - that I
> can
> > > either convert everything into modules or nothing at all.
> > 
> > You don't have to. But if you use extensions that provide modules,
> you'll
> > have to add the proper "import" forms.
> 
> This appears to be my problem.

srfi-34.scm
Description: Text Data

srfi-35.scm
Description: Text Data