OberonCore

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

Наверно, лучше, чтобы какие-то тезисы были озвучены на форуме - какие изменения и зачем.

Первое, что бросается в глаза - это кодировка. На мой взгляд, не стоило использовать какую-либо, кроме Utf-8, а досовскую и подавно.

Не возьмусь прям так сходу более-менее красиво дать комментарии, но тем не менее.

На текущий момент практически не существует в РФ (СНГ) полноценных языков программирования, не перегруженных стрёмной семантикой и синтаксисом. Ещё больше языков на выходе кодогенератора которых -- получается нечто стрёмное и непредсказуемое.

Уже много было сказано, что при переводе с английского на русский тратится от 5 до 30% ресурсов мозга на попытку осмыслить а что же это значит? Паронджанов, Ткачёв об этом тут как-то упоминали. И многие представители профильных организаций минпрома СССР были бы, мягко говоря, сильно удивлены узнав, что в РФ ПО разрабатывается не на русском языке.
Как косвенное следствие такого положения вещей -- я не могу назвать даже малоуспешную операционную систему выполненную в РФ. Языковой-семантический барьер!! Напротив, Запад демонстрирует нам Windows, Linux, Unix, даже "Колибри" имеет ноги из скандинавского любительского проекта. Стыдно!!

Оберон интересен тем, что прост. Создать кодогенератор -- это вполне посильная задача, опыт Антона Кротова, Александра Ширяева, парочки человек из-за бугра какбы_намекаэ.
Прикрутить к исходному лексическому анализатору -- я в этом особых проблем не вижу. Создать мета-операционное окружение для такого языка также не должно быть невыполнимой задачей.

А дальше посмотрим, какие качества будет способен дать язык программирования с полноценной поддержкой русского языка. Разведка боем)

Кодировка -- это дешёвое решение нормального вывода в консоль русского текста. Времени всегда мало, пришлось выбирать меньшее из двух зол. В рамках ЯП с полноценной поддержкой русского языка -- английский является злом)) С UTF-8 задача сильно усложняется. Лично мнение: реализация расширенного набора литералов в форме UTF-8 крайне неудобна при обработке строк. В крайней случае уникод.

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

Ответ не верный. В UTF-8 есть несколько видов пробелов, табуляций и всяких разделителей. Ширина литеры может плавать от 1 до 6 байт/
Пруф: "UTF-8 (от англ. Unicode Transformation Format, 8-bit — «формат преобразования Юникода, 8-битный») — одна из общепринятых и стандартизированных кодировок текста, которая позволяет хранить символы Юникода, используя переменное количество байт (от 1 до 6)." https://ru.wikipedia.org/wiki/UTF-8
Таким образом лексический анализатор пришлось бы усложнить на десятки процентов. Это существенно. Речь шла о быстром решении.
Впрочем, компилятор переваривает UTF-8 с исходным текстом на английском языке и русскими комментариями...

Алгоритмы с многобайтовыми кодировками сложны. Тут куда легче использовать кодировку принятую в Веб. Через амперсанд и специализированное описание. Либо, как частное решение -- вводить типизацию для текста в виде управляющих тэгов (метаинформации):

1. Вы не обязаны в лексическом анализаторе поддерживать разные виды пробелов и т.п, можете выдавать сообщение, что символ недопустим.
2. Для лексического анализа не важно однобайтная кодировка или такая многобайтная, как Utf-8, потому что анализатору не важно, сколько символов видит человек, ему важно идентичность используемых цепочек, что в нормализованном Utf-8 легко обеспечить, а больше и не нужно.

Обязан. Человек -- это обезъяна с гранатой. А если ещё и цейтнот -- это обезьяна с атомной боеголовкой.



Ошибочное утверждение. Тип CHAR -- 8 бит. И для лексического анализа критически важно, сколько в символе байт. Правда, действительно, в независимости от того, сколько видит человек.
Нормализовать UTF-8 -- это дополнительный контракт по языку. Я не помню такого требования в описании языка.
Типизация текста вполне справляется с этой задачей.

Для меня фраза "Надёжность -- превыше всего" поднята на щит.

