Оберон-клуб «ВЄДАsoft»

В Pow! компилятор собирается из исходников без всяких проблем.
Нужно думать о добавлении типа LONGCHAR в него.

Я думал об этом. Пришёл к следующим выводам.

Во 80-е всем хватало однобайтового символа и кодовых страниц. Насчёт китайских иероглифов заморачивались те, кому это было реально нужно, но и они тоже обходились.

Вирту и компании, помимо ASCII, нужны были германские символы ÄäÖöÜüß, что они легко решили своей германской кодовой страницей, далее не пошли.

Стандарт Оберона 1 и 2 регламентирует CHAR только печатными символами из таблицы ASCII. Задать русские символы не только в идентификатор, но даже в строку не получится (в Ofront'е это нельзя; я хотел бы сделать, но тогда надо привязываться к одной из однобайтных кодировок (1251, KOI8-R)).

Но мир становился всё теснее, постепенно юникод вошёл в обиход, и теперь мы без него не мыслим работы, и наверное это правильно. Вирт вот тоже решил, что в Обероне-07 "символ" # "только латинский символ". Поэтому в стандарте О-07 нет привязки CHAR к однобайтовости.

• Сделать уже существующий тип CHAR двухбайтовым:
  Плюсы: минимальность модификации. Добавить в компилятор новый тип труднее, чем модифицировать CHAR под 2 байта. Реверанс в сторону Оберона-07 (CHAR это любой символ, а не только из ASCII);
  Минусы: лишаемся однобайтового CHAR, а он нужен.

• Оставить CHAR = 1 байт, добавить LONGCHAR = 2 байта. Реверанс в сторону OO2C:
  Плюсы: Остаётся совместимость со стандартом О1 и О2 сверху вниз.
  Минусы: Сложная модификация. Разбито представление "CHAR = любой печатный символ". Антиреверанс в сторону Вирта и О-07.

• Сделать CHAR двухбайтовым, ввести SHORTCHAR = 1 байт:
  Плюсы: Компилятор приобретает в этом смысле совместимость не с заброшенным OO2C, а с самыми зрелыми реализациями Оберона: BlackBox, GPCP, Active Oberon. База совместима с O-07. Реверанс в сторону Вирта. LONGCHAR остаётся зарезервированным под более длинные символы (например, в 4 байта);
  Минусы: Модификация сложная, надо узнать как добавлять новые типы.

Если соберёшься сделать третий вариант для POW!, то я планирую реализовать его же для XDev/Ofront. Получим целую линейку систем, реализующих такой подход: BlackBox, GPCP, Active Oberon, XDev/Ofront и POW!

Для добавки нового типа в XDev можно начать с сопоставления исходников компилятора OPCL и BlackBox (они на одной основе — OP2). По различиям будет видно какие именно изменения для широких символов добавлены. А POW! вроде не на основе OP2.

Ещё не так-то просто будет добавить поддержку юникода в IDE/редактор.

P.S. Наверное могу помочь с портированием ACL или LVCL на Оберон-2. Если согласуем взгляды на разработку и стиль кодирования. Такую работу рассматриваю как полезную и довольно необъёмную. VisualOberon кажется более верным направлением, но и самым трудоёмким.

Да, все верно. Получается нужно пробовать именно третий подход из тобой перечисленных.
Для начала переделать в Pow char в shortchar - заодно посмотрю, как он там реализован. А потом на основе полученных знаний, реализовать 2х-байтный char. По большому счету там только операция присвоения реализуется, ну и сам тип....

Да, реализовать операцию COPY для двухбайтовых CHAR, перевод длинных символов/строк в короткие SHORT() и наоборот — LONG(), ну шобы всё по уму.

Рад, что мы сошлись во мнениях насчёт третьего варианта. Уже фрагментации избежим.

Фрагментации в реализации Оберона и без нас вроде бы вполне хватает
Давно пора во многих вопросах заняться обобщением. Есть такие мысли и в отношении GUI, но пока что до их реализации - как пешком до Луны.

в АО CHAR занимает 4 байта (32 битный UNICODE)

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

Курс по программированию на POW!
Pascal of the 3d milenium (Computer programming with Oberon-2).
Увы, на румынском. Но зато с картинками.

Кхм... Никто в AO не делал CHAR двухбайтовым или четырёхбайтовым. CHAR там по сей день как был восьмибитным так и остался восьмибитным.
Но, вся текстовая подсистема работает с 32-х битными символами, это верно.
Просто в Texts.Mod находим следующие объявления:

Zorko, может твоя явная нелюбовь к AO происходит от такой явной дезинформированности?
Фильтровать надо инфушку-то, а ещё славянин...

Из вышесказанного мною, очевидно, что для шага в сторону совместимости с AO можно портировать на POW! текстовую подсистему из A2. Для возможности работы с UNICODE это возможно и достаточный шаг, так как текстовая подсистема - сердце всей системы A2, как во многих Oberon-системах.

Ну, и 32-битность, а не 16-битность, это да, реверанс китайцам
В Китае, кстати, тоже есть оберонщики.

ЗЫ. Или, что вообще мешает понаделать 16-битных нужных биндингов и работать с UNICODE строками как с ARRAY OF INTEGER? Ну, понаписывать нужных библиотечных функций для работы с такой строкой... Length, Pos, и т.д.

Капец, смех да и только. Что-то тут обсуждали-обсуждали... Хоть кто-то смотрел вообще в исходники библиотеки POW! ???
Там и биндинги с префиксом W есть и тип WCHAR = INTEGER