4 ms·

Alan Kay on Lisp and Fexprs

41 points by fogus 17y ago

mortenjorck 17y ago
"take the hardest and most profound thing you need to do, make it great, an then build every easier thing out of it." Indeed.
wingo 17y ago
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.)
jjs 17y ago
Interesting... Fexprs appear to be runtime-only first-class macros.
- gwern 17y ago
  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 17y ago
    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 17y ago
      ...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 17y ago
        [...] but without the distracting complexity of referential transparency? How could referential transparency possibly be distracting or complex?
        camccann 17y ago
        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 17y ago
        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.
    - barrkel 17y ago
      In this way, they are similar to C#'s expression trees, whereby lambdas passed as an argument where the parameter is of type Expression<T> receive an expression tree describing the lambda, rather than an actual callable object.
      - doty 17y ago
        Although C# has rules about variable capture and partial-evaluation that do not necessarily apply to fexprs.
JadeNB 17y ago
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 http://www.ccs.neu.edu/home/wand/pubs.html#Wand98). See http://lambda-the-ultimate.org/node/3640 http://lambda-the-ultimate.org/node/3640 for more discussion and a modern approach (http://web.cs.wpi.edu/~jshutt/kernel.html http://web.cs.wpi.edu/~jshutt/kernel.html) to retaining the appeal of fexprs while avoiding this drawback.
- doty 17y ago
  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.
- KazimirMajorinc 17y ago
  I think Wand's result is straw man if used against fexprs - and Wand really didn't used it that way. Essentially, he says, with fexprs, there is no source => source transformation that can work in all contexts. Ok - but I am not interested in such transformations. Very few programmers are. Whole practical point of these transformations are that they can help to implementers to implement optimizing compilers. But - if one wants source -> source transformation that works in ALL contexts, whatever the reason, he can limit his own use of fexprs - and hence, allow various degrees of such source transformations. For example, he can use fexprs under same limitation macros are used, and in that case, fexprs can be "compiled away" just like macros can. But - he can do it on his own, in some or all of his projects, or even only in some parts of the projects. There is no need to make collective decisions of that kind. Again, it is consistent with idea of Lisp, in which borderline between language designer and programmer is blurred, or at least, it was imagined that way initially. Shutt has interesting and novel approach, and his approach is independent of the severity of overshadowing of the variables problem he addressed. And how severe is that problem? Not really. It is actually the same problem that exists with macros, and techniques used in CL or Scheme (gensyms, hygiene) for macros can work as well with fexprs.
akkartik 17y ago
Oddly enough I cited that exact quote a few weeks ago on the arc forum: http://arclanguage.org/item?id=11185 http://arclanguage.org/item?id=11185

41 points by fogus 17y ago

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

wingo 17y ago

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.)

jjs 17y ago

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

gwern 17y ago
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 17y ago
  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 17y ago
    ...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 17y ago
      [...] but without the distracting complexity of referential transparency? How could referential transparency possibly be distracting or complex?
      - camccann 17y ago
        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 17y ago
        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.
  - barrkel 17y ago
    In this way, they are similar to C#'s expression trees, whereby lambdas passed as an argument where the parameter is of type Expression<T> receive an expression tree describing the lambda, rather than an actual callable object.
    - doty 17y ago
      Although C# has rules about variable capture and partial-evaluation that do not necessarily apply to fexprs.

JadeNB 17y ago

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 http://www.ccs.neu.edu/home/wand/pubs.html#Wand98). See http://lambda-the-ultimate.org/node/3640 http://lambda-the-ultimate.org/node/3640 for more discussion and a modern approach (http://web.cs.wpi.edu/~jshutt/kernel.html http://web.cs.wpi.edu/~jshutt/kernel.html) to retaining the appeal of fexprs while avoiding this drawback.

doty 17y ago
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.
KazimirMajorinc 17y ago
I think Wand's result is straw man if used against fexprs - and Wand really didn't used it that way. Essentially, he says, with fexprs, there is no source => source transformation that can work in all contexts. Ok - but I am not interested in such transformations. Very few programmers are. Whole practical point of these transformations are that they can help to implementers to implement optimizing compilers. But - if one wants source -> source transformation that works in ALL contexts, whatever the reason, he can limit his own use of fexprs - and hence, allow various degrees of such source transformations. For example, he can use fexprs under same limitation macros are used, and in that case, fexprs can be "compiled away" just like macros can. But - he can do it on his own, in some or all of his projects, or even only in some parts of the projects. There is no need to make collective decisions of that kind. Again, it is consistent with idea of Lisp, in which borderline between language designer and programmer is blurred, or at least, it was imagined that way initially. Shutt has interesting and novel approach, and his approach is independent of the severity of overshadowing of the variables problem he addressed. And how severe is that problem? Not really. It is actually the same problem that exists with macros, and techniques used in CL or Scheme (gensyms, hygiene) for macros can work as well with fexprs.

akkartik 17y ago

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