Tim Bradshaw wrote:
> (2) The version at www.tfeb.org is really old due to some
> screwup on my part - I will replace it with a somewhat more
> modern one. The main difference is that the more recent one
> does a much better job of detecting compile-time constant
> HTML and generating the output at compile time rather than
> run time.
There is an up-to-date version there now. As a side comment, one of
the interesting things about HTOUT, and in particular about the
current version, is that it does a fairly serious job of detecting
compile-time constant (strictly, macroexpansion-time constant) HTML,
and evaluation this during the expansion of the macro. It used to
just have a flag which it used to decide if the whole form was
constant, but it now decides on a fragment-by-fragment-basis, and will
generate reasonably optimal code, including lots of literal strings.
This is the sort of thing that would be hard in an interpreted /
function-based solution. Finally, of course, it uses EVAL to do this,
and I think this is probably an example of an OK use of EVAL in Lisp.
--tim
"Tim Bradshaw" <··········@tfeb.org> schrieb im Newsbeitrag
···············@odak26.prod.google.com...
>
> Tim Bradshaw wrote:
> > (2) The version at www.tfeb.org is really old due to some
> > screwup on my part - I will replace it with a somewhat more
> > modern one. The main difference is that the more recent one
> > does a much better job of detecting compile-time constant
> > HTML and generating the output at compile time rather than
> > run time.
>
> There is an up-to-date version there now. As a side comment, one of
> the interesting things about HTOUT, and in particular about the
> current version, is that it does a fairly serious job of detecting
> compile-time constant (strictly, macroexpansion-time constant) HTML,
> and evaluation this during the expansion of the macro. It used to
> just have a flag which it used to decide if the whole form was
> constant, but it now decides on a fragment-by-fragment-basis, and will
> generate reasonably optimal code, including lots of literal strings.
> This is the sort of thing that would be hard in an interpreted /
> function-based solution. Finally, of course, it uses EVAL to do this,
> and I think this is probably an example of an OK use of EVAL in Lisp.
> --tim
>
Thanks a lot for all your answers. I found the pure functional approach
appealing for its brevity. Now I thinks, that it also has some drawbacks.
The point I am getting nervous about is, that 'my approach' will evaluate
everything at runtime. I think I'll have a closer look on the alternatives
because I think it is nice to have as much as possible evaluated at compile
time.
Thanks Andreas
From: Christophe Turle
Subject: Re: easily embedding html into Lisp
Date:
Message-ID: <cim3e9$t78$1@amma.irisa.fr>
Andreas Thiele wrote:
> "Tim Bradshaw" <··········@tfeb.org> schrieb im Newsbeitrag
> ···············@odak26.prod.google.com...
>
>>Tim Bradshaw wrote:
>>
>>>(2) The version at www.tfeb.org is really old due to some
>>>screwup on my part - I will replace it with a somewhat more
>>>modern one. The main difference is that the more recent one
>>>does a much better job of detecting compile-time constant
>>>HTML and generating the output at compile time rather than
>>>run time.
>>
>>There is an up-to-date version there now. As a side comment, one of
>>the interesting things about HTOUT, and in particular about the
>>current version, is that it does a fairly serious job of detecting
>>compile-time constant (strictly, macroexpansion-time constant) HTML,
>>and evaluation this during the expansion of the macro. It used to
>>just have a flag which it used to decide if the whole form was
>>constant, but it now decides on a fragment-by-fragment-basis, and will
>>generate reasonably optimal code, including lots of literal strings.
>>This is the sort of thing that would be hard in an interpreted /
>>function-based solution. Finally, of course, it uses EVAL to do this,
>>and I think this is probably an example of an OK use of EVAL in Lisp.
>>--tim
>>
>
>
> Thanks a lot for all your answers. I found the pure functional approach
> appealing for its brevity. Now I thinks, that it also has some drawbacks.
> The point I am getting nervous about is, that 'my approach' will evaluate
> everything at runtime. I think I'll have a closer look on the alternatives
> because I think it is nice to have as much as possible evaluated at compile
> time.
>
> Thanks Andreas
>
If you want to keep the functionnal approach thus having compilation optimization, perhaps you should use compiler macros (hyperspec 3.2.2.1)
Christophe Turle.