Hi Tomas,

> > to keep in mind that in typical PicoLisp code, almost *everything* runs
> > in a FEXPR. Take a simple HTML form like
> >
> > Without FEXPRS, this example would look like
> >
> >    (action
> >       '(html 0 "Form" "@lib.css" NIL
> >          '(<h2> NIL "Title")
> >          '(<div> 'cls
> >             '(form NIL
> >                '(gui '(+TextField) 10 "Text")
> >                '(gui '(+NumField) 10 "Number")
> >                '(gui '(+Button) "Action"
> >                   ''(doSomething) ) ) ) ) )
> Not necessarily, you could use macros if you didn't want to write the
> quotes.

Really? I don't think I would want to do that.

How much overhead would this involve? The above expression (without the
added quotes) has a size of 41 cells. Now look at the called functions
and their current sizes

   html   79 cells
   <h2>   11 cells
   <div>  11 cells
   form  150 cells

Does this mean that the above expression would expand to about 292
cells? Building such huge structures, just to execute them and then
throw them away? Expanding those macros would take much longer than the
direct functional execution (not to talk about compilation).

> An example, the following 'off' works exactly like in PicoLisp,
> i.e. removes the need for quoting:
> (defmacro off (&rest vars)
>   `(setq ,@(loop for x in vars appending `(,x nil))))

Besides for the overhead of expanding this every time 'off' appears in
the code, compare that to a clean FEXPR definition:

   (de off Lst
      (mapc set Lst) )

This confirms what I said in my last mail, that in CL things usually
looks bigger and uglier ;-)

> > Macros make only sense if you compile the code
> Yes.  On the other hand, fexprs only make sense if you don't compile the
> code:-)

True. Again, same as I said in my last mail: The compiler imposes so
many restrictions upon Common Lisp, and makes it such a heavy and
inflexible dinosaur.

- Alex
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to