Hi Tomas,
> > While this would surely work, I answered that it is a big overhead to
> > generate the whole page as strings just to print them.
>
> Packing strings is not a good idea.
Right.
> It would be much better to create a cons tree instead, something like:
>
> (de <p> (Str) `(p ,Str))
>
> and have a separate function to print the cons tree into a stream
> formatted as html. Notice how little memory such <p> function allocates
> -- 2 cons cells -- compared to the version with pack.
>
> Unfortunatelly, picolisp does not have a convenient way of creating cons
> tree templates with backquote.
It does. Just the syntax is different:
(de <p> (@Str) (fill '(p @Str)))
This also creates just 2 cells.
But the FEXPR solution explained at PilCon allocates no new cells at all. It
prints directly.
Also, needing two separate functions for every HTML function is ugly, tedious
and error-prone.
> > But I forgot to explain: The real reason for FEXPRs goes beyond that. They
> > have
> > the power of passing executable code bodies, with arbitrary flow control,
> > to the
> > function.
>
> This also nicely shows how the power of FEXPRs can easily lead one
> astray.
Right. FEXPRs are dangerous when used the wrong way.
This was what the last PilCon was all about ("hazards"). But I explained also
how these hazards disappear when you follow 2 or 3 simple rules in writing
libraries.
> Another drawback is that side-effects break tracing and make debugging
> much harder.
Side-effects like printing? No problem! In PicoLisp, you can trace, break and
single-step FEXPRs (with or without side-effects) like any other function
(unlike macros in e.g. Common Lisp).
> Using FEXPRs for html output is misoptimisation.
Wrong.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
