Thank you for your comment

Beau­tiful Racket / explainers

Evaluation

In broad terms, the eval­u­a­tion of a Racket program proceeds in four stages:

  1. A source file may have a reader attached (via the #lang line). If so, this reader trans­for­ma­tion is applied to the code.

  2. Any forms that intro­duce bind­ings, like require or define, are resolved.  + For the specifics, see intro­ducing bind­ings in the Racket Refer­ence.

  3. Macros are expanded, starting with the outer­most forms and progressing inward. This stage of eval­u­a­tion is known as compile time or phase 1. Macro expan­sion is recur­sive: if a macro expands to become another macro, the new macro is also expanded. Even­tu­ally, there will be no macros left, leaving only core syntactic forms. This is called the fully expanded program.

  4. If any iden­ti­fiers in the fully expanded program still don’t have bind­ings, then eval­u­a­tion fails with an error. Other­wise, all expres­sions in the fully expanded program are eval­u­ated, starting with the inner­most expres­sions and progressing outward, as in the example below. This stage of eval­u­a­tion is known as run time or phase 0. What­ever remains is the program result.

    (require br/verbose-app)
    (* (+ 1 2) (* 3 4 (/ 5 6)))
    1
2
    (require br/verbose-app)
(* (+ 1 2) (* 3 4 (/ 5 6)))
    copy to clipboard
    handling subexpressions in (* (+ 1 2) (* 3 4 (/ 5 6)))
    handling subexpressions in (+ 1 2)
    evaluating (+ 1 2) = 3
    handling subexpressions in (* 3 4 (/ 5 6))
    handling subexpressions in (/ 5 6)
    evaluating (/ 5 6) = 5/6
    evaluating (* 3 4 (/ 5 6)) = 10
    evaluating (* (+ 1 2) (* 3 4 (/ 5 6))) = 30
    30
    1
2
3
4
5
6
7
8
9
    handling subexpressions in (* (+ 1 2) (* 3 4 (/ 5 6)))
handling subexpressions in (+ 1 2)
evaluating (+ 1 2) = 3
handling subexpressions in (* 3 4 (/ 5 6))
handling subexpressions in (/ 5 6)
evaluating (/ 5 6) = 5/6
evaluating (* 3 4 (/ 5 6)) = 10
evaluating (* (+ 1 2) (* 3 4 (/ 5 6))) = 30
30
    copy to clipboard

This process is recur­sive: each phase of eval­u­a­tion can trigger the import of other modules (for instance, using require). This, in turn, causes the eval­u­a­tion of these imported modules.

Order of eval­u­a­tion

Run-time expres­sions are eval­u­ated from the inside out. But macros are eval­u­ated in the oppo­site direc­tion—from the outside in. The neces­sity for this should be apparent: a macro can rewrite any code inside it, so there’s no way to know in advance whether the inner expres­sions can or should be eval­u­ated at all. Consider this example—do you end up with a zombie apoc­a­lypse, or baby pandas?

(define-macro (unleash INNER-EXPR) #''baby-pandas)
(unleash (zombie-apocalypse))
1
2
(define-macro (unleash INNER-EXPR) #''baby-pandas)
(unleash (zombie-apocalypse))
copy to clipboard

But this differ­ence in eval­u­a­tion order can also defeat certain intu­itions about expres­sions, espe­cially when nesting macros inside each other, or using macros that have side effects. Here, notice how using func­tions instead of macros changes the output:

(define (ofunc inner) (displayln "outer func"))
(define (ifunc) (displayln "inner func"))
(ofunc (ifunc))
1
2
3
(define (ofunc inner) (displayln "outer func"))
(define (ifunc) (displayln "inner func"))
(ofunc (ifunc))
copy to clipboard
inner func
outer func
1
2
inner func
outer func
copy to clipboard
(define-macro (omacro INNER-EXPR) #'(displayln "outer macro"))
(define-macro (imacro) #'(displayln "inner macro"))
(omacro (imacro))
1
2
3
(define-macro (omacro INNER-EXPR) #'(displayln "outer macro"))
(define-macro (imacro) #'(displayln "inner macro"))
(omacro (imacro))
copy to clipboard
outer macro
1
outer macro
copy to clipboard

Further

← prev next →