> 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
scripting
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
where
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
language.
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
server, etc.)
Thanks,
-Brent