Hi pd, > > > : (de pp P (prin "<p>") (run P) (prin "</p>") (pack "<p>" (run P) > > "</p>") ) > > ... > > This is a bit problematic, because the body in P is executed twice. Not > > only is ... > > (de pp P > > (prin (pack "<p>" (run P) "</p>")) ) > yes, all my examples in my previous email are bad code, just for output > only, trying to offer examples of how things can go weird > They're are not intended to be right implementations, too bad for that ;-)
No no, I did not say that :) I just wanted to show the obvious shortcut. > yes sure, I think the PilCon and this email thread are good examples of an > interesting use of fexprs but even complex and large programs may be > arranged in a way fexpr are not needed, it's a kind of condig style. Right. The point is that FEXPRs allow you to write flow control in a way not possible with EXPRs. > My point is you can do with fexprs everything you do with exprs but the > opposite is not true, fexprs have it own role in lisp. But I prefer to code > in a more functional style working composing functions with inmutable > objects and without side-effects. OK. But please don't mix up the issue with side effects. They have nothing to do with FEXPRs. > It's always a balance between performance and logical beauty (from my point > of view), but performance is not only about computing performarce but also > logic and conceptual performarce and even profiling or debugging > performance. And in most cases you can get both (beauty and performance). ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
