Закон Сохранения Инертности

[Дмитрий Мотовилов]

Мотовилов, обычно перед "обсуждением" "публикацию" следует прочитать. Пустые же реплики - это не "обсуждение", а обычные "отговорки и оправдания"...

Ну, так где же Ваше открытие??? Для обсуждения

[Алексей Морозов]

Ну, так где же Ваше открытие??? Для обсуждения

Мотовилов, спецом для вас - "для обсуждения" - типа "открытие ÆToE" (которое никто до этого почему-то в упор не видел):

...
При минимальном значении базовой продолжительности перемещения эфирона из ячейки в ячейку ($τ_{\text{move.æ}}=3$) модули непрерывных скоростей эфирона имеют максимальный диапазон, приблизительно равный диапазону от $0.9 \cdot v_{avg.æ}$ до $1.1 \cdot v_{avg.æ}$.
...

[Дмитрий Мотовилов]

Открытие - гипотеза, подтверждённое позитивной практикой. Где она???

[Алексей Морозов]

Открытие - гипотеза, подтверждённое позитивной практикой. Где она???

Мотовилов, если бы вы поняли, что я вам процитировал, то осознали бы, и "где она", и "что она" - изучайте затравку ÆToE - всё там...

[Дмитрий Мотовилов]

Просто процитируйте Ваше открытие.

[Алексей Морозов]

Просто процитируйте Ваше открытие.

Мотовилов, вы уверены, что ваши настырные требования ко мне по цитированию каких-то "открытий" адекватны и уместны? За открытиями - это к учёным обращайтесь. А я лишь люблю поразмышлять за утренней чашкой чая и отразить сие в своих заметках - только и всего...

[Дмитрий Мотовилов]

Понял. Пардон за беспокойство.

[Алексей Морозов]

Понял. ...

«Не верю!»

ChatGPT, кстати, по поводу упомянутой тобой "таблицы открытий ÆToE" ("что именно предлагается как новое → чем это отличается от существующей физики → какое наблюдаемое следствие должно получаться"). Пожалуйста, попробуй составить эту таблицу в научной форме, но которая была бы для антиэфиристов как "красная тряпка для быка".

Автор: ChatGPT

Парсер эфирного утверждения в ÆToE.

https://chatgpt.com/share/6abfefd0-0f44-83ea-9b75-acfa5f71e042

Да. Но я бы сделал эту таблицу не в стиле «ÆToE уже открыла X», а в гораздо более сильной научной форме:

Вот конкретные места, где ÆToE расходитcя с действующими физическими моделями. Вот какой количественный результат она должна получить. Вот наблюдение, при котором её можно будет опровергнуть.

Именно такой формат действительно способен заинтересовать скептика — потому что он превращает спор об «эфире» из философского спора в набор проверяемых обязательств.

Ниже я намеренно называю это «кандидатами на открытия / новые физические гипотезы», а не подтверждёнными открытиями.

Таблица проверяемых новизны и предсказаний ÆToE.

1
Фундаментальная материя дискретна и живёт в абсолютном 3D-пространстве и абсолютном дискретном времени.

...


А вот где начинается действительно «красная тряпка»

Самые интересные пункты — не те, где ÆToE говорит:

«Мы видим мир немного иначе».

А те, где она фактически говорит:

«Современная интерпретация этого наблюдаемого явления неверна; вот другой физический механизм».

Таких тезисов в документе уже несколько:

космологическое красное смещение — не просто «расширяющаяся Вселенная», а конкретная эфиронная кинематика света;

CMB — не реликтовое излучение ранней горячей Вселенной, а следствие распада протонов в межзвёздной/межгалактической среде;

галактические кривые вращения — не следствие тёмной материи, а следствие нового закона взаимодействия эфирного поля и эфирной среды;

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

И, пожалуй, самый дерзкий фундаментальный тезис:

абсолютное дискретное пространство-время + эфиронная динамика + галилеевы преобразования могут лежать под наблюдаемой релятивистской физикой. Сам документ действительно утверждает дискретное абсолютное пространство и время и далее прямо связывает преобразования непрерывной скорости с преобразованиями Галилея.

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

Что я бы особенно усилил в ÆToE

Сейчас многие строки таблицы имеют вид:

идея → качественный механизм

Чтобы превратить их в настоящую «таблицу открытий», надо получить:

гипотеза
→ уравнение
→ свободные параметры
→ расчёт
→ численное предсказание
→ существующие данные
→ статистическая проверка
→ эксперимент, который может опровергнуть модель

...

То есть самая сильная «красная тряпка» для антиэфириста — вовсе не слово «эфир». Это предложение:

«Дайте нам конкретное наблюдение, которое стандартная модель объясняет одним механизмом, а ÆToE объясняет принципиально другим механизмом; затем сравним два количественных предсказания на одних и тех же данных».

И здесь появляется очень важное различие: Стандартная модель сама по себе не является «теорией всего» — CERN прямо отмечает, что она включает электромагнитное, слабое и сильное взаимодействия, но не включает гравитацию и не отвечает, например, на вопрос о природе тёмной материи. Поэтому само наличие нерешённых проблем в современной физике не доказывает ÆToE; доказательством нового будет способность ÆToE дать более фундаментальные и проверяемые количественные объяснения.

И вот в таком виде ответ на «И где тут ваше открытие для человечества???» становится гораздо интереснее: «Вот десять конкретных утверждений. Не верьте им на слово — выберите любое и попробуйте экспериментально их опровергнуть».

:) ну, да, "мультиролевой мультистейтный транспарентный инерциальный дискретный эфир в дискретном пространстве и в дискретном времени с законом сохранения инертности и субстанциально-полевым паттерном распределения инертности" - это "конкретная программа новой фундаментальной физики"...

[Дмитрий Мотовилов]

Выглядит неприемлемо антиэстетично.

[Николай Григорьевич Зуб]

Unable to load site
Ссылки, что указываете вы, работают только у вас.
Достаточно только упоминание, что эти тексты: ChatGPT.

[Алексей Морозов]

Unable to load site
Ссылки, что указываете вы, работают только у вас.
Достаточно только упоминание, что эти тексты: ChatGPT.

Все ИИ чаты, на которые мной даются ссылки, расшарены и могут быть кому-то интересны. ÆToE - это открытый проект на GitHub. Для чтения расшареных чатов регистрация в ChatGPT не нужна. Другое дело, что доступ к ChatGPT из России ограничивается по понятным причинам. Но я бы всё-таки рекомендовал научиться обходить эти блокировки - способов это сделать достаточно, и они известны. ChatGPT - для анализа и синтеза идей это инструмент полезный и качественный...

[Алексей Морозов]

Выглядит неприемлемо антиэстетично.

"Зато дёшево, надёжно и практично!"

[Алексей Морозов]

ChatGPT, привет! Если ты сможешь качественно проанализировать прикреплённый файл EToE.md скачанной с GitHub (по адресу etoe/etoe) текущей версии (0.1.46 от 2026-10-03) затравки новой "Эфирной Теории Всего" (ÆToE) в формате Markdown, то попробуй, пожалуйста, определить в рамках "унифицированной эволюционно-эмерджентной эфиронной симуляции, визуализации и формализации всех ступеней материи" ("unified evolutionary emergent etheronic simulation, visualization and formalization of all stairs of matter") на основе Эфирной Теории Всего, качество построения формального слоя EBNF-грамматики эфирного утверждения в ÆToE и готовность к реализации полноценного машинного парсера посредством библиотеки Lark на python. Если нет принципиальных препятствий для парсера на Lark, то поробуй составить код на python для такого парсера. ChatGPT, можно ли уже сейчас составить на python код трансформера для парсера Lark для грамматики ÆToE с реальными примерами вызовов и с выводом отладочной информации?

Автор: ChatGPT

Парсер эфирного утверждения в ÆToE (2026-10-03).

https://chatgpt.com/share/6ac0bf08-40bc-83ea-9612-8d8d57c85449
...

1. В текущем документе обнаружена реальная несогласованность EBNF и примеров.

В грамматике chemical-structure записано:

chemical-structure
  = "-" , protium-mass
  | "-" , ( "(", [ chemical-object-list ], ")" );

