OberonCore

Зачем всё это? Я делал то же самое на UTF-8 без всяких заморочек. Писал об этом в телеграме - для добавления национальных идентификаторов в компилятор почти ничего не нужно делать.

А это не компилятор, а лексер для редактора (бывший TFPET). В современной A2 (не путать с ЯОС) лексер BimboScanner по-прежнему присутствует и по-прежнему от текста он получает UTF32, хранящиеся в INTEGER-ах. Далее INTEGER (который на самом деле симв32) каким-то волшебным образом деградирует до CHAR, и последовательность CHAR-ов разбирает лексер. Вот фрагмент лексера:


Если мы предположим, что нам нужно разбирать ключевые слова на русском языке, как в этот код добавить обработку этих слов?

Также интересно, зачем в A2 пытались добавить типы CHAR16 и CHAR32 и почему их дальнейшая судьба не сложилась? Также вопрос "зачем" следует адресовать авторам ББ и авторам Windows, которые не поленились добавить в свои изделия более одного символьного типа.

Приблизительно так

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

Я бы сказал, что второсортность определяется комплексами по этому поводу. Если Вас это так беспокоит, можете сделать возможность работы со строками в CASE, как когда-то предлагалось, а кое-где и было реализовано, если правильно помню. Ну, ещё можно заменить "А" на 41X, чтобы неповадно было.

(* Если исходный код в utf8 *)

Я не хочу программировать в таких системах, где от кодировки исходного кода зависит смысл программы. Брр. Был ад кодовых страничек, когда журналист не в той кодировке сохранял txt на дискету, а редактор ничего не мог прочесть, ругался, бился головой о стену; а тут я, такой юный компьютерщик, появлялся с каким-то хитрым перекодеком, переподковывал их блоху, и всем приходило адское счастье. И я с надеждой читал какой-то глянцевый журнал про то, что вот скоро выйдет волшебная NT, а в ней будет чудесный UNICODE, которого на всех хватит, и будет рай на месте ада.
В итоге поменяли ад кодовых страничек ASCII на ад кодировок UNICODE. Я хочу отгородиться от него, насколько возможно. Вы обосновываете усложнение языка и компилятора тем, что хотите txt любой кодировки понимать?

В КП договорились, что программа представлена в UNICODE 0X..0FFFFX. Этим сняли ряд проблем (задач) с компилятора.

В КП нет перегрузки операторов. Если сравнивается Shortstring и String, это известно компилятору, и он синтезирует соответствующий машинный код.

Мне не нравится тип SHORTCHAR и ARRAY OF SHORTCHAR, я бы все сделал на CHAR, ARRAY OF CHAR, а SHORTCHAR отправил бы в SYSTEM для системных программ; и то не факт, что нельзя обойтись BYTE для всяких системных целей, наэн можно.
Собсно, в ББ почти так и сделано: повсеместно используется CHAR, а устройства для чтения-записи предусматривают и процедуры для ShortString.

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

А можно было договориться до UTF-8 и ничего принципиального в плане проблем бы не добавилось. Важен сам факт договорённости

Но справедливости ради отмечу, что в ББ тоже слегка накосячили, кмк, когда переходили на двухбайтные литеры.
В формат OCF (загружаемый модуль в машинных кодах) заносятся разные имена из модуля, а при загрузке эти части формата копируются в память ЭВМ и никак не интерпретируются, т.е. они в формате как образ памяти. То ли хотели память ЭВМ сэкономить, то ли размер файлов уменьшить, то ли двоичную совместимость сохранить (но с чем?) - не знаю, но решили в формате на двухбайтные не переходить, а вместо этого писать туда однобайтный utf8.
Но поскольку эти данные из формата оказываются в метаданных модуля, их обслуживает ядро - пришлось перекодировщики вUtf8-16-8 втягивать в ядро. И так там наряду с достойными задачами появился перекодировочный хлам.

А, возможно, просто чтобы слегка сократить объем работ это дело отложили - это было, пожалуй, крупнейшее изменение в ББ за много лет.

Если бы до UCS32 договорились - то да, не добавилось бы. Важен факт договоренности.
Но если бы договорились до UTF8 - то проблем бы прибавилось. Вот в вашем примере есть PrevChar, которая не нужна, когда всем литерам входного алфавита соответствует одно число байт.
А ведь еще нужно обрабатывать возможность некорректных литер UTF8!

