OberonCore

Возможно, скоро попробую добавить в ЯОС литералы UTF-32. Это такая штука, которая является не массивом CHAR, а массивом из 32-разрядных чисел, каждое из которых кодирует одну "code point". Поэтому будет два вида строковых литералов:


Сейчас, собственно, есть функция UCS32.Lit, которая возвращает на самом деле указатель на массив таких чисел. Но хочу переделать её в конструкцию языка. Что будет наиболее "обероновым" стилем оформления такой конструкции? Я не особо хочу делать всякие там u"фыва". Например, по той причине, что дальнейший анализ того, какие могут быть литералы, показывает, что в развитом языке может быть много разновидностей, например, в C++ всё выглядит мрачным.

Поэтому самый общий, понятный и управляемый путь сделать свои литералы - это вызов, получаемый с помощью импорта, и подобный вызову функции. Но интересны ваши мнения.

Вы пишете: "Поэтому будет два вида строковых литералов". Неочевидно, что два вида литералов в языке подразумевают, что они должны синтаксически или иначе различаться.

В КП литерные типы определяются вот так:
2. SHORTCHAR the characters of the Latin‘1 character set (0X .. 0FFX)
3. CHAR the characters of the Unicode character set (0X .. 0FFFFX)

Тип строкового литерала определяется по его содержимому: если все литеры строки входят в Latin1, то это литерал типа Shortstring (п. 6.6). А далее допускаются неявные преобразования:



Таким образом, в КП отсутствует необходимость явно указывать тип литерала; фактически, он выводится (собсно об этом в СЯ и сказано в других терминах). Как вам такой подход?

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

А приведите, пож, пример заголовков процедур.

https://github.com/metacore/A2OS/blob/m ... s.Mod#L237 - вот пример из модуля Texts.

А вот определение типа Char32 в этом модуле:
https://github.com/metacore/A2OS/blob/m ... ts.Mod#L26

А вот мои (другие, но похожие) символы UCS32: UCS32 - это название из A2, обычно это называется UTF32. Почему так назвали - я не знаю. А может быть, и я что-то напутал.

https://gitlab.com/budden/ja-o-s/-/blob/главная/source/UCS32.Mod#L15

Я посмотрел по ссылкам, но не очень понял. Что такое UCS32String мне непонятно.

Зато я другое понял: то, что сделано в КП, реализуется компилятором. И, во-вторых, CHAR это не просто два байта, это всегда одна заданная кодировка. Если же определить CHAR просто как двухбайтную (четырехбайтную) литеру, без уточнения кодировки, то потом возникает неоднозначность в том, что такое ARRAY OF CHAR, в какой кодировке строка внутри этого массива. И тогда компилятору нужды дополнительные указания, как осуществить str := "Keep it simple".

А вы, я вспомнил, не трогаете компилятор, верно? Значит, вам такой подход не подходит.

Как раз в этом месте компилятор придётся потрогать. Да, у строкового литерала есть нюансы:

- какой он кодировки
- сколько байт в символе
- как воспринимать находящиеся внутри литерала спецзнаки, например \n
- однострочный/многострочный
- обрезать ли начало строк в многострочном для красоты и если да, то как именно

UCS32String - это ARRAY OF SIGNED32 или что-нибудь в этом роде.

В общем, я сделал не парясь, в стиле лиспа. Есть типы симв8 (в памяти представлен байтом) и симв32 (в памяти представлен 4 байтами), несовместимые между собой. Соответственно, массив из симв8 или массив из симв32. Литералы строки пишутся так:


Это было решение, требующее смирения - всегда хочется приделать вместо такой громоздкой записи какую-нибудь буковку и тем потенцильно сломать какой-то код, который про это не знает. Или буковки закончатся. Решение лиспа состоит в том, что мы строим на просторе большие дома, т.е. если нам нужно какое-то понятие выразить, то мы выражаем его словом и функцией, а не буковками. Благодаря такому решению, можно любые дополнительные нюансы литерала выражать в виде дополнительных параметров псевдо-функции, а не обвешивать строку буковками и циферками, как новогоднюю ёлку.

Но вопрос теперь - делать ли симв16? Я по неделе Оберона (особенно по докладу Артура) и по прошлым настроениям Сергея понял, что симв32 - это перебор, и симв16 хватает даже для наших CJK восточных партнёров.