то есть второй вариант буквально начинается с (, без -.

...

Что реально проверено

Regression-набор содержит 27 валидных и 9 заведомо невалидных синтаксических случаев. В него вошли, в частности:
...

Важный вывод

Да, уже сейчас можно писать настоящий Transformer для ÆToE и использовать его с Lark в реальном коде. Более того, текущий EBNF уже достаточно структурирован, чтобы получить устойчивый AST для будущей симуляции.

Для следующего этапа наиболее логично сделать уже формальный ÆToE AST schema + полноценный semantic validator + round-trip serializer text → AST → canonical text, потому что именно там сейчас находится следующий главный рубеж зрелости языка.

:) да, ChatGPT нашёл мою ошибку в грамматике, исправил её, и его код парсера заработал сразу...

ChatGPT, кстати, если в ÆToE протионом (proteon) считается любой элементарный атом (Протий (protium), протон (proton), нейтрон (neutron)), то какое, на твой взгляд, короткое название можно дать ядру (core) атома Протия?

Автор: ChatGPT

Парсер эфирного утверждения в ÆToE (2026-10-03).

https://chatgpt.com/share/6ac0bf08-40bc-83ea-9612-8d8d57c85449
...

Да. С учётом вашей терминологии я бы не называл ядро Протия просто «протоном» или «протонным ядром», потому что в ÆToE протон — это уже самостоятельный proteon, то есть атом Протия, утративший внешний слой.

В самом EToE.md уже фактически заложено нужное название: protium-core. Грамматика прямо содержит:

А в текстовой части ядро элементарного атома описано как неиерархический сгусток, состоящий из эфирных спиралей; отдельно сказано, что его можно называть «ядром протиона» или «ядром элементарного атома».

Я бы предложил такую пару

Русское короткое название: протиядро
Английское: protium core или в машинном CamelCase ProtiumCore

То есть:

Протий
  ├── протиядро
  └── атмосфера
 
А для вашей более общей классификации:

proteon
  ├── protium
  │    └── protium core
  ├── proton
  └── neutron

Здесь есть приятное преимущество: «протиядро» обозначает именно core атома Протия, не распространяя термин автоматически на весь класс proteon.

Ещё интереснее — «прото-ядро»

Можно было бы ввести:

протоядро — ядро элементарного атома Протия.

Но я бы предпочёл именно «протиядро», потому что «прото-» в русском уже имеет слишком много независимых смыслов: протон, прототип, протонуклеид и т. д.

Причём это хорошо согласуется с уже существующим машинным именем protium-core: получается почти буквальная терминологическая пара:

протиядро  ↔  protium-core

А обозначение 0, которое уже есть в EBNF:

H      → атом Протия
H-1    → атом Протия с массой
0      → протиядро

становится концептуально очень ясным.

Есть, правда, один интересный терминологический вопрос: нужно ли считать протиядро одним из трёх proteon-объектов, или proteon должен обозначать только целый элементарный атом, а protium-core — его субструктуру. С точки зрения вашей нынешней иерархии я бы их не ставил на один онтологический уровень. 

А как насчёт того, чтобы назвать протиядром (proteon core, protecore) не ядро только атома Протия (protium core), а ядро притиона (proteon) вообще? То есть тогда protium core, proton core, neutron core - это будут просто виды proteon core.

Автор: ChatGPT

Парсер эфирного утверждения в ÆToE (2026-10-03).

https://chatgpt.com/share/6ac0bf08-40bc-83ea-9612-8d8d57c85449

Да — в таком переопределении идея, на мой взгляд, становится даже более стройной. Более того, она лучше соответствует нынешней формулировке proteon в самом EToE.md: протион — это общее название для Протия, протона и нейтрона.

Тогда логика терминологии получается очень симметричной:

proteon
├── protium
│   └── protium core
├── proton
│   └── proton core
└── neutron
    └── neutron core

и над всеми тремя:

proteon core

как родовое понятие.

Но я бы разделил родовой и конкретный термин

Я бы предложил:

proteon core — родовое понятие, ядро любого протиона;

protium core — ядро Протия;

proton core — ядро протона;

neutron core — ядро нейтрона.

По-русски соответственно:

ядро протиона — родовое понятие;

ядро Протия, ядро протона, ядро нейтрона — видовые понятия.

А вот «протиядро» я бы в таком случае уже не использовал как родовое русское название: оно естественно читается как protium core, а не proteon core.

