Re: srfi-1 on long lists?

[Marco VEZZOLI <marco dot vezzoli at st dot com>]

Chris Dean wrote:
> 
> Should I expect to get a stack overflow from srfi-1 functions when
> dealing with long lists?  For example, here's list-copy:
> 
> #|kawa:168|# (length (list-copy (make-list 100000 'a)))
> java.lang.StackOverflowError
>         at gnu.expr.ModuleBody.applyN(ModuleBody.java:171)
>         at gnu.expr.ModuleMethod.applyN(ModuleMethod.java:106)
>         at gnu.expr.ModuleMethod.applyV(ModuleMethod.java:134)
>         at gnu.expr.GenericProc.applyN(GenericProc.java:70)
>         at gnu.mapping.ProcedureN.apply1(ProcedureN.java:31)
>         at gnu.kawa.slib.srfi1.lambda2recur(srfi1.scm:273)
>         at gnu.kawa.slib.srfi1.lambda2recur(srfi1.scm:273)
>         at gnu.kawa.slib.srfi1.lambda2recur(srfi1.scm:273)
>         ...
> 
> Regards,
> Chris Dean

from the implementation:

;;; A note on recursion and iteration/reversal:
;;; Many iterative list-processing algorithms naturally compute the
elements
;;; of the answer list in the wrong order (left-to-right or
head-to-tail) from
;;; the order needed to cons them into the proper answer (right-to-left,
or
;;; tail-then-head). One style or idiom of programming these algorithms,
then,
;;; loops, consing up the elements in reverse order, then destructively 
;;; reverses the list at the end of the loop. I do not do this. The
natural
;;; and efficient way to code these algorithms is recursively. This
trades off
;;; intermediate temporary list structure for intermediate temporary
stack
;;; structure. In a stack-based system, this improves cache locality and
;;; lightens the load on the GC system. Don't stand on your head to
iterate!
;;; Recurse, where natural. Multiple-value returns make this even more
;;; convenient, when the recursion/iteration has multiple state values.

Maybe we could do a better job by implementing some code in Java?
-- 
Marco Vezzoli	   tel. +39 039 603 6852
STMicroelectronics fax. +39 039 603 5055