unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: rm@fabula.de
Subject: Re: scm_* API extension? [was] scm_* API question
Date: Thu, 1 Aug 2002 11:41:21 +0200	[thread overview]
Message-ID: <20020801094121.GC7425@www> (raw)
In-Reply-To: <20020731150602.A32555@kiwi.pyrotechnics.com>

On Wed, Jul 31, 2002 at 03:06:02PM -0500, Christopher Cramer wrote:
> I have no idea why you think it would better, but with certain types of
> applications, it's impossible.
> 
> For sake of argument, let's say there are two different ways to use Guile.
> One way is to extend Guile through C, by using load-extension. This works
> fine if the C code is ignorant of the module system (writing a wrapper
> module in Scheme handles everything). The other way is to extend C through
> Guile, which cannot stay module system ignorant, because you typically
> want to load multiple Scheme scripts without worrying about clashing
> symbols from the different scripts -- this is currently impossible
> without getting deep into the details of the module system.

Yes, this is exactly the situation i just encountered. I know that
everyone and their grandmother tells me to write everything in the
scripting language but i just don't feel like rewriting Apache in guile --
besides: that might p**s of a lot of perl hackers ;-)

As a user of _embedded_ guile there a a few specific things i'd expect
from my ideal scripting language:

 - clear encapsulation of namespaces and scope (something i missed in
   TCL for example) - for this is currently use guile's module system,
   but i need to have access to the module mechanics from my C side.

 - save execution/evaluation of script code. I need to ensure that i
   can reliably dissable certain things: a user script should not be
   allowed to call (exit 0) and bring down the whole webserver ;-)
 
 - An (opaque) representation of an 'interpreter'. One thing i found 
   rather elegant in TCL (perl to, if i recall correctly) was the
   possiblility to run several interpreters in parallel. Guile seems
   to completly lack this (i think i understand why, but i still miss
   it).

 - Thread support. I'm personally not a big friend of threaded apps,
   but it seems that more and more code assumes thread awareness. 
   For example i'd love to port mod_guile to Apache2, but unfortunately
   Apache2 _can_ be configured at runtime to work in multithread mode
   (or even a mixture of prefork and multithread). For my personal use
   i don't care since i can just _not_ enable multithreaded operation
   but a mod_guile that doesn't work in certain operation modes will
   just not make it into any distribution.
   

> I can provide examples of what I had to do with Recluse; roughly 300 lines
> of C code are devoted to dealing with the module system.

(define Ralf idiot)

I should've just looked at your code instead of bugging the list ;-)

  Ralf


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


  parent reply	other threads:[~2002-08-01  9:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-30 12:14 scm_* API question rm
2002-07-31  1:09 ` Christopher Cramer
2002-07-31 10:03   ` scm_* API extension? [was] " rm
2002-07-31 10:10     ` Marius Vollmer
2002-07-31 18:21       ` rm
2002-07-31 21:59         ` Rob Browning
2002-08-01 10:10           ` rm
2002-08-01 16:51             ` Rob Browning
2002-08-05 15:08         ` Marius Vollmer
2002-08-05 16:06           ` rm
2002-08-05 16:49             ` Marius Vollmer
2002-07-31 20:06       ` Christopher Cramer
2002-07-31 22:14         ` Rob Browning
2002-08-01  9:41         ` rm [this message]
2002-08-05 17:51           ` Marius Vollmer
2002-08-05 18:12             ` Han-Wen Nienhuys
2002-08-05 18:45               ` Rob Browning
2002-08-05 18:31             ` Rob Browning
2002-08-05 18:33             ` rm
2002-08-05 15:12         ` Marius Vollmer
2002-07-31 10:11 ` Marius Vollmer
2002-07-31 10:30   ` rm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020801094121.GC7425@www \
    --to=rm@fabula.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).