[gambit-list] Re: loading modules multiple times

[Christian]

At 14:41 Uhr +0100 11.08.2005, Adam Langley wrote:
>On 8/11/05, Christian <christian at pflanze.mine.nu> wrote:
>>  I'm wondering why you need that patch.
><snip>
>
>Yes, I could catch the load exception but I don't want to copy and
>paste that code into every module. Of course I could that module
>loading form into its own module, but then how do I load that?

Maybe put (load "my-load") into your main program, which has that 
definition. Your modules would just use the already-loaded definition.

>  > Some words about the logic behind the error (from how I see it): load
>>  on source code can simply reload the source, there's no
>>  implementation problem with that. It does two things, reparse the
>>  source (which may have changed), and re-run it's body (which means,
>>  perform bindings, thus overwriting bindings which may have changed
>>  since after the first load).
>
>Perfectly true and loading a source file multiple times is just fine.
>
>I recognise the inconsistency between loading source multiple times
>and loading a binary multiple times (with this patch); the former
>running the body multiple times.
>
>But modules generally pretty quickly reach the point where they stop
>changing too often and end up compiled. Many of my .scm files will
>start with something like
>
>(load "srfi-1")
>
>But, if I do that, then I can't ever create a higher level module
>which imports either srfi-1 itself and a lower module, or imports two
>lower modules which do.
>
>Questions about design purity are moot while something so simple doesn't work.

I've started exactly like you, e.g. realised that gambit doesn't 
offer a loading infrastructure which tracks what has been loaded, and 
also realised that using the namespace infrastructure manually (by 
writing separate "C header file alike" files) would be tedious, and 
that just aliasing bindings using those header files would be risky 
since if one piece of code overwrites that foo routine from bar.scm 
then every other piece of code also using that bar.scm's foo routine 
would suffer from the change as well, and after realising that I 
could also easily dispense of "make"&makefiles for tracking when 
modules have to be rebuilt from sources, I ended up with chjmodule.

>chjmodule is a nice bit of code, but is very slow and has far too many
>bodges necessitated by Gambit's code.

Well, then maybe it's time now to make it faster and resolve the bodgery?

Marc:

* how can one cheaply copy a binding from one namespace to another? 
I'm using (eval `(define ,fully-qualified-to ,fully-qualified-to)) 
now, and that's the slowest part of the whole thing.

* how can one do the same with runtime macro definitions? (I'm using 
something like (eval `(define-macro (,fully-qualified-to . args) 
(append ',fully-qualified-to args))) currently.)

I'm sure the remaining bodgery can be removed as well (path handling, 
calling external commands -> provide better support, wrapping a file 
with some code before compilation -> do it on the s-expr level 
maybe?, I don't know how to keep position information yet). I'll 
summarize all remaining things which I find awkward as soon as 
someone asks for it or when I'm going over reimplementing it.

Christian.