This is the mail archive of the
mailing list for the Guile project.
RE: continuation theory (Re: Translators, yet once more)
- To: Telford Tendys <telford at eng dot uts dot edu dot au>, guile at sources dot redhat dot com
- Subject: RE: continuation theory (Re: Translators, yet once more)
- From: Brent Fulgham <brent dot fulgham at xpsystems dot com>
- Date: Thu, 13 Jul 2000 16:27:44 -0700
> However, at the heart of it, implementation details do effect
> performance and someone who wants the very best performance
> must take implementation into account, as soon as they decide
> to do that they are fighting against the scheme philosophy
> rather than working with it.
But in this case, wouldn't it be better to build an extension
module in whatever fast language (C?) is needed to achieve the
> Yes you do, because you are not thinking about an application writer
> who has mostly finished their application and is now thinking
> about linking in a scripting language. Such a person generally has
> their own method of storage management and probably has it working
> comfortably -- they are then faced with shuffling their code around
> until it cooperates with guile. In particular:
> * If the user wants guile to be an optional ``plug-in'' module that
> may be loaded at run-time by the application then this is just about
> impossible with the current GC.
Exactly. This is why I have tentatively selected MzScheme (instead of
Guile) for some work I'm doing.
> Aside from the long list in my last mail, run back through the list
> archives and look at how difficult it was to make any decision. There
> is always such a big worry that any choice of direction will
> cut off some potential future application of guile. The fact is
> that not making a decision cuts off the present applications.