This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Shell-style programming in Kawa


On Feb 18, 2014, at 12:27 AM, Per Bothner <per@bothner.com> wrote:

> On 02/13/2014 07:34 PM, Jamison Hope wrote:
>> It turns out that it works if I compile my Scheme file with
>> --module-static-run, but not otherwise.  In particular, not if I
>> compile --module-static, not if I just load the source file, not
>> if I try to run it as "kawa file.scm" or "kawa -f file.scm", and
>> not if I make it an executable shebang script.
> 
> It should work now - at least I tested using --module-static.

Yup, that did it.  If I change the validate-apply: value from
a "class:method" string to the function identifier, then it works
via load, kawa -f, and kawa --script, too.  Nice.

[I mean like this:

(define-procedure myproc
  validate-apply: myValidateApplyFunction
  ...)

instead of

(define-procedure myproc
  validate-apply: "package.some_module:myValidateApplyFunction"
  ...)

since the latter only works if the class loader can find a class
called package.some_module.]

> The issue turns out to be whether the GenericProc field (the
> "answer" in your test-case) is final or not.  If it is final,
> then we know its value, and can call validateApply.
> 
> Under --module-static-run the field can be final, because it
> is initialized in <clinit>; under --module-static the field
> is non-final, because it is initialized in 'run'.
> 
> In the case of the GenericProc object, we don't modify the
> field (it is constant), and there are no side-effects (except
> memory allocation), so there is no reason not to initialize
> the field in <clinit>.  We can do this as long as Declaration's
> shouldEarlyInit() returns true.   Ideally we want something
> like ... || isCompiletimeConstant || simpleSideEffectFreeInit().
> But adding a test for simpleSideEffectFreeInit() may be a bit
> tricky - though it might be useful for other optimizations.
> 
> Instead, it seemed simpler to set the EARLY_INIT flag.  This
> is specifically meant to cause initialization in the constructor.
> So I added a new form 'define-early-constant', which is similar
> to 'define-constant', but also sets the EARLY_INIT flag.

I guess that makes sense.  It's a little strange to think about
non-final constants, though.  Using regular define-constant with
a value that's a self-evaluating literal such as

(define-constant *NUM-AXES* ::int 7)

would get initialized in <clinit> since isCompileTimeConstant()
is true, right?

Thanks!

--
Jamison Hope
The PTR Group
www.theptrgroup.com




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]