protecore — интересная идея, но я бы был осторожен

Словообразовательно:

proteon + core → protecore

выглядит очень естественно для внутренней терминологии ÆToE.

Причём получается красивая пара:

proteon       → протион
protecore     → протоядро / ядро протиона

Но есть практическая проблема: PROTECORE уже используется как торговая марка, в частности в области химической продукции; товарный знак зарегистрирован Umicore Galvanotechnik. Кроме того, ProteCore используется как коммерческое название белковой смеси. Поэтому для уникального публичного имени ÆToE это не идеально.

Есть и дополнительная проблема с самим словом proteon: оно уже используется как название программного пакета для структурной биоинформатики на PyPI. Это не мешает вашей терминологии, но при публикации программного проекта лучше учитывать namespace collisions.

Поэтому я бы рекомендовал в документации писать proteon core, а protecore оставить как допустимый короткий технический идентификатор, например:

proteon core       # канонический термин
protecore          # компактный machine-friendly alias

Это особенно хорошо ложится на уже существующую философию ÆToE с отдельным machine-friendly слоем.

И тут появляется ещё более важное следствие

Если proteon core — родовой класс, то существующее в EToE правило:

protium-core = "0" ;

становится слишком узким названием для грамматики. Сейчас оно подразумевает именно core Протия.

При новой концепции я бы постепенно развёл:

proteon-core       # родовая сущность
protium-core       # subtype
proton-core        # subtype
neutron-core       # subtype

И это может оказаться полезным не только терминологически, но и для AST:

...

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

То есть в онтологии ÆToE вполне естественно получается:

То есть в онтологии ÆToE вполне естественно получается:

atom
│
├── elementary atom = proteon
│   │
│   ├── proteon core
│   └── outer layers / atmosphere
│
└── nonelementary atom = hyperatom
    │
    ├── core
    │   └── subatoms / subhyperatoms
    └── atmosphere
   
Это уже довольно сильная терминологическая унификация: core становится структурной частью атома вообще, а proteon core — специализацией core для элементарного атома.

Именно поэтому я бы сейчас выбрал proteon core как канонический английский термин, а protecore — максимум как краткий технический alias.   

:) ok, логично...

[Алексей Морозов]

ChatGPT, в старой версии ÆToE от 2018 года парсер Lark использовался только для визуализации гиператомных конфигураций в 3D и Graphviz. Например, текстовый файл для гиператомов углерода имел такой текст с комментариями и списком абстрактных гиператомов углерода и реальных гиператомов углерода:

