3 ms·

That sounds a lot like a macro. Is the main difference that macros evaluate at compile time and fexprs evaluate at EVAL time? I imagine a facility like EVAL-WHE

by User23 5y ago

That sounds a lot like a macro. Is the main difference that macros evaluate at compile time and fexprs evaluate at EVAL time? I imagine a facility like EVAL-WHEN[1] can blur the distinction. [1] http://www.lispworks.com/documentation/HyperSpec/Body/s_eval_w.htm http://www.lispworks.com/documentation/HyperSpec/Body/s_eval...

HexDecOctBin 5y ago
The fundamental difference as far as I can see will be removing the distinction between macros and function. For example, (assuming parameters starting with @ are fexprs): (defun if (bool @then @else) (cond (bool (eval @then))) (t (eval @else))))
- Jtsummers 5y ago
  The parameters aren't the fexprs, the function is the fexpr. Even bool will need to be wrapped in an eval.
agumonkey 5y ago
I guess there's no more 'time' because it can happen anytime on any fexpr due to any reason.
dragonwriter 5y ago
> That sounds a lot like a macro Yes, with fexprs, functions can serve as (runtime-evaluated) macros. REBOL used this (though they aren't call fexprs in REBOL) so that its functions could also serve the role of Lisp macros, and it was pretty awesome. It’s too bad that REBOL became such a dead end for nontechnical reasons.
sparkie 5y ago
Macros are also not first-class, whereas fexprs are. Macros and other special forms must appear in their own name when they are called. You can't necessarily bind them to a symbol and then use that symbol in its place with the same behavior. Consider a symbol which could represent some abstract "binary function", which you might later call. You can bind functions like `add` and `mul` to this without trouble, but if you try to bind `and` or `or` to it, you might not be able to (depending on which lisp you are using). You could try to wrap the call to `and` in a function, like `(define (and* x y) (and x y))`, but this `and*` does not actually have the correct behavior, because `y` should not be evaluated if `x` evaluates to `#f` - but being a function, both arguments are evaluated implicitly. If using fexprs, this issue is non-existent. `and` and `or` are simply defined as fexprs, are first-class, and their operands are not implicitly evaluated.

by User23 5y ago

HexDecOctBin 5y ago

The fundamental difference as far as I can see will be removing the distinction between macros and function. For example, (assuming parameters starting with @ are fexprs): (defun if (bool @then @else) (cond (bool (eval @then))) (t (eval @else))))

Jtsummers 5y ago
The parameters aren't the fexprs, the function is the fexpr. Even bool will need to be wrapped in an eval.

agumonkey 5y ago

I guess there's no more 'time' because it can happen anytime on any fexpr due to any reason.

dragonwriter 5y ago

> That sounds a lot like a macro Yes, with fexprs, functions can serve as (runtime-evaluated) macros. REBOL used this (though they aren't call fexprs in REBOL) so that its functions could also serve the role of Lisp macros, and it was pretty awesome. It’s too bad that REBOL became such a dead end for nontechnical reasons.

sparkie 5y ago

Macros are also not first-class, whereas fexprs are. Macros and other special forms must appear in their own name when they are called. You can't necessarily bind them to a symbol and then use that symbol in its place with the same behavior. Consider a symbol which could represent some abstract "binary function", which you might later call. You can bind functions like `add` and `mul` to this without trouble, but if you try to bind `and` or `or` to it, you might not be able to (depending on which lisp you are using). You could try to wrap the call to `and` in a function, like `(define (and* x y) (and x y))`, but this `and*` does not actually have the correct behavior, because `y` should not be evaluated if `x` evaluates to `#f` - but being a function, both arguments are evaluated implicitly. If using fexprs, this issue is non-existent. `and` and `or` are simply defined as fexprs, are first-class, and their operands are not implicitly evaluated.