This is the mail archive of the guile@cygnus.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: finite state machines in guile



> What is wrong is that scheme is defined as a properly tail recursive
> language and that most C compilers will not optimize tail
> recursion. (Some will, but that isn't the point.)

Explain exactly what ``properly tail recursive language'' means.
It most definitely is not true that every call or recursion in scheme can
be optimised to a jump -- only those that are in the correct tail position
will optimise. Similarly, some calls and recursions in C can be
optimised to jumps and others can't -- of those that can, some compilers
optimise some of them.

> Your scheme compiler should turn tail recursion into a loop, not rely
> on the target language to be smarter.

This is exactly what I disagree with!

My principles say that you shouldn't do something wrong yourself in an
attempt to compensate for someone else doing the wrong thing -- you should
do the right thing and encourage other folks to do so too.

I feel that Hobbit's job is to translate nicely expressed scheme code
into nicely expressed C code. If a tail call in scheme is optimisable
to a jump then Hobbit should try to find an equivalent C tail call that
is also optimisable to a jump -- because that is basically the nicest
way to express the equivalent concept in the C language.

Whether the C compiler picks up all available optimisations is quite a
separate issue but as far as RESPONSIBILITY goes, Hobbit should try to
overlap the C compiler as little as possible.

Since we are in the convenient position of having the egcs team who are
actively interested in pursuing the optimisation issue, a little cooperation
would result in both languages improving and a benefit to everyone.

One further point is that Hobbit's output should be as readable as possible
and trying to build optimisations into the C code is guaranteed to produce
unreadable code. Yes, you should give the C compiler every chance by setting
things up in a way that encourages optimisation but no you shouldn't make
a messy hack.

	- Tel