
Alan Kay on Lisp and Fexprs - fogus
http://kazimirmajorinc.blogspot.com/2010/02/alan-kay-on-fexprs.html
======
wingo
As a counterpoint, if you take something hard and profound, and make a turd
out of it, people that avoided the hard problem will probably beat you.

(GNU Guile maintainer speaking. No, we don't have fexprs any more. Yes, we are
finally getting back to the level of other Schemes.)

------
JadeNB
There is an _excellent_ reason not to base your language on fexprs: their
equational theory is trivial
(<http://www.ccs.neu.edu/home/wand/pubs.html#Wand98>). See <http://lambda-the-
ultimate.org/node/3640> for more discussion and a modern approach
(<http://web.cs.wpi.edu/~jshutt/kernel.html>) to retaining the appeal of
fexprs while avoiding this drawback.

~~~
doty
I've already voted it up, and don't want to violate social conventions here,
but consider this comment another vote for the LtU thread mentioned above. A
fantastic and educational argument by people who know what they're talking
about. If you're interested in these sorts of details it's good reading, no
matter what side of the argument you happen to be on.

------
mortenjorck
"take the hardest and most profound thing you need to do, make it great, an
then build every easier thing out of it."

Indeed.

------
akkartik
Oddly enough I cited that exact quote a few weeks ago on the arc forum:
<http://arclanguage.org/item?id=11185>

------
jjs
Interesting...

Fexprs appear to be runtime-only first-class macros.

~~~
gwern
They look to me like lazy functions (eg. in Haskell), but no one else has
mentioned the term laziness, so I must be mistaken in some respect.

~~~
_delirium
There's a similarity in that neither fexprs nor lazy functions evaluate their
arguments up front, but lazy functions will _eventually_ , if they run and
access that argument at all, get an evaluated version of it. Fexprs can get
the actual raw unevaluated argument and poke at it, so if you call (foo (+ 1
2)), _foo_ gets the syntax-tree (+ 1 2) if it's an fexpr, while if it's a
function, lazy or otherwise, it will only ever see the value 3.

~~~
camccann
...so, basically it gives the same ease of understanding program flow that
lazy evaluation offers, but without the distracting complexity of referential
transparency? Okay, then.

~~~
jjs
_[...] but without the distracting complexity of referential transparency?_

How could referential transparency possibly be distracting or complex?

~~~
camccann
In exactly the same way that lazy evaluation makes program flow easy to
follow.

Or perhaps in the same way that the internet makes sarcasm easily recognized,
I suppose...

~~~
jjs
Aha!

So the value of your words depended on evaluating them in a sarcastic context.
This lack of referential transparency made it difficult to reason about them
at compile-time.

