This is the mail archive of the guile@sources.redhat.com 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)


On Tue, Jul 11, 2000 at 11:15:43AM +0200, Michael Livshin wrote:
> Telford Tendys <telford@eng.uts.edu.au> writes:
> 
> > To be a full-blown scheme implementation, guile must support the
> > scheme philosophy, which is not going to suit users who want their
> > chance to control the low level implemention nitty gritty (i.e. who
> > want decent performance).
> 
> interesting.  could you explain that further, I'm having trouble with
> some of the logic.

Scheme is founded on the belief that the scheme program should be as
close to a pure algorithm as possible without any reference to
implementation details (such as whether a stack copy is required or not).
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.

In an ideal world, a compiler would be so smart that it could safely
guarantee a highly optimised result every time but at the stage where
we are at, even C compilers are far from perfect at optimising the C
language (where the programmer makes 90% of the implementation decisions).
Optimising scheme requires the compiler to make a lot more decisions.

The result is that scheme is an excellent language for SOME THINGS.
In particular, knocking out programs quickly and getting something
that works correctly.

> > 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).
> 
> you want to interact with a GC'ed system from C and not have to
> understand GC?  why, you can, but it'll be a very superficial
> interaction.  I'm not sure you'd want to.
> 
> or perhaps I misunderstood your point?

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.

* If the user has loops that do extensive malloc() and free() as part
  of linked list construction or for whatever calculation purpose they
  may require (and yes almost every C program does this somewhere)
  then the cannot call that loop from guile, nor can they call any guile
  code from inside that loop, unless they insert SCM_DEFER_INTS and
  SCM_ALLOW_INTS at the correct places in their code and probably they
  have to ensure that allocation is done in just the right way because
  they cannot always depend on the code completing in the way a C
  programmer would expect.

* There are optimisation issues that require the volatile qualifier
  on some SCM variables (but only in some circumstances, the C programmer
  just has to know when). If not done correctly, this leads to garbage
  collection bugs which can strike at random times on code that has
  already been fully tested and proven correct.

* If the application uses signals for its own purposes then it must
  wrest control of those signals back from guile after guile grabs them
  at initialisation time.

> [ come to think of it, what is there to not understand about GC as a
>   concept?  perhaps you mean the specific conservative GC
>   implementation used by Guile? ]

Perhaps I just mean that it isn't as easy to use as people pretend,
I found a lot of strange things happening when I first tried to write
C code that worked with guile. I think I've got everything under
control now -- at least I have done some big stuff and haven't had any
recent crashes. Still, I have quite a few scm_xxxx function calls
dotted around the place (most of which could be replaced with gh_xxxx
but I just haven't gone through it all).

> > To be a high performance (speed) language it needs a white hot
> > compiler and for scheme that implies a compiler that can resolve all
> > the undeclared implementation issues that scheme programmers are
> > told they don't have to think about (i.e. major research project).
> 
> it's not a major research project anymore, as all imaginable research
> have already been done, sometimes many times over.

I keep hearing that but I'm far from believing it.

Suppose, you have a numerical algorithm... how do you know
if it is going to be able to complete its calculation using only
integers, or if it might need bignums, rationals or floating point?
From the point of view of expressing the algorithm you don't have to
say exactly what types are required but from the point of view of
actually compiling the algorithm you need to know exactly what are the types.

Then there is the extra problem of specifying types for module interfaces
(the other side of the interface is invisible to the compiler it cannot
do type analysis over there).

> it's a lot of work to implement, though.

Waving it off as an implementation problem doesn't make it go away.
We are a long way away from having a full strength scheme compiler.

> [ note: white hot performance is a nice thing to have, but is not one
>   of the _main_ Guile goals. ]

This is what I was trying to say... there are some things that guile
is going to be good for and some things that it isn't. The more there
is focus on the niche where guile can work well, the more results can
be obtained.

> > Because guile has no focus, there is no ``right'' way to do anything
> > in guile because there is always the question ``when you say right,
> > what is this going to be right for?'' the inevitable answer is
> > ``everything'' and the end result is ``nothing much''.
> 
> examples?

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.

	- Tel


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