Сергей, да, можно и внутри системы хранить и обрабатываеть текст в UTF8, однако авторы системы Оберон (сам Вирт или кто-то ещё) приняли решение, что тексты будут храниться в UTF32. Да, при этом типа симв32 (CHAR32) в Обероне нет и код в A2 выглядит так:
Код:
MODULE Texts;
...
TYPE
UCS32String* = ARRAY OF SIGNED32;
PUCS32String* = POINTER TO UCS32String;
Char32* = SIGNED32;
Поскольку решение не моё, то я и защищать его не стану. Вопросы следует адресовать к авторам решения. Итак, для текстов это представление есть. Если я правильно понял, Вы предлагаете декодировать 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Код:
CharJQ* = RECORD UCS32CharCode- : UNSIGNED32 END;
Вы тоже назвали её ненужной. Вы сказали, что будете ждать реализацию юникода от более правильного Феликса или не помню от ещё кого там. Сегодня Вы пишете, что юникод есть, но не в репозитории. Т.е. у кого-то юникод уже есть, а у остальных возможно его никогда и не будет. Поскольку ситуация "у кого-то там в Цюрихе всё работает" повторяется уже не первый раз. В этом свете идея "участвовать в разработке A2" выглядит абсолютным тупиком, а форк - единственным выходом для того, кто хочет действительно развивать A2. Поэтому мой совет всем, кто ждёт что-то от швейцарской команды - не ждите. Если хотите развивать A2 и Вас не устраивает ЯОС - то делайте свой форк. Когда напишете недостающие части - предлагайте швейцарской команде включить ваш код в A2. Если они согласятся - хорошо, если откажутся - Вы не будете хотя бы находиться в тупике, а будете пользоваться своим форком.
Как итог: у меня уже давно есть симв32 как отдельный тип в виде записи (внутри записи - целое число, но этот тип нельзя перепутать с целочисленным - ведь у нас же типизированный язык, а запись нельзя присвоить числу и наоборот), а теперь появился и встроенный тип симв32, который в отладке выводится как текст. А в A2 для пользователей нет ничего, хотя ничто не мешало за полтора года найти время и взять мой код. И возможно не будет, поскольку политика "у нас есть, но вам не дадим" у команды A2 является последовательной, я могу привести и другие примеры. Если мой код даже где-то не работает (хотя я в последний год с ним никаких проблем не припомню), то его можно было бы поправить.