6 ms·

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.