Я думал об этом. Пришёл к следующим выводам.
Во 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. ![Подмигивает ;)](./images/smilies/icon_e_wink.gif)
- Сделать 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 кажется более верным направлением, но и самым трудоёмким.