Re: macro functionality in embedded languages.

On Apr 6, 3:32 am, hjst...@xxxxxxxxx wrote:


One advantage of the macro style is efficiency - the call expands at
compile time and can be compiled with full optimization. The macro
can be written in such a way that it expands to reasonably efficient
code. In the function version, the data is parsed at run time.

Yes. HTOUT does that, and in the most recent (I hesitate to call it
current, as it's something like 4 years since it changed) it makes
quite serious attempts to optimize things, to the extent that for
compile-time-constant HTML it will generate a single constant string
at compile time which then just gets printed at runtime. It can also
do this pretty efficiently with semi-constant HTML, getting in most
cases quite close to the best case. Other tools can do this too, I'm
sure.

One huge advantage of the macro style, as Rob points out is that:

(let ((x ...))
(with-html-output (s)
(:html ...
(dotimes (i x)
(htm (:li (fmt "~R" i)))) ... )))

works. That's a huge win for programmatic HTML generation.

For example, if one were to read
an html specification from a file, or generate one on the fly from
data, as in:

(setq doc (generate-dynamic-html ...))


DTML, which is a system based on HTOUT, essentially does this, reading
from a file (typically). It uses HTOUT's printing support (note HTOUT
also uses this to generate its constant strings as well as at
runtime), but its own parser and walker (DTML's syntax is a sort of
pointy-bracket version of sexps - <header :level 3|text of header
<bold|with some boldface>>). All it does is to build a big data
structure from the file and walk it. DTML has its own macro
definition facility, these macros being expanded by the walker, and
those macros end up as little Lisp functions, which it compiles on the
fly. This takes basically no time (compared to the I/O cost of
reading the file) although it does do some probably-unneeded
optimisation such that macros only get recompiled when it knows they
might have changed. Typically the macros call Lisp functions which
then do a lot of backquote-based rewriting of the parsed DTML they get
passed.

Previous to DTML I briefly used something which was file-based but
used sexps. It used READ and then HTOUT's printing support, but I
forget the details. I probably still have the code.

--tim

.

Relevant Pages

  • Re: modifying array access syntax
    ... I published recent speculation on the ARRAY ... > are in fact remnants of the property lists of these Lisp-N ... these that were meaningful at compile time (FEXPR, FSUBR, and MACRO ...
    (comp.lang.lisp)
  • Re: porting from Ikarus to PLT
    ... The fact that helper functions have to be defined in a separate module ... If it encounters a macro use, it expands the macro, ... module and making it available at compile time. ...
    (comp.lang.scheme)
  • Re: Understanding Macro DOLIST
    ... >> I also do not understand what eval does when it encounters this macro. ... > It expands the macro, ... > (ELEMENT NIL)) ... I compile the and it compiles and loads with no errors. ...
    (comp.lang.lisp)
  • Re: Please review macro
    ... >>compile time about into what code the particular macro invocation should ... Mind you, at the repl I guess you get both ... dramatic results unless you compile the macro first. ...
    (comp.lang.lisp)
  • Re: Question about compilation/evaluation environments
    ... compile time." ... "If a defmacro form appears as a top level form, ... store the macro definition at compile time, ... the macro later on in the file can be expanded correctly. ...
    (comp.lang.lisp)