4 ms·

I want to look at it to understand. But my guess is that this happens at runtime, doesn't it. If this happens at runtime, this means runtime evaluates the macro

I want to look at it to understand. But my guess is that this happens at runtime, doesn't it. If this happens at runtime, this means runtime evaluates the macro, lisp function is generated, generated lisp function is compiled and used.

dragontamer 4y ago
> But my guess is that this happens at runtime, doesn't it Macros would be evaluated at compile-time (or arguably _right before_ compile time).
- terminalcommand 4y ago
  How can you evaluate a complex macro at compile-time if you are doing AoT compilation? Lisp macros are not like C macros where simple substitution would suffice, they need to be evaluated. I found my exact question on stackoverflow: https://stackoverflow.com/questions/7072980/how-do-you-compile-macros-in-a-lisp-compiler https://stackoverflow.com/questions/7072980/how-do-you-compi... The answers on SO are still not clear to me, some people say the macros can be evaluated at compile time, some say that the runtime needs to include some kind of interpreted to run macros. Some say incremental compilation is key to understand how macros get evaluated at compile time. I will run experiments on this.
  - erik_seaberg 4y ago
    A compiled Lisp program might not be able to eval a list or load a source file, for the same reason a packaged jar generally won’t contain a copy of the Java compiler. I think eval-when controls which macro definitions (if any) need to be available at runtime, rather than being expanded away while compiling functions.
    - terminalcommand 4y ago
      From my conversation with lispm above, I discovered that each binary SBCL produces includes the compiler as well. This is what is meant by incremental compilation I get it. When I first heard the term incremental compilation, I thought of a process like going through the ast couple of times and evaluating expressions. This wasn't what it meant. Now it makes sense. You include the lisp compiler in each binary. For parts you cannot evaluate at compile time, you compile at runtime, just like a JIT.
eyelidlessness 4y ago
> If this happens at runtime, this means runtime evaluates the macro Generally speaking this isn’t the case. There are probably exceptions besides a repl, but they’ll almost all be repl-like because macros are effectively functions of pre-compiled code, represented as lists as written in the code. In other words, generally speaking, a lisp program’s life cycle goes something like this: 1. Developer writes lists. 2. Some of these lists are macros, compile them and execute them with their arguments. Many of these are themselves lists and symbols, which will be preserved according to various rules depending on which lisp you’re using and how they isolate code lists from program lists. It’s complicated. 3. Recurse step two until there are no more macro calls. 4. Now you have the actual program, and now you compile that. 5. Now you can execute the actual program.
lispm 4y ago
Macros were invented such that macro expansion does NOT happen at runtime. Lisp designers were implementing languages in the 70s which were used to develop whole operating systems for computers with less than one million instructions per second. With window systems, networking, etc. A big part of the history of Lisp is how to design the language such that it is efficient AND/OR dynamic. Lots of people invented clever memory management, clever implementation techniques and adjusted the language for efficiency. The first self-hosted Lisp compiler appeared already in 1962.
- terminalcommand 4y ago
  I am not saying lisp is not performative. I am still not sold, I will make my own experiments and report back.
  - deleted 4y ago
    [deleted]

dragontamer 4y ago

> But my guess is that this happens at runtime, doesn't it Macros would be evaluated at compile-time (or arguably _right before_ compile time).

terminalcommand 4y ago
How can you evaluate a complex macro at compile-time if you are doing AoT compilation? Lisp macros are not like C macros where simple substitution would suffice, they need to be evaluated. I found my exact question on stackoverflow: https://stackoverflow.com/questions/7072980/how-do-you-compile-macros-in-a-lisp-compiler https://stackoverflow.com/questions/7072980/how-do-you-compi... The answers on SO are still not clear to me, some people say the macros can be evaluated at compile time, some say that the runtime needs to include some kind of interpreted to run macros. Some say incremental compilation is key to understand how macros get evaluated at compile time. I will run experiments on this.
- erik_seaberg 4y ago
  A compiled Lisp program might not be able to eval a list or load a source file, for the same reason a packaged jar generally won’t contain a copy of the Java compiler. I think eval-when controls which macro definitions (if any) need to be available at runtime, rather than being expanded away while compiling functions.
  - terminalcommand 4y ago
    From my conversation with lispm above, I discovered that each binary SBCL produces includes the compiler as well. This is what is meant by incremental compilation I get it. When I first heard the term incremental compilation, I thought of a process like going through the ast couple of times and evaluating expressions. This wasn't what it meant. Now it makes sense. You include the lisp compiler in each binary. For parts you cannot evaluate at compile time, you compile at runtime, just like a JIT.

eyelidlessness 4y ago

> If this happens at runtime, this means runtime evaluates the macro Generally speaking this isn’t the case. There are probably exceptions besides a repl, but they’ll almost all be repl-like because macros are effectively functions of pre-compiled code, represented as lists as written in the code. In other words, generally speaking, a lisp program’s life cycle goes something like this: 1. Developer writes lists. 2. Some of these lists are macros, compile them and execute them with their arguments. Many of these are themselves lists and symbols, which will be preserved according to various rules depending on which lisp you’re using and how they isolate code lists from program lists. It’s complicated. 3. Recurse step two until there are no more macro calls. 4. Now you have the actual program, and now you compile that. 5. Now you can execute the actual program.

lispm 4y ago

Macros were invented such that macro expansion does NOT happen at runtime. Lisp designers were implementing languages in the 70s which were used to develop whole operating systems for computers with less than one million instructions per second. With window systems, networking, etc. A big part of the history of Lisp is how to design the language such that it is efficient AND/OR dynamic. Lots of people invented clever memory management, clever implementation techniques and adjusted the language for efficiency. The first self-hosted Lisp compiler appeared already in 1962.

terminalcommand 4y ago
I am not saying lisp is not performative. I am still not sold, I will make my own experiments and report back.
- deleted 4y ago
  [deleted]