This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: continuation theory (Re: Translators, yet once more)
On Tue, Jul 11, 2000 at 01:38:53PM +1000, Telford Tendys wrote:
> Then people start to use scheme, start to like it for many small jobs
> that they can write up very quickly, then they realise how slow it is when
> they apply it to a really big job. The next thing that happens is they try
> to write ``optimised'' scheme scripts to squeeze a bit of speed out of it.
> What this represents is an attempt to cater to implementation details in
> a language that is designed to avoid implementation details and the result
> is generally a mess.
The result is something like a reimplementation of Common Lisp... (ugh)
> To be an embedded language, guile must be small and must not impose a
> burden on the application writers (its current GC system does impose quite
> a burden for applications that use their own storage allocation conventions
> especially when the authors of those applications don't understand GC).
> It must support only minimal features in the core and must have a tiny
> core distribution so that someone distributing an application can offer
> a read-to-go guile library just for those users who don't already have guile.
>
> To be a scripting language it must be quick to start up.
>
> For what it is worth, my personal suggestions follow:
>
> -- 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 agree with everything else in your message, however I do not understand
the conflict between being an embedded language and being a scripting language.
If Guile is small, it will start up quickly, no?
--
C. Ray C. aka Christopher Cramer
crayc@pyro.net
http://www.pyro.net/~crayc/