Зачем? Давным-давно я делал лексический анализатор с поддержкой русского в кодировке Utf-8 и не было никаких проблем.
В принципе, если Вы ограничиваете транслятор платформой Windows, то можно и не волноваться по этому поводу, но тогда, пожалуйста, напишите об этом в about2.pdf.

)) Прекрасно. Будьте любезны предоставьте Ваш лексический анализатор в публичное пользование вместо предложенного Антоном Кротовым?!))
Не вижу, каким образом кодировка компилятора не позволит ему работать под другими операционными системами? Неужели локаль отменили?))

Если честно, я ожидал замечаний и предложений более по компилятору, чем по кодировке. Пока кодировка -- это даже не задача второй очереди)))

Валера, это ты хорошо придумал. А для Линукса как собрать компилятор? А как думаешь, сложно этот компилятор на Блэкбокс перенести?

Важно, что у Вирта в определении языка не сказано сколько бит должен быть тип CHAR

Коллеги, UTF-8 можно парсить полностью забив на его содержание.
Просто считать все отрицательные байты видимыми символами и все.
Даже последовательности байт можно не разбирать.
Пишите лексер так, будто это и не UTF-8 вовсе. Все будет прекрасно работать.

1) Перекодировка даже руками через Geany -- делается. Можно и скриптом рискнуть. Пока не актуально, под линь файлы не собираются, надо прикручивать elf-компоновщик. Поэтому... В лучшем случай wine)) Необходимость именно такой кодировки -- это компромис.

2) Я прикидываю план переноса под ББ. Теоретически, нужно только заменить операции чтения и записи файлов для поддержки английского языка. Если речь идёт о полностью двуязычной поддержке, то надо лезть в компиль КП. Тут я пасую. Залезть могу, но только испорчу (вероятность под 90-95%).

Сегодня немного побеседовал с Ильёй, я согласен и с ним, и с Ф.В., и с Ваней: КП/ББ это оптимальный вариант для практики. Но Оберон подкупает своей простотой. Абстрактных типов не хватает, а вот специфическая привязка процедур к типам в КП... Ну, я бы не расстроился, если бы стиль вызова был чисто процедурным. Я готов пойти на отказ от стиля КП по методам, но не готов отказаться от расширенной типизации КП)))

У Вирта вообще разрядность ни по каким типам не определена, и я этого хода не понимаю. Толи, он разрешает дать привязку под реализацию железа, то ли что?

Посмотрим, тут пока и кости то не все.) Пока это отчаянный эксперимент по привитию любви к великому и могучему с прицелом на создание не протекающих абстракций )) Или, по определению Ткачёва концепции "Интеллект-2". Имхо, с английским из его же определений -- задача усложняется на не знаю сколько. Порядок-два. Запросто.


Ох... Примерчик бы для деревенских))

Что же вы так все на кодировку налегли?)))

В чём проблема UTF-8?

В коде компилятора есть несколько мест, где идёт проверка на допустимые символы. CHAR -- 1 байт. КОНСОЛЬ не понимает другие кодировки, хотя есть способ заменить консоль на другую локаль. Не помню, можно ли сделать это временно. Попробую. Пока ничего не обещаю)))

1. Анализатор был сделан в рамках проекта для компании и прав на него у меня нет.
2. Пользы от него всё равно было бы мало, так он был написан на Си и не для Оберона.
3. У меня есть желание сделать подержку русского в моём трансляторе Оберона, но, так как, для меня это не приоритетно, то будет это не скоро, если вообще будет.
4. Иногда достаточно информации, что что-то возможно, чтобы его воплотить.

Где Вы увидели слова "не позволит"?
Как Вы думаете, почему мне бросилась в глаза кодировка? Открываю в редакторе - а там каракули, и сделать так, чтобы с этой кодировкой было удобно работать - непросто.

Кодировка стопорит остальное.

Если ещё один плюс будет в карму кодировки -- ну так и быть. Изволю напрячь мозг)))

https://github.com/prospero78/Oberon07ru

Замечательный материал.
Кодировка должна интересовать нас не в первую очередь. Перед нами кросплатформенный компилятор Оберона-07, написанный сам на себе. Что ещё нужно? Теперь любой может его редактировать и улучшать, вливаться в работу.

"ДЕК" это наверное декабрь. А вот что такое "ИЛЕСЛ"

))) Декабрь -- это ДКБ, а ДЕК -- это антипод ИНК. Кстати, ВОТ ОНО!! Полезли смыслы по Ткачёву!! ИЛЕСЛ -- ИЛИ ЕСЛИ (ELSIF). Кстати, в about2 было всё написано))