This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Shell-style programming in Kawa
- From: Jamison Hope <jrh at theptrgroup dot com>
- To: "kawa at sourceware dot org list" <kawa at sourceware dot org>
- Date: Tue, 18 Feb 2014 01:32:52 -0500
- Subject: Re: Shell-style programming in Kawa
- Authentication-results: sourceware.org; auth=none
- References: <52C4B518 dot 5080000 at bothner dot com> <A72FB562-9459-4C69-B346-A6C94DBD22C4 at theptrgroup dot com> <52FBC89B dot 6020800 at bothner dot com> <EB5ADD07-B016-4727-9E73-7B23CAA362D3 at theptrgroup dot com> <52FD471C dot 2030305 at bothner dot com> <E0B88450-EA78-4A81-9B2A-A7F9F5A24C0D at theptrgroup dot com> <5302EF2B dot 2030508 at bothner dot com>
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