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