This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: StackOverflowError in defmacro
- From: Per Bothner <per at bothner dot com>
- To: Chris Dean <ctdean at sokitomi dot com>
- Cc: Kawa List <kawa at sources dot redhat dot com>
- Date: Tue, 04 May 2004 23:10:38 -0700
- Subject: Re: StackOverflowError in defmacro
- References: <12223.1083707549@mercedsystems.com>
Chris Dean wrote:
at gnu.expr.ModuleBody.apply1(ModuleBody.java:127)
at com.merced.util.scheme.TestFramework.apply1(com/merced/util/scheme/TestFramework.scm)
at gnu.expr.ModuleBody.applyN(ModuleBody.java:171)
at com.merced.util.scheme.TestFramework.applyN(com/merced/util/scheme/TestFramework.scm)
at gnu.expr.ModuleBody.apply1(ModuleBody.java:127)
Not sure how this is going wrong - and it's been a while since I've
looked at this code, but here is some background:
If a procedure takes a single argument, then it will be compiled to a
single-argument method, and Kawa will generate an apply method that
calls that method. On the other hand, if the procedure takes a variable
number of arguments, Kawa will generate a method (with a $V suffix) that
takes an Object[] or list paremeter, as well as an applyN method that
calls that method.
A Procedure can be called either way, without the caller knowing
whether it is implemented using apply1 or applyN. If the the call uses
apply1 (most common in compiled code) and if the Procedure
implementation was unary, then we directly get the implementation's
apply1 method; if the caller uses applyN to call an applyN function,
again no problem. However, if caller uses applyN to call a function
implemented using apply1, then we need glue code to extract the argument
from the incoming array and then call apply1. Similarly, if the caller
uses apply1 to call a function implemented using applyN, then we need
glue code to wrap the argument in a one-element array so we can call the
applyN.
The problem is we're getting into an infinite recursion of glue code,
without actually calling a real function. The complication is that the
glue code is partly in the ModuleMethod class, partly in the ModuleBody
abstract class, and partly in the application TestFramework class, which
extends ModuleBody. ModuleBody has glue code that converts both ways,
which means you can't say "override applyN (and then apply1 is
implemented in terms of applyN)" or "override apply1 (and then applyN is
implemented in terms of apply1). Kawa allows either - but it's not
supposed to get confused like this - but it is!
--
--Per Bothner
per@bothner.com http://per.bothner.com/