OberonCore
https://forum.oberoncore.ru/

Нужна ли русификация?
https://forum.oberoncore.ru/viewtopic.php?f=3&t=81		 Страница 1 из 3
Автор:  Trurl [ Понедельник, 26 Декабрь, 2005 18:06 ]
Заголовок сообщения:  Нужна ли русификация?
Надо ли нам создавать свой вариант языка?

Цитата:
3. Vocabulary and Representation
The representation of (terminal) symbols in terms of characters is defined using ISO 8859-1, i.e., the Latin 1 extension of the ASCII character set.

То есть, использование русских символов в идентификаторах запрещено описанием языка.
Цитата:
6.1 Basic Types
2. SHORTCHAR the characters of the Latin 1 character set (0X .. 0FFX)
3. CHAR the characters of the Unicode character set (0X .. 0FFFFX)

Types 2 and 3 are character types with the type hierarchy:
CHAR >= SHORTCHAR


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

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

Мне видится два варианта "наведения порядка":
1. Максимально ограничить ненадлежащее использование "коротких символов" и приложить усилия к тому, чтобы все символьные данные хранились в юникоде.
2. Зафиксировать и упорядочить использование различных кодировок и соответственно приложить усилия к тому, чтобы все преобразования проводились корректно.
Насколько я понимаю, ОМ планирует двигаться по первому пути.
Автор:  Илья Ермаков [ Понедельник, 26 Декабрь, 2005 22:26 ]
Заголовок сообщения: 
Самое разумное, действительно, использовать где только возможно CHAR.

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

ОМ уже от их поддержки никуда не денется, так как сама их ввела (по просьбе info21).
Автор:  Trurl [ Вторник, 27 Декабрь, 2005 10:45 ]
Заголовок сообщения: 
Илья Ермаков писал(а):
ОМ уже от их поддержки никуда не денется, так как сама их ввела (по просьбе info21).

Да нет там никакой поддержки .
Автор:  Иван Горячев [ Вторник, 27 Декабрь, 2005 12:40 ]
Заголовок сообщения: 
Самое разумное было бы попинать ОМС на предмет изменения языка в стиле:
Цитата:
3. Vocabulary and Representation
The representation of (terminal) symbols in terms of characters is defined using Unicode, i.e., UTF-16 encoded characters.


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

Ещё как вариант посмотреть на GPCP - как с символами у него. Вообще хорошо бы свести варианты BlackBox и GPCP к единому языку со всеми различиями на уровне модуля SYSTEM. Ну да это не наша забота - мы можем об этом только "активно намекать" производителям.
Автор:  Info21 [ Вторник, 27 Декабрь, 2005 17:19 ]
Заголовок сообщения: 
Ivor писал(а):
Самое разумное было бы попинать ОМС на предмет изменения языка в стиле: ... мы можем об этом только "активно намекать" производителям.


Попинаем и понамекаем. Тем более они и сами просят.
Автор:  Trurl [ Вторник, 27 Декабрь, 2005 17:31 ]
Заголовок сообщения: 
Я попытался действовать в стиле "Unicode Everywhere". Поправил HostCFrames, HostWindows и пр. так, чтобы все преобразовывалось в юникод.
Самая большая проблема – компилятор. Без русских идентификаторов жить вполне можно, а вот без русских констант – сложнее. Возможно "из высших соображений" и полезно держать все строки в ресурсах, но очень уж напрягает.
Автор:  Trurl [ Вторник, 27 Декабрь, 2005 17:34 ]
Заголовок сообщения: 
Ivor писал(а):
3. Vocabulary and Representation
The representation of (terminal) symbols in terms of characters is defined using Unicode, i.e., UTF-16 encoded characters.


Я бы остановился перед "i.e". Указание кодировки - это уже перегиб.
Автор:  Борис Рюмшин [ Вторник, 27 Декабрь, 2005 19:35 ]
Заголовок сообщения: 
Цитата:
Указание кодировки - это уже перегиб.


Напомню, что Юникоды разные бывают... а ввиду ограниченности типа CHAR двумя байтами, нам подходит только вариант UCS2. Многобайтовые штуки, с переменной длинной (UTF-8), использовать мы все равно не сможем, т. к. придется перепахивать очень много всего. Да и смысла в них особого нет.
Автор:  Иван Горячев [ Среда, 28 Декабрь, 2005 00:17 ]
Заголовок сообщения: 
Trurl писал(а):
Я попытался действовать в стиле "Unicode Everywhere". Поправил HostCFrames, HostWindows и пр. так, чтобы все преобразовывалось в юникод.
Самая большая проблема – компилятор. Без русских идентификаторов жить вполне можно, а вот без русских констант – сложнее. Возможно "из высших соображений" и полезно держать все строки в ресурсах, но очень уж напрягает.


Я тоже так развлекался. Кроме мелких косяков (которые надо вылавливать) полностью юникодный Блэкбокс отказывается работать под 98. А компилятор, кстати, переделывать практически не надо - вот там как раз никто не мешает хранить имена в utf-8.
Автор:  Trurl [ Среда, 28 Декабрь, 2005 09:21 ]
Заголовок сообщения: 
Борис Рюмшин писал(а):
Напомню, что Юникоды разные бывают...

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

