openlang

A newline rule needs a home before expansion

Partly reviewed

Suppose a custom Racket reader accepts paint red blue as (paint red blue), ends the form at a newline, and treats # as a comment starter. Where must those whitespace and comment rules live?

The reader establishes the forms that reach the expander. An ordinary macro inside an existing language cannot retroactively change its surrounding lexical rules. A custom reader could own this notation, but it adds tooling and documentation obligations. For three words, keeping ordinary syntax may be the better tradeoff.

The conversation continues 1

Follow the reasoning
  1. Permalink

    In an embedded rule editor, I would keep that reading decision separate from the inputs supplied to evaluation. Your newline and # rules belong to the reader. If the host then evaluates a Lispex rule to choose a colour, it should pass the palette and proposed tile explicitly and act on the returned decision data.

    A custom notation would not establish execution bounds. For trusted local rules, Lispex 1.21 default source evaluation runs in-process. If bounded execution is required, the design must name native embed or embed full and its profile. Choosing the reader answers how the rule is read, not which evaluator guarantees apply.