This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: how smart is compilation?
Nic Ferrier wrote:
> Per Bothner <per@bothner.com> writes:
>
>>>eg:
>>> some text &(+ 5 1) which has &(begin '(1 2 3 4 5)) some expressions
>>>
>
> I don't understand why this is better than just returning a list.
Beacuse if you return a list you have to actually build a list.
Depending on how you actually do it,, this may involve quite a
bit of object creation.
Actually, what I should have suggested was the values-append
function. This is what implements the XQuery comma operator that
appends sequences. The values-append function is optimized so
that if it is called in the appropriate context to actual
compound value is created - the sub-values are written directly
to the destination using the Consumer interface.
Compiling values-append is like this: If the result context
is a Consumer, then compile code for each operand, in order,
where each operand is compiled using the same result context.
If compiling with --full-tail-calls, then all tail contexts
(including the main body of a function) are compiled using
passed-in Consumer as the result context.
So you see, using append-values is basically free, while using
list is quite expensive. Especially if you are generating
really large documents this can be very important.
> Yes, I know about BRL. I'm using the &() syntax for two reasons:
>
> 1. it should allow the text to be parsed through any HTML parser
I don't understand this. If you want to source code to be viewable
as valid html, then obviouly you can't use '&' as a prefix character.
> Ok... but if one of the lambda's returned a proc then it would be
> compiled to a separate class?
I don't see what that has to do with anything. The issue is not
return values, but nested procedures that capture outer lexical
variables.
> A template is a source language that gets converted to another source
> language (scheme).
That is of course a perfectly valid thing to do. However, the most
efficient thing to do, and the most "Kawa-like" solution, is to treat
the template as a program written in its own programming language.
Just sub-class the Scheme class, and plug in a different parser.
Then you benefit from all the existing Kawa machinery, including
compilation, load, eval, command-line options, etc. It should also
be the solution with the best performance. It may have a higher
initial threshold in terms of learning more about the internals
of Kawa, but it should be worth it. (If you use BRL syntax, or
some alternative syntax that I like better, then I'd be happy to
include it in the core Kawa distribution.)
> I can either:
>
> - make a string of the resulting scheme and then compile it
> with CompileFiles, if I do this I will probably do it so that the
> resulting module is static (because it doesn't make sense to create an
> instance for a template page).
>
> - compile just the parts of the source language which are scheme code
> and embed references to arrays constructed by the translation of the
> template language -> scheme.
I would do neither. Treating your template langauge as a Scheme dialect
with a funny syntax is I think the best solution.
> As I understand it the evaluator causes complex code to be compiled to
> in memory class files anyway. For example, if I do this:
>
> (eval "(lambda () (lambda (x) (+ 5 x)))")
>
> I get a compiled proc back, yes?
Yes.
> The only reason that one might source translate + compile is so that
> the resulting classes can be ported from one location to another
> without necessarily having the kawa stuff available.
If the template doesn't change often, you might as well pre-compile it,
rather than re-evaluate it (and hence re-parse and re-compile it)
each time you re-start your application.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/