OberonCore

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

Плюсы, что большинство идентификаторов в бинарниках занимает мало места в однобайтной кодировке. Алгоритмы сравнения работают быстрее для однобайтных строк?

Кто мешает загружать модули разных версий, конвертируя старые "на лету"? Тогда можно держать и старый формат с utf8, и новый с utf16, а внутри все в utf16

Борис, а у вас уже есть какие-то эксперименты? А то может опасения по поводу сложности изменения компилятора напрасны. Может там не так всё плохо?

С моей точки зрения опасения напрасны. Нет, мы ещё таких изменений не вносили.

Ну, если так, тогда и я дам свое видение.

1. Интерфейс Uft8 в ядре не нужен. И понятие Kernel.Utf8 не нужно.
2. Есть проблема SHORT(lstring) и LONG(sstring). По уму, если lstring в кодировке UCS2, то s := SHORT(lstring) должно переводить это в кодировку UTF8. И наоборот, если sstring в кодировке UTF8, то ls := LONG(sstring) должно переводить к кодировку UCS2.
3. Я в LLVM в ядро вставлял процедуры:

для преобразования строк из SHORT в LONG.
Идея из OFront - там это в сишном виде.
4. Предлагаю в Kernel добавить интерфейсы, например, адреса процедур StrcpySL, StrapndSL (append), которые по умолчанию задаются процедурами из Kernel, но могут инсталлироваться из другого модуля.
5. Модуль с реализацией, ну там HostStrings, содержит процедуры конвертации UTF8 <-> UCS2.

Дмитрий Викторович, ваше предложение мне кажется очень рациональным.

UCS2 не нужна, лучше сразу UTF16

Такое изменение семантики SHORT/LONG опасно. Как минимум для старого кода.

А откуда LONG узнает, что sstring в кодировке UTF8?

Я согласен с критическими замечаниями в адрес такого предложения. Попробую аргументацию в свою защиту.
StrcpySL, StrapndSL по умолчанию задаются процедурами из Kernel - то есть обычные преобразования char<->shortchar.

Только для нового кода (1.8 версия) мы прибиваем реализацию HostStrings, где уже фиксируем кодировки. Для совместимости остается дефолтная реализация со старой семантикой.


Любая возможна, нужно только "на берегу" договариваться, какая кодировка у CHAR


Моя схема допускает установка любых перекодировщиков, например, UTF7. Если Вы для Ваших задач хотите использовать другую кодировку для SHORTCHAR - это будет работать. Но не будет совместимо с другими, если они в UTF8. Надо "на берегу" договариваться, что у SHORTCHAR кодировка UTF8

Всё равно не надо такого. SHORT предполагает какое-то урезание (низкоуровневое), а не преобразование. Причём не очевидное.


А в x 7 символов кириллицы. И всё.

Поддерживаю. Но предлагаю все же BlackBox way: Hook с типозависимыми процедурами.

А здесь поддерживаю Бориса. И еще обращаю внимание, что сейчас a: ARRAY OF CHAR и SHORT(a) - гарантированно одного размера, а как изменится размер массива после преобразования кодировок - поди угадай. Кроме того, единственный останов, который может сейчас произойти при SHORT - это value out of range, причем независимо от базового типа массива. А при преобразовании кодировок - чего хочешь, вплоть до "файл не найден" или "iconv сегодня не в духе" - кто из нас может привести исчерпывающий список исключений, которые могут произойти при вызове Host? И вообще, мы привыкли, что слова, написанные прописными латинскими буквами - это надежно и предсказуемо, как гранит; а если спрятать за SHORT обращение к Host... Обращаться к iconv, конечно, надо, это неизбежное зло, но лучше, чтобы было видно, что это не язык и не языковый рантайм.

Про урезание: если включена проверка Value out of range, то SHORT не урезает; он срабатывает без останова, только если значение "влезает" в младший тип. А если не влезает - то будет останов. Поэтому я бы сказал, что это не урезание, а отбрасывание старших незначащих нулей. И его нужно охранять: IF с < MAX(CHAR) THEN s := SHORT(c) ELSE s := SHORT(CHR(ORD(c) MOD ORD(MAX(SHORTCHAR))) END.

Надо, чтобы преобразование было встроено в ядро. Не надо делать для таких низкоуровневых вещей никаких хуков. И без iconv, конечно! Должно быть платформенно-независимое преобразование.
Либо вообще без преобразований, как Борис изначально предложил.

Другие кодировки не нужны

640K ought to be enough for anybody

https://www.opennet.ru/opennews/art.shtml?num=42795
https://www.openbsd.org/papers/eurobsdcon2016-utf8.pdf, стр. 39

И за это тоже, его в аду будут жарить на сковородках без масла...

И правильно, проблемы от избытка. Если б было везде SHORTCHAR (лучше CHAR) с utf8 - не было б проблемы.

На мой взгляд, проблема не в том, что используется UTF8 для кодирования идентификаторов, а в том, что в Strings импортируется реализация UTF8 из ядра. Это временное решение, которое должно быть устранено. Но также импортируются реализации IsUpper IsLower. А они библиотечные! И они также нужны в ядре. И получается, что даже если вы хотите брать только UCS2. То проблема зависимости Strings от ядра не убирается, так как либо надо делать HostStrings, где будут библитечные реализации Upper и т.п., либо оставить так как сейчас их хост-зависимые библиотечные реализации в ядре. Это важные момент. Никто не хочет писать свою реализацию Upper и Lower для всех известных языков? Если кто-то напишет, то давайте включим это в Strings и тогда можно будет убрать зависимость от ядра.

А в целом как внутренняя реализация UTF8 очень удобен, внутри рантайма везде используется экономичный SHORTCHAR. А парсер и средства отладки работают с UCS2.
Более логичным был бы дальнейший переход на UTF8, так как сейчас подсистема Text не выдерживает критики. Тексты на русском весят очень много, так как TextModels крошит всё отображение на мелкие куски. Пробелы кодируются в SHORTCHAR, а слова в UCS2. И у каждого куска в довесок идет метаинформация. То есть у каждого пробела и слова в русском тексте возникает свой кусок. И это ужасно сказывается на производительности и на размере файлов.

Ну размер то файлов никак не изменится (для русского), при переходе на UTF8. Будет тоже самое, по сути. Вот, кстати, тексты полностью на CHAR перевести можно было бы.
И проблема не только в экспортированных их Kernel процедурах, а в том, что юникодизация выполнена не штатными средствами. Если бы поддержки юникода в КП не было, разговор про utf8 внутри имел бы смысл, но она есть.