I should give you a hard time about arguing from authority ;-), but I was there at the same time and knew KMP, so I wouldn't want to argue too much with him either, and I am in agreement with you about fexprs vs. macros, and the equivalent issues in Julia.
On Friday, July 24, 2015 at 2:31:54 PM UTC-4, Stefan Karpinski wrote: > > Lisp has already been down this path – fexprs > <https://en.wikipedia.org/wiki/Fexpr> were special forms with behavior > similar to R's functions, and they were deprecated in the 1980s in favor of > macros, https://en.wikipedia.org/wiki/Fexpr#Mainstream_use_and_deprecation > : > > His central objection was that, in a Lisp dialect that allows fexprs, >> static analysis cannot determine generally whether an operator represents >> an ordinary function or a fexpr — therefore, static analysis cannot >> determine whether or not the operands will be evaluated. In particular, the >> compiler cannot tell whether a subexpression can be safely optimized, since >> the subexpression might be treated as unevaluated data at run-time. > > > If Lispers think a feature is too dynamic and hard to understand, that's a > danger sign. In general, I wouldn't want to argue too much with Kent Pitman > :-) > > On the subject of Kent Pitman, here's a random bit of Lisp wisdom from this > interview > <http://developers.slashdot.org/story/01/11/03/1726251/kent-m-pitman-answers-on-lisp-and-much-more> > > with him: > > I like Lisp's willingness to represent itself. People often explain this >> as its ability to represent itself, but I think that's wrong. Most >> languages are capable of representing themselves, but they simply don't >> have the will to. Lisp programs are represented by lists and programmers >> are aware of that. It wouldn't matter if it had been arrays. It does matter >> that it's program structure that is represented, and not character syntax, >> but beyond that the choice is pretty arbitrary. It's not important that the >> representation be the Right® choice. It's just important that it be a >> common, agreed-upon choice so that there can be a rich community of >> program-manipulating programs that "do trade" in this common representation. > > > This is probably the best quote about homoiconicity I've read anywhere and > explains why the term is tricky to pin down. > > On Fri, Jul 24, 2015 at 2:21 PM, Brandon Taylor <brandon....@gmail.com > <javascript:>> wrote: > >> Macros seem to have a bunch of limitations. They can't be overloaded to >> take advantage of Julia's typing system. Their functionality can somewhat >> mimic evaluation within a function in its direct parent environment, but >> what if you want to write functions within your macro, or macros inside >> your macro, etc? Probably still possible to do many things, but it would >> invovle passing expressions back in forth in confusing ways, where as with >> environments, as long as an environment is kept attached to every >> expression, they can be immediately evaluated in any sub or subsub etc. >> environment. >> > >
