Some further findings,
The whole macro-expansion to tree-il in psyntax is not done in a tail call manner which limits the sizes
of code tree's that we can compile. Although it would be interesting to know how to code the
psyntax expand algorithm in such a way that we don't risk blowing the stack, I think we
will be better served by waiting for better stack algorithm that implement growing stacks.
For the second bug above, it's not a bug, it's my-cond syntax not being recognized and it tries
to tail-call 2000+ argument function which is not supported in guile :-)
In view of this I suggest that we close this bug or perhaps add a feature request for growing stacks.
An alternate feature request is to have some way to tell guile the size of the stack at start up.
For now anyone that need to compile large functions the only option, I believe, is to change the stack size in the code
and recompile.
WDYT
/Stefan
Some findings!
1. The problems probably originates in the translation to tree-il.
2. Using something like
(define-syntax my-cond
(syntax-rule ()
((_ (p x ...) ) (if p (begin x ...)))
((_ (p x ...) . l) (if p (begin x ...) (my-cond . l))))
Makes the compilation to progress further but fails at a later with,
scheme@(guile-user)> (compile program #:to 'value)
language/assembly/compile-bytecode.scm:150:39: In procedure #<procedure 2be2a20 at language/assembly/compile-bytecode.scm:150:27 (x)>:
language/assembly/compile-bytecode.scm:150:39: In procedure bytevector-u8-set!: Value out of range: 2070
I quick look at the cond clause in boot.scm does not show any evidence that it will blow the stack. In my view the
suspect is any code in psyntax.scm that does a tree walk of the finished code the cond clause is a really deep tree!
because that cond clause produces a already expanded large codeblock that psyntax has to chew on while the my-cond
clause above produces the tree-il incrementally in smaller steps.
/Stefan
On Wed, Dec 5, 2012 at 5:31 PM, <rixed@happyleptic.org> wrote:This program tries to compile a long cond expression and fails quickly with
a stack overflow.
Of course this procedure was generated and a user is unlikely to write such a
long cond, but considering the simplicity of the expression I'm surprised that
the stack is so solicited.
Note that I tested with guile 2.0.6 and not the fresh new 2.0.7 but I haven't
noticed anything in the changelog regarding memory consumption.