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)


Telford Tendys <telford@eng.uts.edu.au> writes:

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

as any other absolute statement, this one is false.  it's absolutely
reasonable to make implementation-influenced changes to a few places
in the code based on results of some profiling (or judgement).  in
*any* language, since we are very far from inventing the perfect AI.

the fact that the Scheme (and Lisp) philosophy values not having you
thinking about bit bashing *all* *the* *time* is a good thing in my
book.

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

I understand that this is being worked on.

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

I don't understand this, I'm afraid.  if the malloc'ing has nothing to
do with Scheme data structures, why do you think that requires
SCM_{DEFER,ALLOW}_INTS at all?  not to mention that they are
more-or-less noops now.

> * 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 you can't live with conservative stack scanning (yes, it's not
perfect, which is more of the world's fault than Guile's), maybe you'd
prefer precise root registration?  the current thinking is that even
with the warts the current scheme is easier to use.

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

I'm not an expert in this area, sorry.  but it looks like something
that can be fixed -- can you help?

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

this is one case where implementation-conscious coding is perfectly
justified, philosophy or no philosophy.

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

yes, nice thing for the new module system's wishlist.

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

"we" as in "guilers" certainly are.  "we" as in "schemers" are not --
there are several state-of-the-art native compilers out there.

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

amen.

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

hasty decisions don't contribute to a useful and lasting project,
either.  but you have some kind of a point here, I guess.

-- 
Well, I wish you'd just tell me rather than trying to engage my enthusiasm,
because I haven't got one.


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