Re: deductive databases

Christopher Browne wrote:
>> The normal alternative to recursion is merely to hide it by the use
of
> a stack. (FORTRAN folk know this well, as FORTRAN was very
> recursion-unfriendly until quite recently.)
>

Yes I mentioned that in connection w/ leftmost tree traversal. I certainly didn't use a stack to hide the recursion- the stack was my first choice. Or maybe I looked it up in a book.

> And while recursion is an abstraction that can cause confusion to
> those new to it, the ways of hiding it tends to lead to code that is
> more opaque than straightforward recursion would have been.

I have seen recursive algorithms that certainly left ME tangled up; I can't remember what they were but they were the A->B;C->A;B->C;D->C; A->D type of thing. I have a feeling that people sometimes try to do everything by the most compact recursion possible and end up with monstrously difficult programs (where by 'program' I mean the main routine and all subroutines). In the world of commercial programming that I inhabit code readability and maintainability and understandability count for more than recursive compactness. I hesitate actually to call it elegance, which was my first choice, because the kind of thing I sketched out above is not really elegant, is it?

Would it be fair to say that recursion uses the subroutine call arguments to replace stack entries? If so, I would prefer the stack as a kind of universally available (let's just say for now) state-descriptor, rather than carrying the info around in my routine-travel-bag. Although if there is a text floating around somewhere that goes into more detail about recursion vs. non-recursion, I would appreciate knowing about it. Always willing to turn the page.

There of course are arguments about whether recursion is more expensive of computer time than non-recursion - I won't weigh in on that argument

Thanks.

Ken Received on Sun May 15 2005 - 02:12:26 CEST