OberonCore

Надо ли нам создавать свой вариант языка?


То есть, использование русских символов в идентификаторах запрещено описанием языка.


То есть, использование русских символов в (ARRAY OF) SHORTCHAR также запрещено. Для этого предусмотрен тип CHAR.
Стоит отметить, что это ограничение на самом деле сильнее, чем первое (хотя может показаться наоборот). В то же время, имеющаяся русификация BlackBox нарушает это правило.
Более того, она фактически поощряет и даже вынуждает дальнейшие нарушения. А это усиливает путаницу, которой и так хватает.

С другой стороны, использование BlackBox в неизменном виде за пределами Западной Европы и Америки практически невозможно.

Мне видится два варианта "наведения порядка":
1. Максимально ограничить ненадлежащее использование "коротких символов" и приложить усилия к тому, чтобы все символьные данные хранились в юникоде.
2. Зафиксировать и упорядочить использование различных кодировок и соответственно приложить усилия к тому, чтобы все преобразования проводились корректно.
Насколько я понимаю, ОМ планирует двигаться по первому пути.

Самое разумное, действительно, использовать где только возможно CHAR.

Что касается русских идентификаторов, то в общих кодах, претендующих на открытое распространение и переносимость, их быть, я думаю, не должно.
Но в принципе сейчас любой нормальный компилятор должен держать Unicode. Это ему (компилятору) только лишний плюс.

ОМ уже от их поддержки никуда не денется, так как сама их ввела (по просьбе info21).

Да нет там никакой поддержки .

Самое разумное было бы попинать ОМС на предмет изменения языка в стиле:


Ну и соответственно CHAR где только можно. А плодить свой вариант языка конечно нехорошо.

Ещё как вариант посмотреть на GPCP - как с символами у него. Вообще хорошо бы свести варианты BlackBox и GPCP к единому языку со всеми различиями на уровне модуля SYSTEM. Ну да это не наша забота - мы можем об этом только "активно намекать" производителям.

Попинаем и понамекаем. Тем более они и сами просят.

Я попытался действовать в стиле "Unicode Everywhere". Поправил HostCFrames, HostWindows и пр. так, чтобы все преобразовывалось в юникод.
Самая большая проблема – компилятор. Без русских идентификаторов жить вполне можно, а вот без русских констант – сложнее. Возможно "из высших соображений" и полезно держать все строки в ресурсах, но очень уж напрягает.

Я бы остановился перед "i.e". Указание кодировки - это уже перегиб.

Напомню, что Юникоды разные бывают... а ввиду ограниченности типа CHAR двумя байтами, нам подходит только вариант UCS2. Многобайтовые штуки, с переменной длинной (UTF-8), использовать мы все равно не сможем, т. к. придется перепахивать очень много всего. Да и смысла в них особого нет.

Я тоже так развлекался. Кроме мелких косяков (которые надо вылавливать) полностью юникодный Блэкбокс отказывается работать под 98. А компилятор, кстати, переделывать практически не надо - вот там как раз никто не мешает хранить имена в utf-8.

Юникод только один, иначе в нем бы просто не было смысла. А при определении языка ссылки на физическое представление исходных текстов совершенно излишни. Хотя, можно ограничить набор допустимых символов, например BMP или даже ещё уже.


У меня работает под 98. Но он не полностью юникодный; я не стал переводить на вызовы юникодных функций, а просто вставил перекодировки.


Но ведь он игнорирует все символы выше 100X. Они даже не доходят до сканера.

Я же сказал "практически не надо" - как раз только сканер и поправить. И прямо в нём конвертить в utf-8 (токма в сообщениях компилятора придётся ставить обратную конвертацию, дабы кракозябров не получить)

P.S. Даже соврал - поправить придётся DevCMP.Get и DevCPS.Get

Не поможет.
Допустим есть текст 'Строка', т.е. 421 442 440 43E 43A 430. Сканер конвертирует его в utf-8. Но для парсера это теперь просто строка в 8-битной кодировке D0 A1 D1 82 D1 80 D0 BE D0 BA D0 B0.

Вот пришла мысль. А что если заставить сканер вместо "Строка" выдавать 421X+442X+440X+43EX+43AX+430X ?
Некрасиво, конечно, но должно работать.

Ну и что?
У нас всего два варианта:строка как имя и строка как константа.
Ну будет у нас переменнаая вместо "трям" называться "трС?Рј" - компилятору всё равно. Правда для корректного восприятия строковых констант всё же придётся поправлять исходники. Но не так много, как для имён.

Но в любом случае есть ещё два момента:
1. Кроме компилятора на имена типов завязаны также Kernel, Meta и вся подсистема хранения (то бишь формат файла документа). Как я уже где-то говорил, минимальными изменениями не отделаешься - юникод потянет за собой новую версию всей среды, местами плохо совместимую с оригиналом.
2. ОМС делает юникодную версию 1.6. Лучше нам не бежать впереди паровоза. Вот если то, что они сделают, нас не устроит...

Да как раз имена меня мало интересуют.
Но вот хотелось бы, чтобы Log.String("Привет") выводило бы именно "Привет" .


Когда они ещё сделают... А писать надо сейчас.

Кажется, действительно немного. Правда теперь все, что не ASCII становится юникодным, но может оно и к лучшему.

Естественно один (плохо выразился), но физическое представление разное. Как на него не обращать внимание, если вы оба предлагаете лезть в компилятор Ну скажите мне, в какой тип данных загнать UTF-8? В CHAR? При этом строго следуя стандарту Unicode, полустандарты не нужны.

Да нет, Игорь прав. Просто я выразился неточно - имелось в виду ограничение на набор символов. Что прямо ложится в диапазон CHAR

Строки я одолел.
Что касается имен, вопросы остаются. Вроде бы Latin-1 нам не нужен.
Можно сделать юникодные имена - там не так уж много работы. И совместимость с текущей версией можно соблюсти. Но вот совместимость с 1.6 ?

На счёт совместимости: самая главная проблема (да и единственная, кажется) - в документах имена типов хранятся как SHORTCHAR. Как это объехать?
А вообще с этим лучше в Координацию