OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 13:56

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 82 ]  На страницу 1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 04 Октябрь, 2021 01:12 

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

Код:
конст a = "фыва" (* это литерал в формате UTF-8, т.е. он в памяти представлен как последовательность байт, каждая русская буква занимает два байта *)
b = UCS32.Lit("фыва") (* это литерал в формате UTF-32, т.е. массив из 4 32-разрядных чисел *)

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 04 Октябрь, 2021 11:06 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Вы пишете: "Поэтому будет два вида строковых литералов". Неочевидно, что два вида литералов в языке подразумевают, что они должны синтаксически или иначе различаться.

В КП литерные типы определяются вот так:
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). А далее допускаются неявные преобразования:

Код:
CONST shortstring = 'Make it as simple as possible';
   string = "В Севилье град крупнее, говорят";
VAR ss: ARRAY N OF SHORTCHAR;
   s: ARRAY OF CHAR;
BEGIN
   s := shortstring;  (* неявное приведение типа, СР2 "вписывает" его во время исполнения программы, хотя Сообщение о языке к этому не обязывает и позволяет сделать приведение во время компиляции *)
   ss := shortstring;
   s := string;
   ss := string;   (* недопустимо *)


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 04 Октябрь, 2021 12:16 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 04 Октябрь, 2021 17:43 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
budden писал(а):
Не, так не пойдёт, потому что у меня есть процедуры, которым на вход нужен UTF8, а есть - которым нужен UTF32

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 04 Октябрь, 2021 21:36 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Октябрь, 2021 11:25 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Я посмотрел по ссылкам, но не очень понял. Что такое UCS32String мне непонятно.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Октябрь, 2021 15:23 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Как раз в этом месте компилятор придётся потрогать. Да, у строкового литерала есть нюансы:

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 19 Декабрь, 2021 16:06 

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

Код:
"абв" - это массив из симв8, в кодировке UTF-8 (на самом деле, просто байты из исходного текста переписываются, но так мыслить сложнее, поэтому мы объявляем, что у нас фиксированная кодировка исходника и литерал тоже в UTF-8)

Лит32("абв") - это массив из симв32, он преобразуется из UTF-8 в UTF-32 во время компиляции и в таком виде пишется в объектный файл

"k" - может интерпретироваться как симв8 или массив 2 из симв8

ЛитСимв32("ю") - это литерал симв32

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 19 Декабрь, 2021 17:38 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 19 Декабрь, 2021 22:50 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Размер нормализованного текста в UTF-8 меньше либо равен тексту в UTF-32. Это никак не помогает?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 19 Декабрь, 2021 22:58 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Я в этом сомневаюсь, для случая некорректных текстов. Хотя точные оценки мне неизвестны. Есть теорема, что всегда меньше, даже для некорректных?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 19 Декабрь, 2021 23:03 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Что означает размер некорректных текстов? Куда пойдут некорректно закодированные байты?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 19 Декабрь, 2021 23:39 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Почему бы не остановиться на какой-то одной кодировке для всей системы? Тут вот тов. Дурманов говорил сегодня, что китайцы широко (в известных пределах) применяют А2. Они же явно китайский там используют внутри.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Декабрь, 2021 01:36 

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Декабрь, 2021 01:54 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Борис Рюмшин писал(а):
Дурманов говорил сегодня, что китайцы широко (в известных пределах) применяют А2. Они же явно китайский там используют внутри.
А не GBK ли они там используют?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Декабрь, 2021 08:07 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
budden писал(а):
Не, так не пойдёт, потому что у меня есть процедуры, которым на вход нужен UTF8 (например, ввод-вывод текстовых потоков), а есть - которым нужен UTF32 (например, текстовый редактор), это зависит от места применения, а не от содержания текста.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Декабрь, 2021 12:27 

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


Последний раз редактировалось budden Понедельник, 20 Декабрь, 2021 12:35, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Декабрь, 2021 12:32 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Comdiv писал(а):
Борис Рюмшин писал(а):
Дурманов говорил сегодня, что китайцы широко (в известных пределах) применяют А2. Они же явно китайский там используют внутри.
А не GBK ли они там используют?

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Декабрь, 2021 13:06 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
budden писал(а):
А есть ли в ББ способ сказать, что "abcd" - это литерал типа ARRAY OF CHAR, а не ARRAY OF SHORTCHAR?

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

Кстати, насчет мейнстрима. Мы ведь пишем
Код:
byte x = 42;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Декабрь, 2021 17:33 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Ну может это и называется "цепочкой литер", но это всё вопросы по терминологии, а не по сути дела. Ваша точка зрения пока понятнее не стала.

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

Так и в Обероне, во всяком случае, в активном, тоже пишется
Код:
const a = 42;

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 82 ]  На страницу 1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB