On Sat, Mar 13, 2021 at 02:09:30PM +0100, Tomas Hlavaty wrote:
> Avoiding allocations is wrong thing to do for this use-case. Printing
> directly is severely inconvenient. Do you have a neat solution to the
> svg viewBox problem I wrote about?
You are talking about a different problem domain. Width calculations were not an
issue in that discussion.
If you want output with a pre-calculated width, you can still do it in the
FEXPR. No need to build a separate "tree", the FEXPR body *is* one already.
But if you insist, just switch function pointers to do width calculation instead
of printing. Given our example
(de <p> Prg
(prin "<p>")
(run Prg)
(prin "</p>") )
(de <div> (Col . Prg)
(prin "<div class=\"" Col "\">")
(run Prg)
(prin "</div>") )
we add a width-calculating function for each tag:
(de pWidth Prg
(+ 3 (run Prg) 4) )
(de divWidth (Col . Prg)
(+ 12 (length Col) 2 (run Prg) 6) )
For demonstration, say we want first print the width to stderr, and then the
HTML to the current stream
(de printWidthAndPrint Prg
(let (<p> pWidth <div> divWidth prin length)
(msg (run Prg)) )
(run Prg) )
Test:
(printWidthAndPrint
(<div> "red" (<p> (prin "Text"))) )
Output:
34
<div class="red"><p>Text</p></div>
Note that this again does not produce a single cell. Optimal.
> > Also, needing two separate functions for every HTML function is ugly,
> > tedious
> > and error-prone.
>
> Not sure what do you mean.
I meant '<p>' and 'p' in your example.
> > 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).
>
> You can trace it but the trace does not show the side-effect thus making
> trace useless.
I do not understand. We are talking about the 'trace' of function calls for
debugging, showing whe called function, and its arguments, then recursively
indented the trace of sub-function calls, and then the return of the function
and its value, right? Works fine with FEXPRs.
'trace' prints to stderr, so it does not interfer with other printing.
> >> Using FEXPRs for html output is misoptimisation.
> >
> > Wrong.
>
> In reality it is misoptimisation because it optimizes for irrelevant
> advantage of no allocation but it severely criples what one can do.
No. It cripples nothing. It is the most powerful concept. You can express
anything with it.
You can see this from the fact that *all* primitives in the PicoLisp interpreter
itself are FEXPRs (FSUBRs to be exact).
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
