Re: how smart is compilation?

[Per Bothner <per at bothner dot com>]

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/