OberonCore
https://forum.oberoncore.ru/

#008 Предложение: убрать UTF8 из BlackBox
https://forum.oberoncore.ru/viewtopic.php?f=134&t=6511		 Страница 2 из 3
Автор:  Иван Денисов [ Четверг, 12 Декабрь, 2019 18:06 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Борис Рюмшин писал(а):
Внутри ему делать нечего.

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

Плюсы, что большинство идентификаторов в бинарниках занимает мало места в однобайтной кодировке. Алгоритмы сравнения работают быстрее для однобайтных строк?
Автор:  Sergej Durmanov [ Четверг, 12 Декабрь, 2019 19:16 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Кто мешает загружать модули разных версий, конвертируя старые "на лету"? Тогда можно держать и старый формат с utf8, и новый с utf16, а внутри все в utf16
Автор:  Иван Денисов [ Пятница, 13 Декабрь, 2019 04:40 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Борис, а у вас уже есть какие-то эксперименты? А то может опасения по поводу сложности изменения компилятора напрасны. Может там не так всё плохо?
Автор:  Борис Рюмшин [ Пятница, 13 Декабрь, 2019 12:25 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
С моей точки зрения опасения напрасны. Нет, мы ещё таких изменений не вносили.
Автор:  Дмитрий Дагаев [ Воскресенье, 22 Декабрь, 2019 13:03 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Иван Денисов писал(а):
Новое ядро проектируем для версии 1.8, подключился Антон и орловцы. Вот поэтому и Борис про Utf8 написал, что раз идет редизайн ядра, то можем сделать всё более элегантно.

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

1. Интерфейс Uft8 в ядре не нужен. И понятие Kernel.Utf8 не нужно.
2. Есть проблема SHORT(lstring) и LONG(sstring). По уму, если lstring в кодировке UCS2, то s := SHORT(lstring) должно переводить это в кодировку UTF8. И наоборот, если sstring в кодировке UTF8, то ls := LONG(sstring) должно переводить к кодировку UCS2.
3. Я в LLVM в ядро вставлял процедуры:
Код:
PROCEDURE StrcpySL* (IN src: ARRAY OF SHORTCHAR; VAR dst: ARRAY OF CHAR; len: INTEGER);
PROCEDURE StrcmpSL* (IN x: ARRAY OF CHAR; IN y: ARRAY OF SHORTCHAR): INTEGER;
PROCEDURE StrapndSL* (IN src: ARRAY OF SHORTCHAR; VAR dst: ARRAY OF CHAR; len: INTEGER);

для преобразования строк из SHORT в LONG.
Идея из OFront - там это в сишном виде.
4. Предлагаю в Kernel добавить интерфейсы, например, адреса процедур StrcpySL, StrapndSL (append), которые по умолчанию задаются процедурами из Kernel, но могут инсталлироваться из другого модуля.
5. Модуль с реализацией, ну там HostStrings, содержит процедуры конвертации UTF8 <-> UCS2.
Автор:  Илья Ермаков [ Воскресенье, 22 Декабрь, 2019 14:52 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Дмитрий Викторович, ваше предложение мне кажется очень рациональным.
Автор:  Sergej Durmanov [ Воскресенье, 22 Декабрь, 2019 18:38 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
UCS2 не нужна, лучше сразу UTF16
Автор:  Борис Рюмшин [ Воскресенье, 22 Декабрь, 2019 19:23 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Дмитрий Дагаев писал(а):
2. Есть проблема SHORT(lstring) и LONG(sstring). По уму, если lstring в кодировке UCS2, то s := SHORT(lstring) должно переводить это в кодировку UTF8. И наоборот, если sstring в кодировке UTF8, то ls := LONG(sstring) должно переводить к кодировку UCS2.

5. Модуль с реализацией, ну там HostStrings, содержит процедуры конвертации UTF8 <-> UCS2.

Такое изменение семантики SHORT/LONG опасно. Как минимум для старого кода.
Автор:  Trurl [ Воскресенье, 22 Декабрь, 2019 20:01 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Дмитрий Дагаев писал(а):
И наоборот, если sstring в кодировке UTF8, то ls := LONG(sstring) должно переводить к кодировку UCS2.

А откуда LONG узнает, что sstring в кодировке UTF8?
Автор:  Дмитрий Дагаев [ Воскресенье, 22 Декабрь, 2019 21:23 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Я согласен с критическими замечаниями в адрес такого предложения. Попробую аргументацию в свою защиту.
StrcpySL, StrapndSL по умолчанию задаются процедурами из Kernel - то есть обычные преобразования char<->shortchar.
Борис Рюмшин писал(а):
Такое изменение семантики SHORT/LONG опасно. Как минимум для старого кода.

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

Sergej Durmanov писал(а):
UCS2 не нужна, лучше сразу UTF16

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

Trurl писал(а):
А откуда LONG узнает, что sstring в кодировке UTF8

Моя схема допускает установка любых перекодировщиков, например, UTF7. Если Вы для Ваших задач хотите использовать другую кодировку для SHORTCHAR - это будет работать. Но не будет совместимо с другими, если они в UTF8. Надо "на берегу" договариваться, что у SHORTCHAR кодировка UTF8
Автор:  Борис Рюмшин [ Воскресенье, 22 Декабрь, 2019 23:42 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Дмитрий Дагаев писал(а):
Только для нового кода (1.8 версия) мы прибиваем реализацию HostStrings, где уже фиксируем кодировки. Для совместимости остается дефолтная реализация со старой семантикой.

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

Код:
VAR x: ARRAY 8 OF CHAR; y: ARRAY 8 OF SHORTCHAR;

y := SHORT(x);

А в x 7 символов кириллицы. И всё.
Автор:  adimetrius [ Понедельник, 23 Декабрь, 2019 00:55 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Дмитрий Дагаев писал(а):
4. Предлагаю в Kernel добавить интерфейсы, например, адреса процедур StrcpySL, StrapndSL (append), которые по умолчанию задаются процедурами из Kernel, но могут инсталлироваться из другого модуля.
5. Модуль с реализацией, ну там HostStrings, содержит процедуры конвертации UTF8 <-> UCS2.


Поддерживаю. Но предлагаю все же BlackBox way: Hook с типозависимыми процедурами.
Борис Рюмшин писал(а):
Всё равно не надо такого. SHORT предполагает какое-то урезание (низкоуровневое), а не преобразование. Причём не очевидное.

А здесь поддерживаю Бориса. И еще обращаю внимание, что сейчас 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.
Автор:  Иван Денисов [ Понедельник, 23 Декабрь, 2019 10:48 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Надо, чтобы преобразование было встроено в ядро. Не надо делать для таких низкоуровневых вещей никаких хуков. И без iconv, конечно! Должно быть платформенно-независимое преобразование.
Либо вообще без преобразований, как Борис изначально предложил.
Автор:  Alexander Shiryaev [ Понедельник, 23 Декабрь, 2019 14:18 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Trurl писал(а):
Дмитрий Дагаев писал(а):
И наоборот, если sstring в кодировке UTF8, то ls := LONG(sstring) должно переводить к кодировку UCS2.

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

Другие кодировки не нужны :wink:
Автор:  Ярослав Романченко [ Понедельник, 23 Декабрь, 2019 15:03 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Alexander Shiryaev писал(а):
Другие кодировки не нужны :wink:
640K ought to be enough for anybody :wink:
Автор:  Alexander Shiryaev [ Понедельник, 23 Декабрь, 2019 23:13 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
https://www.opennet.ru/opennews/art.shtml?num=42795
https://www.openbsd.org/papers/eurobsdcon2016-utf8.pdf, стр. 39
Автор:  Artyemov [ Вторник, 24 Декабрь, 2019 01:10 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Ярослав Романченко писал(а):
640K ought to be enough for anybody :wink:

И за это тоже, его в аду будут жарить на сковородках без масла...
Автор:  Дмитрий Дагаев [ Вторник, 24 Декабрь, 2019 19:15 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Alexander Shiryaev писал(а):
https://www.opennet.ru/opennews/art.shtml?num=42795
https://www.openbsd.org/papers/eurobsdcon2016-utf8.pdf, стр. 39

И правильно, проблемы от избытка. Если б было везде SHORTCHAR (лучше CHAR) с utf8 - не было б проблемы.
Автор:  Иван Денисов [ Среда, 25 Декабрь, 2019 12:38 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
На мой взгляд, проблема не в том, что используется UTF8 для кодирования идентификаторов, а в том, что в Strings импортируется реализация UTF8 из ядра. Это временное решение, которое должно быть устранено. Но также импортируются реализации IsUpper IsLower. А они библиотечные! И они также нужны в ядре. И получается, что даже если вы хотите брать только UCS2. То проблема зависимости Strings от ядра не убирается, так как либо надо делать HostStrings, где будут библитечные реализации Upper и т.п., либо оставить так как сейчас их хост-зависимые библиотечные реализации в ядре. Это важные момент. Никто не хочет писать свою реализацию Upper и Lower для всех известных языков? Если кто-то напишет, то давайте включим это в Strings и тогда можно будет убрать зависимость от ядра.

А в целом как внутренняя реализация UTF8 очень удобен, внутри рантайма везде используется экономичный SHORTCHAR. А парсер и средства отладки работают с UCS2.
Более логичным был бы дальнейший переход на UTF8, так как сейчас подсистема Text не выдерживает критики. Тексты на русском весят очень много, так как TextModels крошит всё отображение на мелкие куски. Пробелы кодируются в SHORTCHAR, а слова в UCS2. И у каждого куска в довесок идет метаинформация. То есть у каждого пробела и слова в русском тексте возникает свой кусок. И это ужасно сказывается на производительности и на размере файлов.
Автор:  Борис Рюмшин [ Среда, 25 Декабрь, 2019 12:50 ]
Заголовок сообщения:  Re: Предложение: убрать UTF8 из BlackBox
Ну размер то файлов никак не изменится (для русского), при переходе на UTF8. Будет тоже самое, по сути. Вот, кстати, тексты полностью на CHAR перевести можно было бы.
И проблема не только в экспортированных их Kernel процедурах, а в том, что юникодизация выполнена не штатными средствами. Если бы поддержки юникода в КП не было, разговор про utf8 внутри имел бы смысл, но она есть.
Страница 2 из 3 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/