OberonCore

Ну и какой тип у 42?

Я не знаю. Особенно если это не 42, а 2147483649. И что дальше? Что Вы имели в виду, говоря о том, что надо "передавать туда то, что они ожидают"?

В общем, мы посовещались и я решил пока не делать тип симв16. Потому что хвосты от симв32 ещё остались и пока даже неясно, как их все подчистить. В целом-то всё работает, но есть нюансы чисто архитектурные, а именно, как определены операции сравнения для новых строк: они сейчас определены в модуле через механизм перегрузки операций, в то время как для обычных строк они вшиты в компилятор. И тут есть не перевешивающие друг друга плюсы и минусы у каждого варианта. Нужно время, чтобы понять, какой вариант надо оставить.

Что же касается вопроса о форме литералов, думаю, обсуждение можно свернуть. То, что я сделал - может быть и не идеально, но недостаточно плохо, чтобы что-то ещё менять. Тема автовывода типа литералов сложная, глубокая, что-то сильно менять в ней нет ресурсов, да и обсуждать это особо времени нет.

Собственно и повторный выход в эту тему был для того, чтобы дать обратную связь по тому, какое решение принято по данному вопросу в ЯОС. Конечно, его можно осуждать, как и любое решение.

Если кому-то вдруг прямо очень надо, чтобы в ЯОС появился тип симв16 (напомню, в оригинальной A2 на сегодня нет ни CHAR16, ни CHAR32, а для модуля texts вместо CHAR32 используются целые числа), то дайте знать чем раньше, тем лучше, потому что это была сложная работа. Сейчас её будет относительно несложно повторить по свежей памяти, а чем дальше - тем сложнее.

В ЯОС есть модуль UCS2 и в нём тип UCS2.Char, который и есть Char16, но он выглядит как запись с числом внутри. Т.е. это отдельный тип, который нельзя просто так перепутать ни с числом, ни с CHAR-ом, и для него есть какие-то процедуры, которые его обслуживают. Он используется для обмена с WinApi в Win версии, например, для буфера обмена (ЕМНИП). Т.е. он в принципе работает и пользоваться можно. Недостатки: он сам по себе не печатается как строка при вводе-выводе, поэтому уровень комфорта невысокий. И самое главное - нельзя сделать литералы таких строк - если они нужны, их придётся выделать в куче. Но у нас тут собрались оберонщики-аскеты, нам не привыкать.

Что касается симв32, то литералы массивов из симв32 я внедрил в среду разработки и она насколько-то ускорилась, может быть, процентов на 10, а может и на 20, за счёт снижения нагрузки на кучу.

А я знаю и с удовольствием расскажу. 42 имеет тип int. Однако, мы спокойно присваиваем его переменной x типа byte или float.
Аналогично, строка "abcd" имеет то тип, который требуется в месте использования.

Ну, во-первых, это выглядит нелогичным. По идее, если "каждая константа имеет тип, равный минимально вмещающему эту константу типу", то она должна быть типа беззнаковый байт или знаковый байт (хотя это два разных типа и это имеет последствия, если мы с ней делаем вычисления). Если же "каждая константа имеет тип, равным максимально вмещающему эту константу типу", то тогда непонятно, почему "abcd" имеет тип SHORTCHAR, а не CHAR. Вместо этого имеем набор ad hoc правил, которые неявные и не такие уж просты. Если у нас культ простоты, то их присутствие в языке вызывает у меня сомнения. Но допустим, к этому можно привыкнуть. Теперь смотрите (специально расчехлил ББ ради этого случая).


Ничего не смущает?

Идея, что каждая константа имеет тип, сама по себе сомнительна. Там, где её применяют, приходится придумывать всякие хитрые правила-исключения.

А что сомнительного? Ведь у нас же язык со статической типизацией. Почему переменные и параметры имеют значение, а константы не должны?

ПОЧЕМУ???
Значение константы, даже во время компиляции - не нечто "висящее само по себе в воздухе".
Даже не во всех выражениях вам её разрешается использовать - опять-таки - именно - из-за несовместимости по типу.

Все, вроде, так и есть, как вы написали. Меня ничего не смущает. А что смущает вас? Какие могут возникнуть проблемы при перекодировке? Согласно Сообщению, SHORTCHAR использует кодировку Latin-1, CHAR - Unicode character set. Википедия про Latin-1 сообщает, что "В Юникоде первые 256 кодовых позиций совпадают с ISO-8859-1".

Ан нет, нужно уточнить:

Не припомню, где в Сообщении о языке такое сказано. Напротив,

Ну, какие-то типы константам можно приписать, но это не те типы, которые используются для переменных и значений.
Типов значений обычно бывает больше, чем типов констант. Да и правила использования для них другие.

Вот как раз у языков с динамической типизацией проще. Каждая константа имеет тип.
Хотя, конечно, типы эти не совсем такие, как в статических языках.