Ну что значит, беспокоит? То, что Вы привели, годится только для соревнования по умению программировать. Для программирования как ремесла это ни в какие ворота. Предложите такое решение 1С-никам - узнаете про себя много нового. Собственно, с помощью типа симв32 и его литералов у меня всё то же самое сделано по-нормальному, я уже приводил примеры, как. И в том же 1С символьный тип - это не UTF-8 (он там один, но не знаю какой, хотя теперь может и не один). Зачем делать уродливо, если уже есть нормальное решение? Ради догмы минимализма?

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

Кстати, я посмотрел - в 1С тоже пишут и ищут программки перекодировки. Но когда я лично работал с 1С, я не припомню, чтобы приходилось с этим сталкиваться. Видимо, тогда был везде ANSI (т.е. виндовая кодовая страница), или можно было указать кодовую страницу (например, от DOS) при открытии файла. Во всяком случае, длина строки в 1С - это количество кодовых точек юникода, а не количество байт, т.е. там внутри не UTF-8.

Я специально выделил слово "принципиального", чтобы не было придирок. PrevChar или его заменители - это штатная особенность сканера при распознавании неоднозначностей вроде 1.2 1..2, то есть, ничего принципиально нового не вносится - стандартная работа.
Разрешать некорректные и ненормализованные символы транслятору тоже не нужно - это делается внешними инструментами.

Суть же в том, что исходник будет сохранён не в UTF-32 или UTF-16, а в UTF-8 и сканер без особых проблем может работать с этим исходным кодом без какой-либо предварительной перекодировки, так как UTF-8 хорошо продумана. И реализовывается сканер один раз, после чего вы работаете без дополнительных мыслей о кодировке.

К слову, 32-битные литералы можно воплощать не как UTF-32, а как всё тот же UTF-8 и тогда преобразование строк туда и обратно можно делать с минимальными издержками, так как отличие будет лишь в выравнивании. Единственно, на little endian просядет скорость сравнения литер на <>, но не на =, и с ORD и CHR придётся повозиться

Вот так договорились за уникод, а потом - бац! - вторая версия.

Нет разницы, я адаптировал сканеры и для редакторов.

Никак не деградирует - конвертируется в строку UTF-8. FoxScanner также успешно работет и с файлами и с текстом.

Конкретно в этом модуле русская буква будет считаться строкой, соответственно CASE нужно заменить на IF.

"Пытались" это сильно сказано. Изначально это были алиасы для INTEGER(16 бит) и LONGINT(32 бит). Никакой полезной нагрузки не несли. Можно посмотреть, какие операции производятся над unicode code point, чтобы понять - это скорее числа, чем символы. Тогда нужно вводить соотвествующую алгебру для символьных типов. Получим те же самые числа. Или не вводить и получим громоздкие мало понятные вычисления и приведения на ровном месте. При добавлении CHAR16/CHAR32 ровно так же нет никаких гарантий, что там не мусор. Потому что в Обероне нет диапазонных типов. Единственный плюс может быть в строковых литералах. Но они сейчас ни для чего не нужны. Пока в а2 нет unicode библиотеки (она как бы есть, но в репозитории её нет), вводить char16/char32(что бы под этими типами ни подразумевалось) преждевременно. Достаточно алиасов.

Сергей, да, можно и внутри системы хранить и обрабатываеть текст в UTF8, однако авторы системы Оберон (сам Вирт или кто-то ещё) приняли решение, что тексты будут храниться в UTF32. Да, при этом типа симв32 (CHAR32) в Обероне нет и код в A2 выглядит так:



Поскольку решение не моё, то я и защищать его не стану. Вопросы следует адресовать к авторам решения. Итак, для текстов это представление есть. Если я правильно понял, Вы предлагаете декодировать UTF32 в UTF8 и в таком (менее удобном, как мы только что видели по коду Константина) парсить. Это, конечно, можно, но, UTF32 - более удобное для обработки представление, чем UTF-8, и текст уже представлен в этом виде. Логично его в таком же виде и парсить, вместо того, чтобы встраивать в парсер какие-то куски для учёта особенностей UTF-8. Конечно, если уже есть работающий парсер, который понимает UTF-8, может оказаться легче так перекодировать, но мы видели, что такой парсер содержит костыли - он обрабатывает не текст (кодпоинты), а байты, из которых составлен UTF-8, и в него вплетён код раскодировки UTF-8. Это всё некрасиво, хотя и жизнеспособно.

