Жаль, что сообщество куда-то рассосалось, настал момент, когда нужен коллективный разум. Спустя примерно 2 месяца после начала работы над макросами Зоркий Глаз обнаружил, что в сарае нет одной стены, т.е. выяснилось, что текст с макросами не переводится движком перевода.
Подходы утром написал в телеграме:
* сделать двухъязычность в самом компиляторе, т.е. разрешать в любом месте писать Потоки.Писарь наравне со Streams.Writer.
- минус в том, что для поиска нужно будет искать и русский, и английский варианты.
* переводить макросы во время макрорасширения.
- минус в том, что вообще непонятно, что имеется в виду, это просто смутная идея
* ограничить вызовы макросов, чтобы они были похожи на вызовы функций, и воспринимать их так же при анализе кода.
- минус в сочетании усложнения и ослабления. Прежде всего, становится ясно, что не получится заменить макросами конструкции #если (препроцессор). Утешает то, что и в лиспе это не получается, т.к. там, кроме макросов, есть директивы препроцессора #+ . А раз в лиспе это нельзя, то нефиг и лезть. Здесь внезапно выясняется, что макросы в Си элегантны!
* ограничить _вызовы_ макросов, чтобы они были похожи на _определения_ классов, и так их воспринимать.
- выглядит более-менее жизнеспособным
* в модуле одинаковое слово переводится одинаково независимо от контекста.
- тоже выглядит жизнеспособным, хотя и не решает вопрос о составных именах (то, что в Си есть ##). Хотя тут можно выкрутиться несколькими способами. однако такие модули потребуют значительного рефакторинга, в худшем случае он будет нелокальным, а затронет и ИПП других модулей (поскольку это правило должно соблюдаться в модуле тотально). Особенно плохо, что если в нашем модуле "Клиент" используется "Модуль1.Имя" и "Модуль2.Имя", то возникает ограничение, требующее одинаковости перевода "Имя" в этих модулях и всё начинает сливаться в одну единую общую помойку. С другой стороны, конечно же, это может быть и большим плюсом, поскольку именование в коде становится более чётким. Но всё же это подрывает идею пространств имён.
Метапроцедуры vs (движок перевода и двухкомпиляторность)
Метапроцедуры vs (движок перевода и двухкомпиляторность)
Последний раз редактировалось БудДен 18.01.22 23:02, всего редактировалось 1 раз.
Re: Макросы и движок перевода
Прототип решения на вечер выглядит так:
- не трогаем препроцессор #if. Цель сделать единый макропроцессор для всех уже существующих в АО применений и плюс к тому ещё для замены шаблонных модулей мы не можем достичь, значит, отступаем от неё. Наша задача - покрыть шаблоны модулей.
- понятие цитаты кода упраздняем. Параметром макроса может быть только то, что можно осмыслить в контексте вызова, а следовательно, и перевести.
Например,
- выражение
- выражение-тип
- ссылка на процедуру
- ключевое слово RETURN как признак того, что из процедуры можно сделать "нелокальный" возврат.
В A2 также возможна ссылка на импорт, а импорт может быть параметризованный - это открывает возможности для многоэтажных шаблонов. Нам нужна какая-то замена, но пока её нет. - нужна замена "блока операторов", то, что в лиспе обозначается как "&Body". Видимо, нужно ввести понятие "подставляемого блока", который отличается от inline процедуры тем, что может осуществить возврат из охватывающего блока (это важно для макросов). Блок может содержать "параметры блока", подобные параметрам шаблона - они перечислены в объявлении блока и так мы их осмысливаем. Остальное осмысливается в том контексте, где этот блок написан. Т.е. в целом это выглядит как (локальная) процедура.
Re: Макросы и движок перевода
В общем, достали меня эти макросы-фигакросы. Надо как-то выйти из этой игры, сделав вид, что всё нормально, но никак не получается :(
Re: Макросы и движок перевода
Появились некоторые идеи. Во-первых, можно снизить уровень интеграции макросов в тулчейн, подвергая макрорасширению только избранные модули, а не все. Так можно будет сделать то же, что и в А2, т.е. единицей макрорасширения будет модуль. А основное тело кода не будет затронуто этой бедой, оно будет всего лишь импортировать модуль. Вместо "использует М := Модуль(арг1, арг2)" будем писать в системе сборки:
"Модуль_арг1_арг2 = Модуль(арг1,арг2)", и это будет означать, что в этот момент в сборке запускаем макрорасширитель. А клиент будет уже писать "использует М := Модуль_арг1_арг2". Как это решает проблему с переводом, пока не думал, но в целом масштаб беды снижается.
"Модуль_арг1_арг2 = Модуль(арг1,арг2)", и это будет означать, что в этот момент в сборке запускаем макрорасширитель. А клиент будет уже писать "использует М := Модуль_арг1_арг2". Как это решает проблему с переводом, пока не думал, но в целом масштаб беды снижается.
Re: Макросы и движок перевода
Ага. А при этом можно делать макрорасширение только в русскоязычном режиме. Для англоязычной версии мы не касаемся истинных исходников модулей, а переводим только результат макрорасширения. Это начинает быть похожим на решение, причём идеологически правильное. Но пока ещё многое неясно. Например, при такой ситуации все русскоязычные имена, использованные в процессе макрорасширения, замораживаются и не могут быть автоматически изменены. Их изменить можно, но для этого понадобится поиск текста по файлам. Кроме того, механизм сборки нужно поменять так, чтобы он в англоязычном режиме пропускал этап макрорасширения.
Re: Макросы и движок перевода
Правда, при этом нельзя будет параметризовать модуль из англоязычной ветки. Выглядит слишком уж сурово.
Re: Макросы и движок перевода
Выяснено, что в A2 только один макро-модуль (GenericCollections) с одним клиентом (WMBuilder).
Re: Метапроцедуры vs (движок перевода и двухкомпиляторность)
Кроме движка перевода, двухкомпиляторность тоже мешает макросам - она не даёт сделать литералы цитат, поскольку цитаты превращаются в цепочку лексем. Если мы будем из литерала конструировать цепочку лексем, будет возникать ситуация, когда мы цитату скомпилировали лисом, а потом клиента компилируем фоксом, или наоборот. В связи с этим пока что решено не делать литералы цитат. Все цитаты, которые есть в коде, существуют только во время компиляции и не доходят до того, чтобы быть записанными в виде данных в объектный файл. Как минимум, я на это очень надеюсь.