On Sat, Mar 13, 2021 at 03:33:23PM +0100, Tomas Hlavaty wrote: > On Sat 13 Mar 2021 at 15:03, Alexander Burger <a...@software-lab.de> wrote: > 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.
I don't get your problem with side effects! Why do you open new issues like like SVG and PDF generation, when the task is to print a page to to a socket? It was a minimal example for didactic purposes in PilCon. So what is the side effect? The printing??? Printing is all we are talking about here. And even besides this simple example, I want output of an HTML server as fast as possible, and the way the PicoLisp server does it is surely optimal. Both from the speed of page generation as also the simplicity of the HTML functions, and the readability of the source code (please show me a source code which generates a report in HTML in a cleaner way than the example of the Sales report in my last mail!). > Cons trees and garbage collection are one of the best things about lisp. Sure. But not an issue here! We want output, not a data structure. > > 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. That's trivial. Just calculate while printing then. > So optimal means writing to a file is cheaper than consing a cell? I am > not convinced. We NEED the output, but we DON'T need the cell. > 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? I already explained that tracing goes to stderr. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
