OberonCore

Хорошо, что Вы начали выдергивать цитаты из контекста. Значит, по сути-то дела ничего сказать не получается. Полностью моё высказывание звучит следующим образом:

Дальше:

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

P.S. 151 процедура переведена. Итого 23 за сегодня. Правда, удалось довольно долго посидеть.

Произошли, можно сказать, тектонические изменения. Я нашёл человека, который тоже заинтересован в создании отечественной ОС. Впрочем, он человек занятой, и не факт, что ему понравится вся эта оберонщина, но он сразу внёс несколько новых мыслей. Одна из них состояла в том, что зачем ББЦБ, если есть A2 и Project Oberon. У меня этот вопрос висел в очереди. На самом-то деле, не нужна система, завязанная на WinAPI или X Window - обе эти системы весьма сомнительны с точки зрения анализа безопасности. Но вчера я загрузил эмулятор A2 и сразу увидел, что редактор там гораздо лучше, чем в Блекбоксе. Например, в A2 есть подсветка синтаксиса и изображение перечня определений слева от текста. Отсюда я делаю вывод, что Блекбокс просто был брошен на ранней стадии разработки, а не то, что "так сделано, потому что так надо", или же он был рассчитан на какие-то совсем скромные компьютеры, которые не могут потянуть более сложный гуй.

Интерфейс A2 на вид, конечно, «вырви глаз», но за счёт интеграции файловых систем можно пытаться подгрузить тот же VS Code и править исходники извне среды.

Я почитал исходники компилятора. A2-шный компилятор так же безобразен, как ББЦБ, а в проекте Оберон, как мне показалось, была произведена определённая работа в направлении понятности кода и приведении его к более общепринятым обозначениям. Но проделанная работа по переводу может быть повторно использована, т.к. коды всех трёх компиляторов похожи. Отсюда следует вывод, что ручной перевод неэффективен - нужен внешний словарь переводов и инструмент, который автоматически этот перевод применяет.

По сути это похоже на рефакторинг на уровне «переименуй поле объекта». Для этого нужна определённая инструментальная поддержка. В «Яре» я сделал кое-что - у меня есть парсер-линза. Может быть, удастся в сжатые сроки переделать Яр в "недооберон", который останавливается на дереве кода, в котором разрешены все ссылки на поля и функции. Тогда его и можно будет использовать как инструмент рефакторинга. Вероятно, что и клиент-серверную IDE, если до неё дойдут руки, надо будет делать на базе clcon, а не на базе Visual Studio Code.

Посему сегодня я занимался в основном лиспом - восстанавливал рабочее состояние «яра». Завтра на работу. На некоторое время, видимо, затихну, к радости тех, кому моя тема мешает своим постоянным всплытием А там - кто знает, чем всё закончится? Вдруг мне понравится вот это? https://github.com/froggey/Mezzano . Тогда вообще от вас уйду.

В А2 2 компилятора, 1) PACO, основанный, как и компилятор ББ, на проекте OP2 ( кстати OP2, достаточно хорошо описан ), и 2) новый FOX, который написан с нуля и там всё понятно, достаточно посмотреть в исходники

Спасибо, особенно за пункт 2

> кстати OP2, достаточно хорошо описан
Где? Это? http://obertone.ru/_media/bb/op2.paper.pdf и http://obertone.ru/blackbox/dev ?
Это не достаточно хорошо, это только азы. Даже предназначение модулей не раскрыто, во всяком случае, в применении к ББЦБ этой инфы явно недостаточно. Хотя кстати да, там есть кое-что про те поля, которые я ещё не изучил. Но и там не всё хорошо написано. Например, вот такой комментарий: (* imported from module mno *). Я-то теперь примерно догадываюсь, что такое mno, но это нужно было читать код и сопоставлять разные его (некомментированные) куски между собой.

