Re: RFC: major change to argument processing.

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> It eats stack, which is a more finite resource than heap for Guile.

I'd actually wondered why guile seemed to have a fairly conservative
initial stack setting, being used to languages where the stack was
limited mostly by RAM.  However, now that I think about it, recalling
that guile has to do stack-copying for various things, writing code
that does everything on the stack could get really expensive if you
didn't watch it.

I had to bump the guile stack limits for gnucash and g-wrap because
obviously we had people (me included) that were presuming the stack
was conceptually large.

Actually now I'm curious.  When you do something like

  (define (foo xxx)
    (if (null? xxx)
      '()
       (cons 1 (foo (cdr xxx)))

What's actually happening in guile memory/stack-wise?

I know that if you use call/cc, the stack will have to be copied, but
what's happening in general (normal calls), and how do threads affect
things.  (I'm asking because I can see a number of ways to handle the
stack, including on the heap in various ways...)

> More theoretically, it can't be as easily optimized into a real loop.

Hmm.  Just need a really smart compiler :>

More seriously, I'll have to think about this.  If recursion, even
when tail recursive, really is that much more expensive than other
approaches, then I should probably start adjusting my assumptions and
coding practices.

(Actually, just to clarify, you used "let loop" in your approach,
 which I consder a recursion, so do you just mean building results on
 the stack?)

In the long run, if there are things we can to do make recursion
faster/more efficient, then I think they're probably important.
Scheme seems to be often taught with an emphasis on recursion.
i.e. you hear that a do loop is usually just a macro that expands into
a recursion, etc., and things like SICP certainly lean that way too.
And just stylistically, I tend to prefer recursion these days.

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930