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] |
>>>>> "L" == Lauri Alanko <lealanko@cc.helsinki.fi> writes: L> On Fri, 2 Oct 1998, Tel wrote: L> Actually, reading the C9X draft more closely (as I don't have C89 L> handy), it almost looks like tail-call optimization of most L> functions is forbidden [5.1.2.3:§5, 6.1.2.4:§6], though of course L> an implementation can break these if it can guarantee it does not L> affect the semantics of the program.. If it's allowed to break them, it isn't forbidden... In any case, 5.1.2.3 is the same as the C89 standard... 6.1.2.4 doesn't exist in the final committee draft, so I don't know what it's referring to. 5.1.2.3 says: An instance of each object with automatic storage duration is associated with each entry into its block. Such an object exists and retains its last-stored value during the execution of the block and while the block is suspended (by a call of a function or receipt of a signal). Now, I don't believe this prohibits tail recursion in most cases. Specifically, I don't think it prevents tailcall optimization in the cases that scheme requires it. Only if called functions require access to local variables in the calling function would it be prohibited. For example, if you passed the address of a local variable, you couldn't optimize it, because that variable has to exist through the duration of the tail call. However, if that's not the case, you could close out the stack of the calling process and replace it with your call, because it would still work as if the variables were still there. Since that section of the standard hasn't changed and we havew some compilers which implement tail-call optimization in some cases, I think it's ok. -- Alan Shutko <ats@acm.org> - By consent of the corrupted It's difficult to see the picture when you are inside the frame.