Re: scm_* API extension? [was] scm_* API question

[rm]

On Wed, Jul 31, 2002 at 04:59:35PM -0500, Rob Browning wrote:
[ nice samples removed ]
> 
> etc.  There's also a module-ref function and a module-use! function...

I konw these, but this is all done from the scheme side. I just want
to be able to do the same cool things from C (other than scm_call_*ing
the functions from (ice-9 safe) etc.).

> > BTW, one reasons i do use the module system is the impicit cacheing
> > i get: a module gets loaded only once, and that does make a
> > difference in response time compared to the initial 'eval a file per
> > request' aproach of mod_guile.
> 
> Well that may or may not be the right thing to do if you're *just*
> using the module system for the caching.  In that case, you may be
> better off to implement the caching yourself (via a hash table or
> whatever) and leave the module system to more static modules.

No, cacheing is just a (very) nice side effect. My main rationale is
the namespace encapsulation. In general i think these modules should
be considered static -- during the lifetime of a server the code for
a handler shouldn't change. I put things like 'GuileBind ... ' into
the handler's module since i haven't understood how to do the same 
with environments so far.

> For example, depending on what you're wanting to do, you might want to
> allow different requests to be handled inside separate namespaces,
> though they're all using a common set of code.  OTTOMH, I think you
> could do this by putting the common functionality into a module, say
> foo.scm, then doing something like this for *each* request:
> 
>   (use-modules (foo))
>   (define foo-module (resolve-module '(foo)))
> 
>   ;; For each request...
>   (define next-request-envt (make-safe-module))
                          ^                ^
                          |                |
                          *----------------*
                               |

   Does this mean: module <=> environment in guile?

>   (module-use! next-request-envt (module-public-interface foo-module))
>   (define request-form (list handler-sym current-url-string))
>   (eval request-form next-request-envt)
> 
> Marius, etc.  Please correct any inaccuracies above -- I'm just going
> from what I've gathered while poking around.  I suspect we need more
> thorough documentation of the acceptable usage of the anonymous module
> stuff.

Would be highly welcome ;-)


 Ralf