This is the mail archive of the
mailing list for the Guile project.
RE: continuation theory (Re: Translators, yet once more)
- To: Guile <guile at sourceware dot cygnus dot com>
- Subject: RE: continuation theory (Re: Translators, yet once more)
- From: Brent Fulgham <brent dot fulgham at xpsystems dot com>
- Date: Tue, 11 Jul 2000 10:27:35 -0700
> On Tue, 11 Jul 2000, Telford Tendys wrote:
> > -- Guile should make it's primary target to be an extension language
> > for applications. It should NOT attempt to be a scripting language,
> > nor should it worry if other scheme implementations can do
> > something that guile cannot do.
I disagree. If I can't use Guile as a scripting language (as part of my
extension) than what's the point? If I have to embed Python to get
services, then I'll make it my extension language as well. I think it's
important that Guile be available and usable as a scripting and extension
language. Otherwise, there is very little point in using it at all.
> > -- Guile should not attempt to support a multi-threading system but
> > it should be thread-friendly itself so that an application which
> > uses threads can use guile. There is absolutely no value in an
> > extension language that tries to spawn its own threads all over
> > the place -- whoever is designing the application will make their
> > own mind up about how many threads they need and what they are
> > doing with them -- presume that the application designer is right
> > sometimes.
Again I disagree. Guile needs to support threaded programming. Providing
some programming constructs to the application programmer (i.e., the native
C threads), but not to the extension programmer, will create situations
certain extensions cannot be written (or cannot be written efficiently).
Threads are a basic and fundamental part of many modern designs. To omit
them for the extension programmer will result in a crippled extension
One obvious case where threads would be warranted for extension programming
is an extension that act as fundamental parts of the parent program (e.g.,
a spell checking module for a text editor, an HTML parser for a web