Это и есть "набор ad hoc правил", которые не из чего не следуют и их надо выучить. Это нехорошо. Потому что принцип простоты требует, чтобы правила выводились из минимального набора аксиом. Во всяком случае, как я его понимаю. Перекодировка в случае ББ ничем не смущает, не считая того, что она имеет свою ненулевую цену. Присвоить литерал того же типа - это просто скопировать кусок памяти. А присвоение от SHORTCHAR к CHAR - это уже некое вычисление, хотя простое и дешёвое. Если же в языке присутствует utf-8 или кодовые страницы, то преобразование имеет определённую стоимость, не является однозначным, даёт результат неясной длины и/или может завершиться неудачей, т.е. уже совсем нехорошо получается. Т.е. в ББ решение находится как бы на пределе возможностей и при усложнении строковых типов дальше уже не тянется. Не говоря уж о том, что по содержимому литерала невозможно понять, нужен ли он нам как строка в UTF-8 или в UTF-32 - эта информация может быть получена только когда его чему-то присваиваем. А если этот литерал является экспортируемой константой, то информации о присваиваниях у нас нет. Допустим, мы всегда будем присваивать его только строкам UTF-8 - тогда его и хранить надо в UTF-8, чтобы была ясна его длина. А может быть, будем его присваивать только строкам UTF-32 - Тогда и хранить надо в UTF-32. Но принять решение о хранении мы не можем, если тип литерала не указан при его создании. Как-то так. В принципе, и в ББ такая ситуация возможна, когда литерал состоит из ASCII литер, но присваиваться будет всегда в других модулях и всегда только переменным типа ARRAY OF CHAR. Тогда получается, что мы всегда будем его перекодировать. Это - потери машинного времени. В принципе мы можем это уложить в путь Оберона и сказать, что сторговали простоту за скорость. Поэтому, как я уже сказал, решение на грани. В случае наличия строк UTF-8 и UTF-32 сделка уже не проходит.

Не бывает констант, литеральных значений, без типов.
Не бывает констант без (даже - подразумеваемого!) Типа.
Или мы - о разном говорим?.

Т.о. тип данных в КП определяет множество. Значение, к примеру, 3 принадлежит множествам BYTE, SHORTINT, INTEGER, LONGINT, SHORTREAL, REAL. И в алгебре тоже: 3 принадлежит N, Z, R.
В общем случае, любой литерал может принадлежать нескольким множествам. Принципиально невозможно однозначно установить тип литерала. Не бывает констант с однозначным типом.
К исключениям как раз строковые литералы относятся: "Мыслю, следовательно существую" - однозначно принадлежит множеству строк Unicode.

(Строго говоря, понятие "тип литерала" в приведенной цитате вообще не определяется: типы определены в отношении переменных)

Если так рассуждать, то и у любого значения, например, 8, нельзя определить тип, а тип есть только у места хранения. Думаю, тип литерала есть и он представляет из себя то, о чём договорились. Компилятор по каким-то (хорошо, если описанным) правилам этот тип назначает, тип так просто не увидеть, но можно вставить в определённое место компилятора вывод сообщения об этом типе. А дальше уже литерал становится "значением, известным во время компиляции", и у него есть (невидимый) тип. Он может преобразовываться с помощью неявных преобразований. Во всяком случае, в компиляторе Фокс это по-моему как-то так устроено. Не знаю про другие компиляторы.

На мой вкус, Utf8 сложна, и потому подходит для хранения, но не для обработки. Кажется, что она и сделана (оптимизирована) как раз для хранения, а не обработки. Причем в расчете на то, что чаще всего встречаются первые 256 кодов.

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

Пример, кмк, аналогичный. В языке Оберон целочисленные переменные всегда знаковые и размера 32 бита. А в системе Оберон, как я понял, в ряде форматов целые выводятся не по 4 байта, а по скольку нужно, от 1 до 5. Но это именно в ряде файловых форматов, это для хранения! Прочитанное из файла целое - всегда в целочисленной переменной, и в памяти ЭВМ занимает 32 бита. Хлопоты по кодированию/декодированию локализованы в нескольких процедурах одного модуля, они не затуманивают текст компилятора и не расползаются по всему языку и всевозможным прикладным модулям. Следы такого подхода есть и в ББ: в формате OCF разнообразные целые (не все) кодируются переменным числом байт. Это дает особенный выигрыш там, где целые значения распределены неравномерно: например, в отладочных сведениях смещения текстовой позиции от оператора к оператору - обычно < 127, поэтому почти всегда кодируются одним байтом.

