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:

> Actually, I suggest using values, and compiling with --full-tailcalls. 
>  
> > 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.


> You might consider using BRL's template syntax, using square brackets: 
>  
> some text [(+ 5 1)] which has [(begin '(1 2 3 4 5))] some expressions 
>  
>  
> Either way, this could become: 
>  
>      (values "some text " (+ 5 1) " which has " (begin '(1 2 3 4 5)) 
>               " some expressions") 

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
   (a bit of a long shot I know).

2. I just prefer this syntax

At the end of the day this is the least important part of any template
system, I can easily plug BRL syntax in later, or provide a choice
between the two.

Incidentally you don't need the begin form with BRL's syntax. For
example:

   some text ['(0 1 2 3 4 5)] more text

is transformed to:

   (values "some text " '(0 1 2 3 4 5) "more text")

> > If I compile this to a module would it always be the case that all the 
> > procedures (ie: all those wrapped expressions) would get compiled to 
> > separate classes? 
>  
> No, they should only be separate classes if they require a closure 
> environment.  You can avoid this if you specify --module-static. 

Ok... but if one of the lambda's returned a proc then it would be
compiled to a separate class?


> I'm not sure I'm understanding what you're getting at, but my 
> preferene is always going to be compilation.  Using eval is something 
> I try to discourage. 

I'll try to explain what I mean.

A template is a source language that gets converted to another source
language (scheme). How the resulting source language is then executed
is the decision I have to make.

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.

The second option is attractive because it won't cause the non-scheme
chunks to be parsed more than once. Consider converting a large file
with only one scheme expression. With the "make a scheme program"
method the text chunks have to be read in and then spat out as part of
a scheme program, they then have to be read in again by the scheme
compiler.

By using the second option one can read in the text strings and put
them directly into the execution Environment of the page.

The other attractive thing about the second option is that you don't
have to manage the creation of the class files.

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?


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. But being able to
do that is a long way off anyway, so why bother?


Nic


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