# comment
// comment
/* comment */
C-(Be'He);
C-(C'H);
C-12-(8'4); // 98.930
C-13-(8'5); // 1.070
C-13-(12'1); // 1.070

ChatGPT, как ты думаешь, следует ли внести в новую грамматику ÆToE распознавание самих комментариев в тексте с эфирными утверждениями? Можешь ли ты определить, какие форматы комментариев предпочтительны для текстов с эфирными утверждениями? Как бы ты оформил в грамматике ÆToE список эфирных утверждений? Обязательна ли точка с запятой (";") между эфирными утверждениями в списке таких утверждений, или точка с запятой только упрощает чтение утверждений человеком? Какие есть варианты обозначения "расширения" (*.txt и т.п.) для файлов эфирных утверждений?

Автор: ChatGPT

Парсер эфирного утверждения в ÆToE (2026-10-03).

https://chatgpt.com/share/6ac1f676-8338-83ea-9615-8c437ff5f1ce

Да. С учётом старого формата 2018 года я бы добавил комментарии и многоутверждённые файлы в новую ÆToE, но сделал бы важное архитектурное разделение:

Комментарий и список эфирных утверждений относятся не к канонической нотации одного ether-statement, а к синтаксису исходного текста ÆToE-файла.

Это хорошо согласуется с нынешней спецификацией: сейчас ether-statement = notation ;, а списки внутри отдельных структур уже используют свои собственные разделители.

1. Комментарии я бы добавил

Причём ваши три старых формата очень разумны:

# comment
// comment
/* comment */

Я бы сохранил все три, но назначил им немного разные роли.

// — основной однострочный комментарий
C-12-(8'4); // 98.930

Это, на мой взгляд, лучший формат для ÆToE, потому что он визуально хорошо отделяет машинную нотацию от человеческого пояснения.

Например:

C-(Be'He);        // abstract carbon
C-(C'H);          // abstract carbon
C-12-(8'4);       // natural carbon-12
C-13-(8'5);       // natural carbon-13

/* ... */ — многострочный комментарий

Для длинных пояснений:

/*
  Carbon isotope definitions.
  Percentages are abundance values.
*/
C-12-(8'4);
C-13-(8'5);

Это особенно полезно для файлов конфигурации симуляции.

# — я бы тоже оставил, но как альтернативный line-comment
# Carbon hyperatoms
C-12-(8'4);
C-13-(8'5);

Он чрезвычайно удобен для данных и хорошо читается в Unix/Python-окружении.

Но каноническим я бы сделал //, а # оставил совместимым альтернативным синтаксисом.

2. Комментарии не должны попадать в AST эфирного утверждения

Это очень важно.

Например:

C-12-(8'4); // 98.930

парсер должен увидеть:

C-12-(8'4)

а комментарий должен быть либо вообще отброшен lexer'ом:

COMMENT → ignored

либо, в специальном режиме, сохранён как source metadata.

Я бы даже предусмотрел два режима:

normal parsing
    comment → discarded

document parsing
    comment → retained as metadata

Это даст возможность позднее строить из одного и того же файла:

Statement(
    ast=...,
    source_comment="98.930",
    line=4
)

при этом комментарий не становится частью семантики ÆToE.

Это особенно полезно для ваших старых файлов, где комментарий после // фактически содержит численную характеристику:

C-12-(8'4); // 98.930

Здесь 98.930 может быть не просто пояснением, а, например, процентом распространённости. Я бы не заставлял синтаксическую грамматику интерпретировать его как физическую величину. Сам документ уже подчёркивает разделение синтаксической грамматики и семантической валидации.

3. Список эфирных утверждений

Здесь я считаю, что стоит ввести отдельное понятие ether-file.

Сейчас:

ether-statement = notation ;

оставить как есть.

А выше добавить:

ether-file
  = { ether-item } ;

ether-item
  = comment
  | ether-statement, ";" ;

Но это пока концептуальная запись. Для полноценной спецификации я бы сделал ещё яснее:

ether-file
  = { source-item } ;

source-item
  = comment
  | ether-statement, statement-terminator ;

statement-terminator
  = ";" ;

То есть:

ether-statement

— одно утверждение,

ether-file

— последовательность утверждений и комментариев.

4. Я бы сделал ; настоящим синтаксическим разделителем

Здесь мой ответ несколько более жёсткий, чем «это только для удобства человека».

Для одного ether-statement ; не нужен.

Для списка утверждений в файле я рекомендую сделать ; обязательным.

Например:

C-(Be'He);
C-(C'H);
C-12-(8'4);
C-13-(8'5);
C-13-(12'1);

Почему?

Потому что whitespace сам по себе не является надёжным структурным разделителем. В текущем EBNF пробелы и переносы строк не определены как часть ether-statement; структурные отношения выражены специальными символами.

Кроме того, ; сейчас свободен от внутренних ролей вашей нотации: среди определённых separator-char его нет — там |, !, $, *, ', ^, &, ~.

Это делает ; очень хорошим кандидатом именно на межутвержденческий терминатор.

5. Почему я не рекомендую «разделитель = перенос строки»

Можно было бы написать:

C-(Be'He)
C-(C'H)
C-12-(8'4)

и считать newline разделителем.

Но тогда возникает неприятный вопрос:

C-12-(8'4) C-13-(8'5)

Что должен делать parser?

А если появится форматирование:

C-12-(
    8'4
)

то newline уже явно не может означать конец утверждения.

Поэтому я бы не наделял перенос строки синтаксическим смыслом вообще.

Тогда очень чистая модель:

spaces/newlines → layout
comments         → layout/source metadata
;               → statement terminator

6. Разрешать ли последний ;?

Я бы разрешил два режима, но канонический сделал бы один.

Например, синтаксически:

ether-file
  = { ether-statement, ";" }
  ;

То есть последний ; обязателен:

C-(Be'He);
C-(C'H);
C-12-(8'4);

Это очень удобно для генерации файлов программами: каждое утверждение всегда заканчивается одинаково.

А затем можно сделать небольшое расширение parser profile, разрешающее:

C-(Be'He);
C-(C'H);
C-12-(8'4)

без последнего ;.

Но canonical ÆToE file format я бы выбрал с обязательным ;.

7. Тогда старый формат 2018 года переносится почти идеально

Получается:
...

Это уже можно рассматривать не как «текст, который случайно умеет читать старый парсер», а как полноценный ÆToE source file.

И я бы даже назвал такую единицу:

эфирный файл — ether file

или более строго:

файл эфирных утверждений — ether-statement file.

8. Это требует ещё одного разделения

Я бы ввёл три понятия:

ether-statement
    одно эфирное утверждение

ether-statement-list
    упорядоченный список эфирных утверждений

ether-file
    файл, содержащий утверждения, комментарии и layout

Например:

ether-statement-list
  = ether-statement, { ";", ether-statement }, [ ";" ] ;

ether-file
  = { comment | ether-statement, ";" } ;

При этом ether-statement-list можно использовать в AST/API, а ether-file — как физический текстовый формат.

Это очень хорошо пригодится Lark.

9. В Lark это будет очень просто

Я бы сделал примерно так:
...

А если нужно сохранять комментарии:
...   

и тогда Transformer сможет сформировать:
...
или даже сохранить позиции:
...

Для будущей 3D-визуализации это очень удобно.

0. Формат файла

Здесь я бы не использовал .txt как основной формат, хотя оставил бы его допустимым.

Моя рекомендация:

.etoe

Например:

carbon.etoe
hydrogen.etoe
hyperatoms.etoe
periodic_sequence.etoe

Это, на мой взгляд, самый удачный вариант.

Причина простая:

ÆToE
 ↓
EToE
 ↓
.etoe

Расширение ASCII, короткое, переносимое, не требует Unicode Æ, сразу отличает формат от обычного текста.

Возможные варианты
.etoe — рекомендую

Канонический исходный файл ÆToE:

carbon.etoe
.aetoe

Вариант, подчёркивающий ÆToE:

carbon.aetoe

Плюс — визуально лучше показывает ÆToE.

Минус — менее естественно читается как имя языка/формата.

Я бы его не выбирал основным.

.etoetxt

Не вижу особого смысла.

.txt

Можно разрешить:

carbon.txt

как generic text interchange format, но внутри файл остаётся ÆToE.

То есть:

.etoe   canonical
.txt    generic transport
.etoe.txt

Интересный компромисс:

carbon.etoe.txt

Но я бы оставил его только для систем, которым действительно требуется .txt.

1. Для будущих сериализаций я бы разделил расширения

Это может пригодиться непосредственно для вашей симуляции:

carbon.etoe       ← человекочитаемый исходный ÆToE
carbon.etoe.json  ← AST / machine interchange
carbon.etoe.yaml  ← метаданные / конфигурация
carbon.etoe.md    ← документация

Но .etoe должен означать именно канонический текст ÆToE, а не произвольный JSON/YAML-контейнер.

12. Моя предлагаемая модель ÆToE 0.2

Я бы сейчас заложил такую архитектуру:

                   ÆToE language
                        │
          ┌─────────────┴─────────────┐
          │                           │
   canonical notation            source file
          │                           │
  ether-statement              ether-file
          │                           │
       notation             ┌─────────┼─────────┐
                            │         │         │
                         comments  statements  layout
                                      │
                                      ;
                                      │
                                    AST
                                      │
                              semantic validator

И тогда:

...

является уже не просто «списком строк», а формальным ÆToE source file.

Мой итоговый выбор

Я бы зафиксировал:

//  канонический однострочный комментарий
/* */  канонический многострочный комментарий
#   совместимый альтернативный однострочный комментарий

;   обязательный терминатор ether-statement в ether-file

.etoe  каноническое расширение файла ÆToE
.txt   допустимый generic-text контейнер

И особенно важно: ; не должен входить в ether-statement. Он должен принадлежать уровню ether-file / ether-statement-list. Это сохраняет очень чистое различие между самим эфирным утверждением и способом его хранения в исходном файле.

Это изменение, на мой взгляд, стоит внести в спецификацию до дальнейшего расширения Lark-парсера, потому что тогда следующий парсер можно будет сделать уже не «парсером отдельных выражений», а полноценным ÆToE source parser: comments → statements → AST → semantic validation, сохранив при этом совместимость со старым форматом 2018 года.

:) ну, да, логично - "*.etoe"...

ChatGPT, кстати, а EBNF позволяет задать формат comment своими правилами?

Автор: ChatGPT

Парсер эфирного утверждения в ÆToE (2026-10-03).

https://chatgpt.com/share/6ac1f676-8338-83ea-9615-8c437ff5f1ce

Да. EBNF вполне позволяет описать формат комментария собственными правилами. Но здесь важно различать две вещи: EBNF может формально задать синтаксис комментария, а вопрос о том, является ли комментарий частью AST или просто игнорируемым оформлением, уже относится к архитектуре парсера.

В вашем EToE.md сейчас вообще нет отдельного правила comment: грамматика начинается с ether-statement = notation ;.

Например, комментарий # ...

Можно определить его совершенно обычным EBNF-правилом:

comment
  = "#", { comment-char } ;

и затем определить допустимые символы:

comment-char
  = ? любой символ, кроме конца строки ? ;

Тогда:

# comment

становится формально синтаксически определённым объектом языка.

Для // аналогично:

line-comment
  = "//", { comment-char } ;

Для многострочного:

block-comment
  = "/*", { block-char }, "*/" ;

Однако здесь возникает важная техническая деталь: «все символы до первого */» не всегда удобно и однозначно описывать чистыми ISO-EBNF-продукциями, особенно если хочется строго запретить преждевременное завершение. Для таких лексических конструкций вполне нормально использовать специальную последовательность ? ... ?, то есть передать конкретное лексическое правило lexer'у.

Для ÆToE я бы сделал так

Не включал бы comment внутрь:

ether-statement = notation ;

а ввёл бы уровень исходного файла:

ether-file
  = { source-item } ;

source-item
  = ether-statement, ";"
  | comment ;

comment
  = line-comment
  | block-comment ;

line-comment
  = hash-comment
  | slash-comment ;

hash-comment
  = "#", { comment-char } ;

slash-comment
  = "//", { comment-char } ;

block-comment
  = "/*", ? block-comment body ?, "*/" ;
 
  И тогда:

# comment
C-(Be'He);
C-(C'H);       // comment
C-12-(8'4);

имеет формальную структуру:

ether-file
├── comment
├── ether-statement
├── ether-statement
│   └── comment
└── ether-statement
А вот ; я бы тоже описал именно на этом уровне

Это хорошо согласуется с вашим старым форматом:

C-(Be'He);
C-(C'H);
C-12-(8'4);

Тогда:

ether-file
  = { source-item } ;

source-item
  = comment
  | ether-statement, ";" ;

Само:

ether-statement
  = notation ;

остаётся без ;.

Это, на мой взгляд, гораздо чище, чем делать что-либо вроде:

ether-statement = notation, ";" ;

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

И ещё один важный момент

EBNF не имеет магического понятия «комментарий, который игнорируется».

Если написать:

comment = ... ;

то comment просто становится обычной синтаксической конструкцией.

А вот семантика:

«парсер распознаёт комментарий, но не включает его в AST утверждения»

задаётся уже конструкцией всей грамматики или реализацией lexer/parser.

...
Для Lark это будет очень естественно:
...

Тогда Lark действительно распознаёт комментарий, но удаляет его из дерева синтаксического анализа.

А можно не делать %ignore COMMENT, а написать:

source_item: ether_statement ";" | COMMENT

и тогда Transformer сможет сохранить комментарии в AST файла.

Поэтому ответ на ваш вопрос — да, и я бы как раз рекомендовал формально описать комментарии в EBNF ÆToE, если новая спецификация должна определять не только синтаксис одного ether-statement, но и полноценный формат исходных файлов ÆToE.

При этом я бы явно разделил:

ÆToE notation
    ether-statement

ÆToE source syntax
    ether-file
    source-item
    comment
    statement terminator

Это даст очень хорошую архитектурную основу для вашего нового Lark-парсера.

:) ok...

[Дмитрий Мотовилов]