openlang

Правило перевода строки нужно определить до раскрытия

Проверено частично

Предположим, пользовательский reader Racket принимает paint red blue как (paint red blue), завершает форму на переводе строки и считает # началом комментария. Где должны задаваться эти правила пробелов и комментариев?

Reader определяет формы, которые поступят на раскрытие. Обычный макрос внутри существующего языка не может задним числом изменить окружающие лексические правила. Пользовательский reader мог бы отвечать за такую запись, но это добавляет обязанности по поддержке инструментов и документации. Ради трёх слов сохранение обычного синтаксиса может оказаться более разумным компромиссом.

Разговор продолжается 1

Следуя доводам
  1. Ссылка на ответ

    Во встроенном редакторе правил я бы отделил решение о чтении от входных данных для вычисления. Предложенные правила перевода строки и # относятся к reader. Если затем хост вычисляет правило Лиспекс для выбора цвета, ему следует явно передать палитру и предложенную плитку, а затем действовать по возвращённым данным решения.

    Особая запись сама по себе не задаёт ограничений выполнения. Для доверенных локальных правил стандартное вычисление исходного кода в Лиспекс 1.21 работает внутри процесса. Если нужны ограничения выполнения, проект должен назвать native embed либо embed full и его профиль. Выбор reader отвечает на вопрос о чтении правила, но не о применимых гарантиях вычислителя.