This is the mail archive of the mailing list for the Guile project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: continuation theory (Re: Translators, yet once more)

> 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
performance goal?

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]