On Sat 13 Mar 2021 at 08:27, Alexander Burger <a...@software-lab.de> wrote:
> (de <p> Prg
> (prin "<p>")
> (run Prg)
> (prin "</p>") )
>
> [...]
>
> One question that came up was why FEXPRs could not be replaced with normal
> functions (EXPRs), simply 'pack'ing strings:
>
> (de <p> (Str)
> (pack "<p>" Str "</p>") )
>
> [...]
>
> 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.
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.
> 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.
For example:
(let (*X NIL *Y NIL)
(draw-svg-thing-and-determine-width-and-height)
`(svg (@viewBox "0 0 " ,*W " " ,*H) ...))
The above will not work when <p> is not pure and does side-effect write.
One has to draw it twice, once to /dev/null to determine width and
height and then second time inside the three dots.
When draw-svg-thing-and-determine-width-and-height is pure and returns
cons tree, it does not need to be called second time but the return
value can be used inside the three dots. If consing and garbage
collecting a cons tree is cheaper than calling
draw-svg-thing-and-determine-width-and-height once again, it is already
a win.
Another drawback is that side-effects break tracing and make debugging
much harder.
Using FEXPRs for html output is misoptimisation.
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
