This is the mail archive of the kawa@sources.redhat.com 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: how smart is compilation?


Per Bothner <per@bothner.com> writes:

> > 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. 

I should be able to because that is the attribute. What I'm trying to
do is define a 'server side scheme expression' attribute (a bit like
the javascript attribute that the netscape browser supported).


> 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.  

That's the trouble though. Learning the internals of kawa.

What I'm doing here is mainly a hack for myself, this template engine
is a distillation of all the things I want from template engines that
none of them do. As such it's kinda of a hobbyist project (thoguh I
will use it for real applications) and I can improve it as I go.

At some point I hope to learn about kawa internals (I had a mind to
write an AWK processor with kawa) and then I may do as you suggest.
 
> > 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. 

That's what I'll do for now then. I'll cause each expression to be
wrapped in a no-arg lambda. I think I have to hack together an eval
that will take a Pair rather than a string... having said that
expressions probably won't be that long so I could write the Pair to a
string and eval that.


> > 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. 

I've found that many template languages that rely on compilation turn
out to have management problems (with the compiled files). Just
relying on eval but doing it as quick as possible might be better,
it's worth trying.


Nic


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