Нет не только единой терминологии, нет даже единой, однозначно интерпретируемой деятельности как "классификация". Если вдруг интересно почему (по второй ссылке -- диссер автора статьи):
https://www.rpri.ru/arshinov/materials/4ebanov/iz%20historii.html
http://www.textreferat.com/referat-7365.html

Не в курсе, как там в компиляторе типы классифицируются, но на всякий случай. В программировании имеется общепринятое понятие типизации с некоторой классификацией типов, в т.ч. существует и понятие их рода:
https://ru.wikipedia.org/wiki/Тип_данных
https://ru.wikipedia.org/wiki/Род_(теория_типов)

Речь о классификации не типов, а сущностей в самом компиляторе. В т.ч. и типов. Насчёт рода типов - я вижу, что молодёжь сейчас лучше знает Хаскель, чем не знаю его я. В науке, как известно, новая вера приходит с новым поколением. Я принадлежу к поколению до Хаскеля, и вряд ли даже на смертном одре побегу туда креститься. Так что не общепризнано

Не стоит по себе судить людей.

Напомню начало нашей беседы:




Я вам говорю о простом: перевод переменных не имеет смысла. Хотите-занимайтесь. Но смысла в этом нет. У вас всё остальное уже реализовано?
Есть хорошая среда разработки? Есть библиотеки со стандартными алгоритмами? Оно запускается на Байкале? Там есть криптография?
Если всё это есть, то, конечно, можно и перевести переменные в компиляторе.

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

> Если всё это есть, то, конечно, можно и перевести переменные в компиляторе.

Смысл перевода - в попытке найти новые кадровые ресурсы взамен отъезжающих. Зарплаты в Байкале и Эльбрусе лично мне, к примеру, пока не интересны - я у американских работодателей больше зарабатываю. Пока. Завтра всё может поменяться. Т.е. я здесь, но в рабочее время я уехал в америку.

И я знаю, что многие создатели Эльбруса уехали в США. И некоторые мои знакомые уехали в США в последние 3-4 года. И я хочу поставить языковой барьер на пути этого процесса. Пусть те, кто хочет уезжать, изначально не идут работать на российскую военку. Для этого программирование, связанное с обороной, нужно перевести на РЯ. Это не создаст непреодолимой преграды, но создаст существенные затруднения. И плюс к тому, через русификацию ИТ можно поднять и статус русского языка. Но правда это никому не нужно, т.к. везде сплошная пятая колонна, которая только и мечтает сдать страну. Или, так скажем, почти никому.

Кроме того, мне не нравятся ни Байкал, ни Эльбрус. Эльбрус мне технически не нравится, а Байкал - своей ориентированностью на мировые рынки. Что будет там, мы прекрасно уведели на примере Касперского у Хуавей. А они хотят и рыбку съесть, и дальше сами знаете что. Меня интересует та организация, которая ставит своей целью защиту России, а не выход на мировые рынки. Но в такую организацию меня пока никто работать не приглашал. Есть лоббисты издающегося в США Линукса (Линукс - это своя отдельная религия, и я думаю, что линуксоидам в среднем линукс дороже России, хотя, конечно, не всем) и есть вот такие, типа Байкала, которые ждут, пока их скупят, чтобы уехать с нашими секретами на кратно бОльшую зарплату. И потому у них вакансия технического писателя на английском языке, вот она:

https://hh.ru/vacancy/27020697?utm_medi ... 62;organic

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

> Гораздо полезнее тратить время и деньги не на перевод переменных, а, скажем, на создание среды программирования в которой переименование всех использований переменной делалось бы на раз

А почему Вас так волнует, на что я трачу своё время? Вы за своё время волнуйтесь. Конечно, после того, как я понял, сколько разных оберонов есть, и что у них родственный код, я понял, что именно такую среду и придётся сделать. Но это не отменяет нужды в переводе. Среда с переименованием - это всего лишь инструмент для того, чтобы сделать этот перевод быстрее. Но не нужно путать инструмент и работу, для которой он нужен. В случае ББ, имена переменных представляют из себя никому не понятные аббревиатуры. Даже тем, кому противен вид родного языка, нужно их как-то переименовать во что-то понятное. Я же к русскому языку отношусь хорошо, поэтому если и буду что-то переименовывать, то на русское.

