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



On Fri, 2 Oct 1998, Tel wrote:

> > And this is of course just another point to prove that C can't be used
> > well as a portable assembler.. :(
> 
> The point of this comment is completely lost on me. Your purpose when
> compiling a program is to produce binary code that has the same behaviour as
> you have described with your C code. You have no business trying to
> specify to the compiler exactly where you want each jump -- so long as
> the behaviour is guaranteed consistent.

But it isn't! Simply enough: a scheme implementation is required, and thus
guaranteed, to be properly tail-recursive. A C implementation has no such
guarantee, so a straightforward translation of a scheme function call to a
C function call combined with an ordinary C implementation does not
constitute an R5RS compliant scheme implementation.

Actually, reading the C9X draft more closely (as I don't have C89 handy),
it almost looks like tail-call optimization of most functions is forbidden
[5.1.2.3:§5, 6.1.2.4:§6], though of course an implementation can break
these if it can guarantee it does not affect the semantics of the
program..

Of course one could rely, on, say, a future egcs extension that was
properly tail recursive, but then it wouldn't be compilation to _C_ any
more, FWIW...

(Of course, if a hypothetical translator was to rely on egcs, wouldn't it
be logical to take it all the way: make a scheme front-end for it?)


Lauri