Ivor писал(а):
Я тоже так развлекался. Кроме мелких косяков (которые надо вылавливать) полностью юникодный Блэкбокс отказывается работать под 98.

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

Цитата:
А компилятор, кстати, переделывать практически не надо - вот там как раз никто не мешает хранить имена в utf-8.

Но ведь он игнорирует все символы выше 100X. Они даже не доходят до сканера.
Автор:  Иван Горячев [ Среда, 28 Декабрь, 2005 11:04 ]
Заголовок сообщения: 
Trurl писал(а):
Но ведь он игнорирует все символы выше 100X. Они даже не доходят до сканера.


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

P.S. Даже соврал - поправить придётся DevCMP.Get и DevCPS.Get
Автор:  Trurl [ Среда, 28 Декабрь, 2005 13:02 ]
Заголовок сообщения: 
Ivor писал(а):
Я же сказал "практически не надо" - как раз только сканер и поправить. И прямо в нём конвертить в utf-8

Не поможет.
Допустим есть текст 'Строка', т.е. 421 442 440 43E 43A 430. Сканер конвертирует его в utf-8. Но для парсера это теперь просто строка в 8-битной кодировке D0 A1 D1 82 D1 80 D0 BE D0 BA D0 B0.
Автор:  Trurl [ Среда, 28 Декабрь, 2005 13:09 ]
Заголовок сообщения: 
Вот пришла мысль. А что если заставить сканер вместо "Строка" выдавать 421X+442X+440X+43EX+43AX+430X ?
Некрасиво, конечно, но должно работать.
Автор:  Иван Горячев [ Среда, 28 Декабрь, 2005 13:34 ]
Заголовок сообщения: 
Trurl писал(а):
Не поможет.
Допустим есть текст 'Строка', т.е. 421 442 440 43E 43A 430. Сканер конвертирует его в utf-8. Но для парсера это теперь просто строка в 8-битной кодировке D0 A1 D1 82 D1 80 D0 BE D0 BA D0 B0.


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

Но в любом случае есть ещё два момента:
1. Кроме компилятора на имена типов завязаны также Kernel, Meta и вся подсистема хранения (то бишь формат файла документа). Как я уже где-то говорил, минимальными изменениями не отделаешься - юникод потянет за собой новую версию всей среды, местами плохо совместимую с оригиналом.
2. ОМС делает юникодную версию 1.6. Лучше нам не бежать впереди паровоза. Вот если то, что они сделают, нас не устроит...
Автор:  Trurl [ Среда, 28 Декабрь, 2005 14:58 ]
Заголовок сообщения: 
Да как раз имена меня мало интересуют.
Но вот хотелось бы, чтобы Log.String("Привет") выводило бы именно "Привет" :).

Цитата:
ОМС делает юникодную версию 1.6. Лучше нам не бежать впереди паровоза. Вот если то, что они сделают, нас не устроит...

Когда они ещё сделают... А писать надо сейчас.
Автор:  Trurl [ Среда, 28 Декабрь, 2005 18:03 ]
Заголовок сообщения: 
Ivor писал(а):
Правда для корректного восприятия строковых констант всё же придётся поправлять исходники. Но не так много, как для имён.

Кажется, действительно немного. Правда теперь все, что не ASCII становится юникодным, но может оно и к лучшему.
Автор:  Борис Рюмшин [ Четверг, 29 Декабрь, 2005 01:33 ]
Заголовок сообщения: 
Trurl писал(а):
Борис Рюмшин писал(а):
Напомню, что Юникоды разные бывают...

Юникод только один, иначе в нем бы просто не было смысла.


Естественно один (плохо выразился), но физическое представление разное. Как на него не обращать внимание, если вы оба предлагаете лезть в компилятор :) Ну скажите мне, в какой тип данных загнать UTF-8? В CHAR? :) При этом строго следуя стандарту Unicode, полустандарты не нужны.
Автор:  Иван Горячев [ Четверг, 29 Декабрь, 2005 06:09 ]
Заголовок сообщения: 
Да нет, Игорь прав. Просто я выразился неточно - имелось в виду ограничение на набор символов. Что прямо ложится в диапазон CHAR
Автор:  Trurl [ Четверг, 29 Декабрь, 2005 15:54 ]
Заголовок сообщения: 
Строки я одолел. :)
Что касается имен, вопросы остаются. Вроде бы Latin-1 нам не нужен.
Можно сделать юникодные имена - там не так уж много работы. И совместимость с текущей версией можно соблюсти. Но вот совместимость с 1.6 ?
Автор:  Иван Горячев [ Пятница, 30 Декабрь, 2005 00:17 ]
Заголовок сообщения: 
На счёт совместимости: самая главная проблема (да и единственная, кажется) - в документах имена типов хранятся как SHORTCHAR. Как это объехать?
А вообще с этим лучше в Координацию :)
Страница 1 из 3 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/