Re: Better support for transition to guile-1.6

[Mikael Djurfeldt]

Tom Lord <address@hidden> writes:

> There are some parts of the design of Guile that are very limiting,
> at least for some applications.  These include:
> 
>       The use of the C stack to hold the current continuation.
> 
>       The conservatively-oriented GC interface.
> 
> 
> 
> It would be nice if Guile had the freedom to change those details
> without impacting client programs.  

On one hand, I agree that such freedom in itself would be good.  On
the other hand, achieving such freedom has a large impact on client
programs.

The C stack holds the current continuation because we use a simple
mapping between primitive procedures and C functions and because the
flow of control in Scheme is largely paralleled by the flow of control
in the implementation of the interpreter.  This makes the C world
interact more smoothly with the Scheme world.  It makes it easy to
implement new primitives when using Guile as an application extension
lanuage, and it makes it easy to call Scheme procedures from the
application and vice versa.

The conservatively-oriented GC interface saves the user from lots of
"annotation" when implementing primitives and when dealing with Scheme
data from the application.  Again, it makes Guile easier to use in its
role as an embedded language.

Regarding the continuations, it is conceivable to use some hybrid
approach so that part of the continuation, associated with the Scheme
level, is stored elsewhere while calls to primitives are made "on the
stack".  I'm not sure that would require a large change in the API.

Regarding the GC interface, it is conceivable to use some kind of
preprocessor to avoid explicit annotation.

In both cases, a lot of development and experimentation is needed
before we can design an API.  Such a thing could maybe be done for
guile-2.0.

Since there are lots of improvements between 1.4 and 1.6 we should aim
for getting it out reasonably soon.  We can't wait until next year.

In summary: There's no way we would do anything regarding these two
points for 1.6.  For the future, we'll simply see what people come up
with.

> But if there are many people who will soon have to make large changes
> to the way their programs call Guile, then perhaps this is a good
> time to carefully design a stable and flexible API that can survive
> even as the implementation(s) evolve.

I definitely agree that this has been a weak point in Guile
development: We should have put more thought into the API from the
start (many times).

But regarding 1.6, we have to have some kind of pragmatic attitude.
Designing a new API takes too long time.  A reasonable compromise
would be that a small group of people go through the entire current
API before the 1.6 release.  They could check for consistency and at
least have some kind of forward perspective.  They could ensure that
there is at least some kind of feeling that the API fits together as a
whole.  Currently, I don't think anything more ambitious would be
productive, and if this is done, it is only meaningful if these people
really have time to go through the entire API.

Best regards,
Mikael D.