Hi Tomas, > I am inclined to think that fexprs are not a good thing, because like > first class continuations, they break compose-ability (or whatever is > the english word for that).
FEXPRs a not so very important. They just allow you to avoid having to quote everything. I don't understand all the fuss that is made about them. It is perhaps because they are more powerful than the holy macros. > That brings the question of how much of PicoLisp really needs fexprs? I > think I could implement most of PicoLisp in Common Lisp rather easily > using functions and macros without the need for fexprs at all. Even in > case of PicoLisp, most of the things are actually not fexprs. It's just > that everything is implemented using FEXPRs under the hood in PicoLisp. Right. As I said above, they are mainly a cosmetic issue. But you have to keep in mind that in typical PicoLisp code, almost *everything* runs in a FEXPR. Take a simple HTML form 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) ) ) ) ) ) All functions execpt 'gui' and 'doSomething' are FEXPRs here. 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 so much difference, but tedious and error-prone. Macros make only sense if you compile the code, and the execute it many times. This discourages such single-pass code like in the example above. Cheers, - Alex -- UNSUBSCRIBE: mailto:firstname.lastname@example.org?subject=Unsubscribe