Переходим к следующему вопросу. У нас уже есть UTF32, это данность, которая от нас не зависит. У модуля текст десятки, если не сотни клиентов, и всем им нужен тип Texts.Char. Нужен ли в этих условиях отдельный тип симв32/CHAR32, отличающийся от цел32/SIGNED32? Да, нужен, и вот для чего. В строках обычно находится информация для чтения человеком. Зная, что это текст, его можно вывести, к примеру, на красном экране. Отличие между массивом симв32 и массивом из SIGNED32 ясно видно на картинке. Работая с массивами из симв32, мы на красном экране видим сам текст, а работая с тем же текстом, но представленном в виде массивов из а2-шных Texts.Char, которые есть SIGNED32, мы видим только сообщение "NO STRING". Очевидно, видеть текст удобнее, чем не видеть его. Одного этого достаточно, чтобы ввести тип симв32. Если же видеть текст не нужно, то давайте и тип CHAR выкинем - ведь CHAR - это тоже число по сути, и все действия над ним можно представить как действия над числами.

Далее, я не знаю, что Вы понимаете под Юникодной библиотекой, но, как минимум модуль StringsUCS32 существует в ЯОС уже как минимум полтора года, и я Вам об этом говорил. Вот, например, версия от 20.05.2020:

https://gitlab.com/budden/ja-o-s/-/blob ... sUCS32.Mod

На тот момент встроенного типа симв32 не было, а была такая вот запись:

https://gitlab.com/budden/ja-o-s/-/blob ... 32.Mod#L14


Вы тоже назвали её ненужной. Вы сказали, что будете ждать реализацию юникода от более правильного Феликса или не помню от ещё кого там. Сегодня Вы пишете, что юникод есть, но не в репозитории. Т.е. у кого-то юникод уже есть, а у остальных возможно его никогда и не будет. Поскольку ситуация "у кого-то там в Цюрихе всё работает" повторяется уже не первый раз. В этом свете идея "участвовать в разработке A2" выглядит абсолютным тупиком, а форк - единственным выходом для того, кто хочет действительно развивать A2. Поэтому мой совет всем, кто ждёт что-то от швейцарской команды - не ждите. Если хотите развивать A2 и Вас не устраивает ЯОС - то делайте свой форк. Когда напишете недостающие части - предлагайте швейцарской команде включить ваш код в A2. Если они согласятся - хорошо, если откажутся - Вы не будете хотя бы находиться в тупике, а будете пользоваться своим форком.


Как итог: у меня уже давно есть симв32 как отдельный тип в виде записи (внутри записи - целое число, но этот тип нельзя перепутать с целочисленным - ведь у нас же типизированный язык, а запись нельзя присвоить числу и наоборот), а теперь появился и встроенный тип симв32, который в отладке выводится как текст. А в A2 для пользователей нет ничего, хотя ничто не мешало за полтора года найти время и взять мой код. И возможно не будет, поскольку политика "у нас есть, но вам не дадим" у команды A2 является последовательной, я могу привести и другие примеры. Если мой код даже где-то не работает (хотя я в последний год с ним никаких проблем не припомню), то его можно было бы поправить.

У Вирта вообще ASCII был

В A2 по умолчанию тексты в utf-8 хранятся. А с наличием системы кодеков это вообще не проблема. Можно работать с любыми мыслимыми кодировками. Всё перекодируется "на лету"

У системы Оберон много версий. Одна из них встроена в A2 - насколько эта версия основная и кто её делал - я не знаю. Это файлы Oberon.*.Mod (из ЯОС я их выкинул, возможно, что и зря). Структуры данных для текстов описаны здесь: https://github.com/metacore/A2OS/blob/m ... .Texts.Mod , в конце файла есть пояснения. Я так понял, текст там состоит из абстрактных объектов, но не ASCII. Когда в прошлый раз читал, мне показалось, что там поддерживался юникод. Вероятно, я ошибся.

Но если он и не поддерживается, то не суть. В A2-то он есть в модуле Texts.

Никто же не знает, какая у вас там сейчас стадия. Может это просто ваш очередной эксперимент с КОИ-7