И теперь стоит задача создать такую среду, прорабатывается два варианта - либо сделать её на базе A2 (в которой, кстати, компилятор Fox изначально гораздо лучше написан, судя хотя бы по структуре исходников и по беглому взгляду на них), или делать на базе моей старой разработки Яр, которую я достал из помойки на днях.

Если бы был только ББ, то я бы и руками его допереименовал. А сейчас я не знаю, что делать - есть как минимум проект Оберон и A2, в которых есть родственные компиляторы с пересекающимися исходниками. Конечно, в этом случае ручная работа теряет смысл.

> Если всё это есть, то, конечно, можно и перевести переменные в компиляторе.

А перевод компилятора нужен для того, чтобы внести в Оберон то, чего там явно не хватает. В A2 я тоже вижу вписанные прямо в код операции над односвязными списками. Так программировать нельзя. В языке не хватает средств типа шаблонов, макросов, чего угодно, чтобы избежать ручного выписывания поиска по Б-дереву, сортировки, работы со списками. Такие практики ничего общего с надёжностью не имеют. В семидесятые это было нормой, а сегодня за это на любой работе руки отрывают.

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

Но с момента, как я узнал про FoxCompiler, планы поменялись, т.к. может оказаться, что там более понятный компилятор. Если так, то перевод компилятора вообще будет снят с повестки дня.

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

А значит, нужно просто осваивать A2. Сейчас я ищу и не нахожу аналог функции из ББ "показать исходник". Я знаю, что она в ББЦБ сделана через задницу, но то, что есть, лучше, чем ничего. Не факт, что в более сложном активном обероне этот же подход сработает.

И ещё нужно понять, как отлаживать в A2. Для ББЦБ отладчик есть. Без отладчика я не люблю работать.

Маэстро, завязывайте, пожалуйста, ну не смешно ни разу... ассортимент архитектур "нездесь" и "секреты отсель" - ну соразмеряйте что ли.
Вы про "кролика" не слыхали, нет: разработчик (чуть не сказал производитель) вместо живой микросхемы предлагает лабкит с FPGA - Вирты, блин. Только вот RISC-Oberon это образовательная концепция и лабкит это правильно, а у наших - торговля воздухом.

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

Для США смысл скупать наших производителей состоит не столько в том, чтобы получить эти секреты (Байкал вроде довольно простой), а чтобы Россия не стала суверенной. Государство, работающее на чужом телекоммуникационном оборудовании, разговаривающее по инстранным мобильникам, хранящее свои данные на импортных HDD в импортных СУБД, на сегодня суверенным не является. США нужно разрушить или хотя бы максимально затянуть процесс создания независимой российской ИТ-инфраструктуры, свободной от американских закладок. Поэтому ожидания байкаловцев на то, что их купят, если таковые действительно существуют, вполне оправданы.

Да, Сорокин в "Сахарном кремле" как в воду глядел...

Короче говоря, не то, чтобы этот проект был совсем ошибкой, но близко к тому. Код и интерфейс ББЦБ далеки от моих представлений о хорошем, расшифровка аббревиатур трудозатратна, а сам продукт завязан на неинтересные операционные системы Windows/Linux. Попробуем переключиться на A2.

Репозиторий опять переехал:

https://gitlab.com/budden/nkp

Подправил README, там коротко подведены итоги проекта.

Всем спасибо за участие.

wwwait... а какие интересные? Щ_Щ да и где там прямо уж завязанность кроме хостовых модулей?

ЧТД, очередной Непонявший.

A2OS - это само по себе ОС. А насчёт твоего проекта могу сказать так: пилите, Шура! Как допилите систему с возможностями A2, просигнальте. Рассмотрим всерьёз, невзирая даже на озвученные недостатки ББЦБ.