On Sat 13 Mar 2021 at 15:03, Alexander Burger <a...@software-lab.de> wrote: > 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.
I am talking about an example which shows how inconvenient the standard picolisp your solution with side-effect is. Yet another example, writing out pdf. https://logand.com/sw/emacs-pdf/file/emacs-pdf.el.html#l110 creates cons tree and implements insert-pdf function to serialize it in the right format. One of the issues here are pdf object references, which need to output "before" being known, making side-effect solution unuseable. Cons trees and garbage collection are one of the best things about lisp. Trading allocations for side-effects is a bad trade off. > If you want output with a pre-calculated width, you can still do it in the > FEXPR. Not pre-calculated. The bounding box is known after the thing is drawn. > 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) ) Why separate and duplicate functions. What if the drawing is not so trivial? This is not a good solution. Generally, I want to update *W and *H during arbitrarily complex drawing without all those extra functions you suggest. > Note that this again does not produce a single cell. Optimal. So optimal means writing to a file is cheaper than consing a cell? I am not convinced. > 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. If my code outputs html to /tmp/a.html and I trace it, where would the arguments and return values be written to? Where would the side-effect be written to? >> 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. I am not disputing that FEXPRs are the most powerful concept. I am saying that using it for html output is using wrong tool for the job. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