utf-8 в языке нет. Есть только CHAR/симв8, UTF-16 (UCS-2), изображаемый сейчас записью из одного поля и UTF32 = симв32. Но при этом utf-8 сплошь и рядом служит для связи с внешним миром, поэтому "попа есть, а слова нет" - сплошь и рядом массив из симв8 на самом деле закодирован в utf-8. Деться от него абсолютно некуда, и если его убрать, то будет выбор либо выкинуть кириллицу, либо использовать кодовые страницы. В принципе было бы неплохо иметь тип, который явно подчёркивает, что данная строка является корректным utf-8, тогда можно было бы много сделать более надёжным или быстрым, но это нет и я этого делать не собираюсь. utf32 тоже уже есть - на нём сделан весь "богатый текст", более того, объекты представлены символом с кодом 0FFFFFFFFH (-1), которого в юникоде нет. utf16 нужен для обмена с Windows в режиме приложения. Т.е. я ничего не добавляю в язык, кроме того, что в некоторых случаях превращаю число цел32, которое на самом деле буква utf32, в тип симв32, про который явно сказано, что это литера, а не число. Здесь особого усложнения по сравнению с ББ нет, просто взято не 16 бит, а 32 - возможно, это и ошибка, но не моя, поскольку не я писал модуль Texts в A2. Если бы я для своих задач попытался бы сделать симв16 = CHAR из ББ, в текстах символы продолжали бы оставаться числами, что не есть слишком плохо, но тем не менее весьма коряво, и главное, я не смог бы пользоваться инфраструктурой модуля Texts (а это все текстовые редакторы и прочее) для своей деятельности без перекодировки строк из 16 бит в 32, что тоже глупо.

В т.ч. и литералы utf-8 уже присутствуют в системе в огромном количестве. А литералы utf32 нужны, чтобы писать всякие процедуры для работы с текстом, например, в каком-нибудь парсере текста, читаемого из окна редактора (для IDE), они нужны для ключевых слов.

Вот конкретный пример: https://gitlab.com/budden/ja-o-s/-/blob/опять-симв32/source/BimboScannerUCS32.Mod#L580

За счёт истинных литералов, зашитых в компилятор, получается существенный выигрыш в скорости, и другим путём его достигнуть нельзя (ну разве только переделать весь алгоритм).

Но в общем-то вопрос явно устарел, я уже сделал тип симв32 (он есть только в ЯОС, в A2 его так и не осилили доделать и выкинули), сделал литералы строк этого типа, Лит32, которые и хранятся в программе в формате UTF32, ЛитСимв32, представляющий литеру UTF32 (представлен 32-разрядным числом, но для компилятора это отдельный тип симв32, изолированный от численных типов) и поправил вылезшие ошибки компиляции штуках в 20 файлов, теперь в модуле Texts литера в объекте "текст" изображается именно литерным типом, а не числовым, как раньше. Последствия - например, при отладке можно будет видеть текст, а не числа. Это не является необходимым, но это удобно. И собственно, тут обсуждать уже особо нечего, можно поосуждать, но я просто даю обратную связь по тому, к чему я пришёл в результате обсуждения.

Насчёт марсианских программистов - например, объектные файлы тоже используют utf-8 для хранения имён. Так что эти марсиане везде проникли. У меня, очевидно, нет ресурсов переделать все использования строк в A2, а особенно - в случае, когда это режим приложения и завязка на внешний мир. Поэтому и внутри в A2/ЯОС есть много случаев, когда строки и хранятся, и обрабатываются в UTF-8. Это плохо, но такова ситуация,

Если посмотреть на время вчерашнего сообщения, то можно как-то попытаться оправдать его сумбурность. Я спешил и текст вышел не слишком хорош Готов дать дальнейшие пояснения, если ещё будут вопросы.

В частности, вот ещё пример литералов, которые содержат только латиницу, но мне они нужны как UTF32. Здесь str - это массив из симв32, а процедура "СравниСтрокуЪИМассивСимвВ_UTF8" была написана в те незапамятные времена, когда и кириллицы в ЯОС не было - поэтому она транслитом. Собственно, эта процедура и показывает цену, уплаченную за отсутствие литералов массивов симв32 - приходится перекодировать строки для каждого сравнения, естественно, это замедляет парсер.


Это код из того же лексера АО для ИРС, но на несколько строк выше. Лексер понимает и русские, и английские ключевые слова АО, поэтому этот кусок в нём тоже есть. Почему-то этот кусок не переделан на литералы массивов симв32, (тоже спешил ), а должен он в современной ЯОС выглядеть так:

Соответственно, если сделать как в ББ, т.е. str = "UNTIL", то нам понадобится операция сравнения строк UTF32 со строками из симв8. В учебниках пишут, что перегрузка операций снижает надёжность языка. Сейчас в ЯОС такой операции нет вообще, т.е. попытка сравнить массивы из симв8 и из симв32 является ошибкой компиляции. И я считаю это правильным. Например, вот достаточная причина отсутствия такой операции: если даже ввести такую операцию, то непонятно, как сравнивать: считать ли массив из симв8 закодированным в UTF8 или в кодовой странице? А если в кодовой странице, то в какой? Таким образом, мы просто не можем никак определить эту операцию и лучше пусть её не будет. Кроме того, такая операция будет дороже - сейчас мне достаточно сравнить просто куски памяти побитно, а при сравнении строк в разной кодировке их нужно будет перекодировать.

Надеюсь, данный пример всё же обосновывает необходимость двух отдельных видов строковых литералов.