Вече на п-п-р

Жаль, что сообщество куда-то рассосалось, настал момент, когда нужен коллективный разум. Спустя примерно 2 месяца после начала работы над макросами Зоркий Глаз обнаружил, что в сарае нет одной стены, т.е. выяснилось, что текст с макросами не переводится движком перевода.

Подходы утром написал в телеграме:

* сделать двухъязычность в самом компиляторе, т.е. разрешать в любом месте писать Потоки.Писарь наравне со Streams.Writer.

- минус в том, что для поиска нужно будет искать и русский, и английский варианты.

* переводить макросы во время макрорасширения.

- минус в том, что вообще непонятно, что имеется в виду, это просто смутная идея

* ограничить вызовы макросов, чтобы они были похожи на вызовы функций, и воспринимать их так же при анализе кода.

- минус в сочетании усложнения и ослабления. Прежде всего, становится ясно, что не получится заменить макросами конструкции #если (препроцессор). Утешает то, что и в лиспе это не получается, т.к. там, кроме макросов, есть директивы препроцессора #+ . А раз в лиспе это нельзя, то нефиг и лезть. Здесь внезапно выясняется, что макросы в Си элегантны!

* ограничить _вызовы_ макросов, чтобы они были похожи на _определения_ классов, и так их воспринимать.

- выглядит более-менее жизнеспособным

* в модуле одинаковое слово переводится одинаково независимо от контекста.

- тоже выглядит жизнеспособным, хотя и не решает вопрос о составных именах (то, что в Си есть ##). Хотя тут можно выкрутиться несколькими способами. однако такие модули потребуют значительного рефакторинга, в худшем случае он будет нелокальным, а затронет и ИПП других модулей (поскольку это правило должно соблюдаться в модуле тотально). Особенно плохо, что если в нашем модуле "Клиент" используется "Модуль1.Имя" и "Модуль2.Имя", то возникает ограничение, требующее одинаковости перевода "Имя" в этих модулях и всё начинает сливаться в одну единую общую помойку. С другой стороны, конечно же, это может быть и большим плюсом, поскольку именование в коде становится более чётким. Но всё же это подрывает идею пространств имён.

Прототип решения на вечер выглядит так:

• не трогаем препроцессор #if. Цель сделать единый макропроцессор для всех уже существующих в АО применений и плюс к тому ещё для замены шаблонных модулей мы не можем достичь, значит, отступаем от неё. Наша задача - покрыть шаблоны модулей.
• понятие цитаты кода упраздняем. Параметром макроса может быть только то, что можно осмыслить в контексте вызова, а следовательно, и перевести.
  
  Например,
  
  - выражение
  - выражение-тип
  - ссылка на процедуру
  - ключевое слово RETURN как признак того, что из процедуры можно сделать "нелокальный" возврат.
  
  В A2 также возможна ссылка на импорт, а импорт может быть параметризованный - это открывает возможности для многоэтажных шаблонов. Нам нужна какая-то замена, но пока её нет.
• нужна замена "блока операторов", то, что в лиспе обозначается как "&Body". Видимо, нужно ввести понятие "подставляемого блока", который отличается от inline процедуры тем, что может осуществить возврат из охватывающего блока (это важно для макросов). Блок может содержать "параметры блока", подобные параметрам шаблона - они перечислены в объявлении блока и так мы их осмысливаем. Остальное осмысливается в том контексте, где этот блок написан. Т.е. в целом это выглядит как (локальная) процедура.

В общем, достали меня эти макросы-фигакросы. Надо как-то выйти из этой игры, сделав вид, что всё нормально, но никак не получается :(

Появились некоторые идеи. Во-первых, можно снизить уровень интеграции макросов в тулчейн, подвергая макрорасширению только избранные модули, а не все. Так можно будет сделать то же, что и в А2, т.е. единицей макрорасширения будет модуль. А основное тело кода не будет затронуто этой бедой, оно будет всего лишь импортировать модуль. Вместо "использует М := Модуль(арг1, арг2)" будем писать в системе сборки:
"Модуль_арг1_арг2 = Модуль(арг1,арг2)", и это будет означать, что в этот момент в сборке запускаем макрорасширитель. А клиент будет уже писать "использует М := Модуль_арг1_арг2". Как это решает проблему с переводом, пока не думал, но в целом масштаб беды снижается.

Ага. А при этом можно делать макрорасширение только в русскоязычном режиме. Для англоязычной версии мы не касаемся истинных исходников модулей, а переводим только результат макрорасширения. Это начинает быть похожим на решение, причём идеологически правильное. Но пока ещё многое неясно. Например, при такой ситуации все русскоязычные имена, использованные в процессе макрорасширения, замораживаются и не могут быть автоматически изменены. Их изменить можно, но для этого понадобится поиск текста по файлам. Кроме того, механизм сборки нужно поменять так, чтобы он в англоязычном режиме пропускал этап макрорасширения.

Правда, при этом нельзя будет параметризовать модуль из англоязычной ветки. Выглядит слишком уж сурово.

Выяснено, что в A2 только один макро-модуль (GenericCollections) с одним клиентом (WMBuilder).

Кроме движка перевода, двухкомпиляторность тоже мешает макросам - она не даёт сделать литералы цитат, поскольку цитаты превращаются в цепочку лексем. Если мы будем из литерала конструировать цепочку лексем, будет возникать ситуация, когда мы цитату скомпилировали лисом, а потом клиента компилируем фоксом, или наоборот. В связи с этим пока что решено не делать литералы цитат. Все цитаты, которые есть в коде, существуют только во время компиляции и не доходят до того, чтобы быть записанными в виде данных в объектный файл. Как минимум, я на это очень надеюсь.