P.S. преобразования между строковыми типами у меня являются только явными, поскольку UTF-8 и UTF-32 занимают разную длину, и для каждого преобразования, если мы хотим, чтобы оно прошло с гарантией, нужно выделять неизвестное заранее количество памяти, большее, чем в источнике. Т.е. операция дорогостоящая и нетривиальная.

Размер нормализованного текста в UTF-8 меньше либо равен тексту в UTF-32. Это никак не помогает?

Я в этом сомневаюсь, для случая некорректных текстов. Хотя точные оценки мне неизвестны. Есть теорема, что всегда меньше, даже для некорректных?

Что означает размер некорректных текстов? Куда пойдут некорректно закодированные байты?

Почему бы не остановиться на какой-то одной кодировке для всей системы? Тут вот тов. Дурманов говорил сегодня, что китайцы широко (в известных пределах) применяют А2. Они же явно китайский там используют внутри.

1. При раскодировке неправильного UTF-8 неверную часть желательно заменить символом - заместителем, а потом перезапустить чтение. А потом может понадобиться этот символ обратно из UTF-32 перегнать в UTF-8. В идеальном мире кодировка/раскодировка вообще должна быть без потерь, чтобы любая последовательность байт (кроме 0) преобразовывалась бы в UTF-32 и потом обратно, но это уже мои домыслы/фантазии. Не знаю, осуществимо ли это, делал всё как обычно в спешке и в такие глубины не лез. Но на практике необходимо ожидать, что любые последовательности байт, в т.ч. и некорректные, обязательно придут к нам на вход, и вести себя как-то так, чтобы дать пользователю понимание, что случилось, но при этом нельзя сразу падать, поскольку это лёгкая мишень для атаки.

2. Нет, на одной кодировке по историческим причинам остановиться нельзя. Т.к. уже есть модуль Texts с 32-битным символом (который пока что представлен тупо числом, что крайне неудобно со многих сторон), и есть обмен данными с Windows, где используются 16-разрядные символы. Ну а UTF-8 тоже уже есть во многих местах. Такова суровая жизнь разработчика операционных систем.

А не GBK ли они там используют?

Осуществимо, но тогда это будет не совсем UTF-32 и это может привести к более печальным последствиям, чем отказ от приёма или корректировка неправильных данных.

Ну так и передавайте то, что им нужно. В чем проблема-то?

Я не понял содержание Вашего совета. Речь в той части, на к-рую Вы отвечаете, шла о том, что тип строкового литерала в ББ определяется его содержимым. Вроде, с одной стороны, это мейнстрим - тип литерала сплошь и рядом определяется содержимым. Тогда, казалось бы, почему бы и тип литер из содержимого не определять? С другой, даже для чисел это может приводить к неожиданностям, поэтому данное решение несколько напрягает. А наличие неявных преобразований всегда снижает надёжность языка. Поэтому должен быть хотя бы способ указать тип литерала явно. Я думаю, для чисел в ББ такой способ есть. А есть ли в ББ способ сказать, что "abcd" - это литерал типа ARRAY OF CHAR, а не ARRAY OF SHORTCHAR?

Если мы находимся внутри системы, я не думаю, что это будет прямо плохо. Отказаться от раскодировки любой UTF-8 последовательности мы не можем. Одной из первых работ по его улучшению в ЯОС была починка отладочного вывода, который скромно замолкал при появлении кириллицы. Ни корректировать данные, ни отказаться их принять поток отладочного вывода не может, потому что тогда это будет уже не поток отладочного вывода. Если пришли неверные данные, их нужно показать, и как минимум, явно показать, что данные некорректные и где. Притом, этот поток потом может кодироваться обратно в UTF-8 и выводиться в какую-нибудь консоль Windows в chcp 65001, у которой свои (возможно, глючные) представления относительно UTF-8.

Неверная постановка вопроса, "abcd" - это вообще не массив.

Кстати, насчет мейнстрима. Мы ведь пишем

Ну может это и называется "цепочкой литер", но это всё вопросы по терминологии, а не по сути дела. Ваша точка зрения пока понятнее не стала.


Так и в Обероне, во всяком случае, в активном, тоже пишется

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