7 ms·

Lisp macros (and earlier FEXPRs) predate Zig by 53 years!

socialdemocrat 4y ago
That isn’t a C-like language. Doing it in a statically typed low-level systems language is an unusual thing.
bsder 4y ago
FEXPRs aren't comptime and aren't macros--the point of FEPXRs is that you hold off evaluating the arguments until runtime or, perhaps, not at all (think short circuit booleans). This was actually a schism in Lisp and why FEXPRs died out. CS theory wanted to compile things for speed and FEXPRs very much didn't fit into that. This is why macros took over--they were very much targeted at compile time. The late John Shutt's thesis and work on the language he called Kernel goes into quite a bit of detail and the history about it: https://web.cs.wpi.edu/~jshutt/kernel.html https://web.cs.wpi.edu/~jshutt/kernel.html Sadly, Shutt never really "completed" the Kernel language--the language is very interesting but is extremely slow and unwieldy in the descriptions he gave. It generates a lot of garbage and extra "environments"; it resists compilation and memoization; it sometimes seems to go out of its way to deal with things that make life very difficult (circular and infinite lists). A couple of good passes of optimization might have produced something very interesting. I was personally attracted to it for very small embedded devices (<16K RAM/16K Flash) as it delgates a lot of macrology to interpretation--sadly I just couldn't get the footprint down far enough given all the garbage and environments the language generates. I suspect it's possible, but it would take someone who knew the landscape intimately to figure out what needed to be dropped.
- klipt 4y ago
  > hold off evaluating the arguments until runtime or, perhaps, not at all (think short circuit booleans). > infinite lists Sounds like an early attempt at Haskell. Haskell is lazy by default so you can write your own "if" as a function and it will be just as short circuiting as the built in if. And infinite lists show up in basic Haskell tutorials. However Haskell combines this laziness with immutability, which is an easier combination to reason about than laziness with mutable side effects. Compiler technology for lazy languages is definitely impressive, but it's still the case that if you want to squeeze the last bit of performance out of Haskell code it does usually require manually forcing eager evaluation.
- int_19h 4y ago
  Did they die out, or did they just go into hiding? I can't help but think how R - which is really a Lisp with C-like syntactic sugar on top - always lazily evaluates arguments (and captures the original expression + environment for them that the callee can access), which makes it possible to represent all special forms as plain function calls.
  - bsder 4y ago
    FEXPRS were actively murdered by the main Lisp intelligentsia: See: "Special Forms in Lisp" by Pitman https://dl.acm.org/doi/pdf/10.1145/800087.802804 https://dl.acm.org/doi/pdf/10.1145/800087.802804 Shutt's thesis does a good job talking about the history.

That isn’t a C-like language. Doing it in a statically typed low-level systems language is an unusual thing.

FEXPRs aren't comptime and aren't macros--the point of FEPXRs is that you hold off evaluating the arguments until runtime or, perhaps, not at all (think short circuit booleans). This was actually a schism in Lisp and why FEXPRs died out. CS theory wanted to compile things for speed and FEXPRs very much didn't fit into that. This is why macros took over--they were very much targeted at compile time. The late John Shutt's thesis and work on the language he called Kernel goes into quite a bit of detail and the history about it: https://web.cs.wpi.edu/~jshutt/kernel.html https://web.cs.wpi.edu/~jshutt/kernel.html Sadly, Shutt never really "completed" the Kernel language--the language is very interesting but is extremely slow and unwieldy in the descriptions he gave. It generates a lot of garbage and extra "environments"; it resists compilation and memoization; it sometimes seems to go out of its way to deal with things that make life very difficult (circular and infinite lists). A couple of good passes of optimization might have produced something very interesting. I was personally attracted to it for very small embedded devices (<16K RAM/16K Flash) as it delgates a lot of macrology to interpretation--sadly I just couldn't get the footprint down far enough given all the garbage and environments the language generates. I suspect it's possible, but it would take someone who knew the landscape intimately to figure out what needed to be dropped.

klipt 4y ago
> hold off evaluating the arguments until runtime or, perhaps, not at all (think short circuit booleans). > infinite lists Sounds like an early attempt at Haskell. Haskell is lazy by default so you can write your own "if" as a function and it will be just as short circuiting as the built in if. And infinite lists show up in basic Haskell tutorials. However Haskell combines this laziness with immutability, which is an easier combination to reason about than laziness with mutable side effects. Compiler technology for lazy languages is definitely impressive, but it's still the case that if you want to squeeze the last bit of performance out of Haskell code it does usually require manually forcing eager evaluation.
int_19h 4y ago
Did they die out, or did they just go into hiding? I can't help but think how R - which is really a Lisp with C-like syntactic sugar on top - always lazily evaluates arguments (and captures the original expression + environment for them that the callee can access), which makes it possible to represent all special forms as plain function calls.
- bsder 4y ago
  FEXPRS were actively murdered by the main Lisp intelligentsia: See: "Special Forms in Lisp" by Pitman https://dl.acm.org/doi/pdf/10.1145/800087.802804 https://dl.acm.org/doi/pdf/10.1145/800087.802804 Shutt's thesis does a good job talking about the history.