OberonCore https://forum.oberoncore.ru/ |
|
Есть ли в природе живые специалисты по A2? https://forum.oberoncore.ru/viewtopic.php?f=22&t=6342 |
Страница 2 из 6 |
Автор: | Sergej Durmanov [ Суббота, 26 Январь, 2019 12:58 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
Да вроде бы в сообщении о языке |
Автор: | budden [ Суббота, 26 Январь, 2019 13:08 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
Я имею в виду, где это закодировано. Впрочем, не так уж важно это. |
Автор: | budden [ Суббота, 26 Январь, 2019 13:37 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
А кстати я не могу найти сообщение о языке. Упоминание о типах CHAR16 есть только в википедии, но оттуда я не могу по ссылкам найти документ или хотя бы связанную цепочку документов, в которых было бы чётко показано, что в A2 есть CHAR16. Может кто-нибудь подсобить? Часть ссылок здесь вообще битые. http://www.ocp.inf.ethz.ch/wiki/Documentation/Language |
Автор: | Kemet [ Суббота, 26 Январь, 2019 14:17 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
В A2 нет CHAR16 и CHAR32. Используется CHAR и ARRAY OF CHAR, который, в то же время, строка в UTF8. В подсистеме Text используется Texts.Char32, и ARRAY OF Texts.Char32. Это UCS4. Репорт устарел, нового пока нет, так как состояние языка пока не зафиксировано. Можно глянуть в FoxParser.Mod текущее состояние - там везде расставлено формальное описание конструкций. Можно, также, сгенерировать документацию |
Автор: | budden [ Воскресенье, 27 Январь, 2019 00:50 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
А есть возможность использовать кодовые страницы, хотя бы KOI-8R? |
Автор: | budden [ Воскресенье, 27 Январь, 2019 01:04 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
KOI-7 H1 Код: процедуре сЕТ* (ЦОЛОР, БГЦОЛОР, ЖОФФ : лонгинт; цонст НАМЕ : арраы оф цхар; СИЗЕ : лонгинт; СТЫЛЕ : сет); бегин селф.ЦОЛОР := ЦОЛОР; селф.БГЦОЛОР := БГЦОЛОР; селф.ЖОФФ := ЖОФФ; нев(ФОНТиНФО); цопы(НАМЕ, ФОНТиНФО.НАМЕ); ФОНТиНФО.СИЗЕ := СИЗЕ; ФОНТиНФО.СТЫЛЕ := СТЫЛЕ енд сЕТ; Сразу и ключевые слова в нижнем регистре... |
Автор: | Kemet [ Воскресенье, 27 Январь, 2019 07:24 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
Цитата: А есть возможность использовать кодовые страницы, хотя бы KOI-8R? Использовать где? Если учесть, что Text - UCS4, а остальное, где руки дотянулись, UTF8. Есть также конвертеры CyrillicUtilities.Mod, куда можно добавить KOI-7( KOI-8R есть ). Есть подсистема IME |
Автор: | budden [ Воскресенье, 27 Январь, 2019 11:48 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
В исходных текстах для именования переменных и функций, а значит - везде по компилятору, линкеру, символьным файлам, командному интерпретатору. Вот всё это. Т.е. либо заменять char на более широкий, либо использовать 8-битные кодировки. |
Автор: | Kemet [ Воскресенье, 27 Январь, 2019 17:04 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
Если компилировать из IDE, то можно выбрать Format. В остальном нет. Лучше допилить до глобального использования UTF8 |
Автор: | budden [ Воскресенье, 27 Январь, 2019 22:39 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
Вот в этом фрагменте кода из FoxScanner.mod что Вы понимаете под «глобально использовать utf-8?» Код: WHILE (s # EndOfText) & (s # End) & (s # With) & (s # Unequal) DO token.position := position; endPos := position.start; IF (ch >= 'A') & (ch <= 'Z') OR (ch >= 'a') & (ch <= 'z') THEN newline := FALSE; GetIdentifier(token); Здесь ch - глоб. перем типа CHAR, которая получается с помощью Streams.Reader.Char . Если мы мыслим в терминах байт и хотим сюда запихнуть кириллицу, то в этом месте нужно парсить utf-8. Если же мы хотим использовать какой-нибудь условный Utf8String.Reader.Char, то ch должно уже быть чем-то типа ucs-4, и нужно менять все места, где оно используется, и дальше вниз по течению заменять CHAR на Char32. Может я что-то не понял, но мне кажется, что некорявое решение здесь только через ucs-4, а оно довольно трудоёмкое. |
Автор: | budden [ Понедельник, 28 Январь, 2019 00:11 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
Слегка покопался и упёрся в то, что CHR может вернуть только ASCII. Т.е., KOI-8 не поддерживается. Вот до чего доводит увлечение Utf-8. А зачем оно вообще нужно? Я согласен, что оно неизбежно в использовании в интернете, т.е., безусловно, нужно уметь читать и писать файлы в этой кодировке. Но внутренне представление в utf-8 - это не более, чем кривой костыль для того, чтобы не переделывать работающие юникс-программы. При этом, в рамках ASCII они действительно продолжают работать, а вне оного встречаются глюки, которых я уже наелся в tcl/tk. Я попробовал компилировать с форматом KOI-8R в PET - что-то успехов никаких. Судя по выводу вот этой программки Код: MODULE z; IMPORT KernelLog; PROCEDURE Do*; VAR z:ARRAY 3 OF CHAR; BEGIN z := 'ю'; KernelLog.Ln; KernelLog.String(z); KernelLog.Ln; KernelLog.String("First char: "); KernelLog.Int(ORD(z[0]),0); KernelLog.Ln; KernelLog.String("Second char: "); KernelLog.Int(ORD(z[1]),0); KernelLog.Ln; END Do; END z. независимо от формата файла, содержащего эту программу (а это KOI-8R и в PET тоже установлено KOI-8R) всё равно буква 'ю' при чтении превращается в utf-8. Т.е. наивная надежда получить внутреннее представление строк в KOI-8R сразу же разрушилась. Я уже давно пришёл к выводу, что utf8 - это империалистическая кодировка, которая решает проблемы США за счёт остальных стран. Поскольку я вообще полез в эту A2, чтобы сделать «учебную русскоязычную ОС» или продукт для собственного употребления, в котором не будет дискриминации русского языка, то я категорически не принимаю использование utf-8 для внутреннего представления строк. Если я не осилю это переделать, то этот продукт просто не для меня. Дальше вопрос к Вам, kemet, как к одному из представителей сообщества A2 - что Вы думаете на тему замены utf8 внутри везде на UCS4 (или 16-разрядную, если китайцев побоку) кодировку, допиливания типа CHAR32 или CHAR16? И что на эту тему думает сообщество? Всё же Texts.Char32 - это не более, чем псевдоним для LONGINT. Такой уровень сервиса со стороны компилятора явно недостаточен. |
Автор: | Kemet [ Понедельник, 28 Январь, 2019 06:42 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
budden писал(а): Если мы мыслим в терминах байт и хотим сюда запихнуть кириллицу, то в этом месте нужно парсить utf-8 Если работать в PET, то внутри UCS4 или UTF8. Конвертеры преобразуют в эту форму.Если же в PET написать программу в KOI8R, сохранить на диск и компилировать командой Compiler.Compile, то компилятор работает с файлом напрямую через потоки, и там прочитается то, что ты записал - байт c символом в KOI8R. Но как по мне все эти кодировки маразм чистой воды. Распарсить UTF8 не большая проблема. Но я так и не понял, зачем тебе это. |
Автор: | Борис Рюмшин [ Понедельник, 28 Январь, 2019 08:53 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
budden писал(а): ...замены utf8 внутри везде на UCS4... UTF-8 это представление кодами переменной длинны символов Unicode. UCS-4 (UTF-32) тоже самое, только 32-битными целыми. Шило на мыло? И при всё уважении к ГОСТ (в данном случае это ГОСТ 19768-74), KOI-8R -- жуткий анахронизм, кстати, зафиксированный уже даже не в ГОСТ, а в RFC1489. Там даже порядок букв через одно место, чтобы коррелировать с латиницей. |
Автор: | Kemet [ Понедельник, 28 Январь, 2019 09:17 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
budden писал(а): Слегка покопался и упёрся в то, что CHR может вернуть только ASCII. CHR и ORD дают обратимый результат: Цитата: MODULE Test; PROCEDURE Do*; VAR x, y: LONGINT; ch: CHAR; BEGIN x := 254; ch := CHR(x); y := ORD(ch); TRACE( x, y ); END Do; END Test.Do ~ Вывод: {P cpuid= 0, pid= 11804 Test.Do@107:x= 254; y= 254; } Цитата: Судя по выводу вот этой программки Всё, что заключено в кавычки это, в общем случае, строковой литерал и могут быть, на первый взгляд, странности, потому что подсистема Text юникодная. А вот символы вида 09X никуда не конвертируются. |
Автор: | budden [ Понедельник, 28 Январь, 2019 09:31 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
Kemet писал(а): budden писал(а): Если мы мыслим в терминах байт и хотим сюда запихнуть кириллицу, то в этом месте нужно парсить utf-8 Если работать в PET, то внутри UCS4 или UTF8. Конвертеры преобразуют в эту форму.Если же в PET написать программу в KOI8R, сохранить на диск и компилировать командой Compiler.Compile, то компилятор работает с файлом напрямую через потоки, и там прочитается то, что ты записал - байт c символом в KOI8R. Но как по мне все эти кодировки маразм чистой воды. Распарсить UTF8 не большая проблема. Но я так и не понял, зачем тебе это. Compiler.Compile с единственным параметром - путём к файлу с кириллицей в KOI-8R - говорит "illegal character in string". Т.е. я так думаю, что внутри компилятора зашито мнение о том, что файл закодирован в utf-8. Параметра про кодировку или формат я в FoxCompiler.mod не нашёл. Нужно мне это для русскоязычных идентификаторов, как в ББЦБ, чтобы писать «PROCEDURE Печатай» и т.п. |
Автор: | budden [ Понедельник, 28 Январь, 2019 09:41 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
Цитата: MODULE Test; PROCEDURE Do*; VAR x, y: LONGINT; ch: CHAR; BEGIN x := 254; ch := CHR(x); y := ORD(ch); TRACE( x, y ); END Do; END Test.Do ~ Отсутствие документации печалит. Согласно документу A2 Programming Quickstart GUide от 2010 CHR и ORD понимают только ASCII. Теперь получается, что это неправда. А вот конструкция nnX точно не понимает ничего за пределами ASCII. С0X - это ошибка компиляции, поэтому задать таким видом «ю» не выйдет. Да его и не будет во входном потоке (насколько это пока что показывают эксперименты), а вместо него будет 209 и 142 последовательно. Спасибо за TRACE . |
Автор: | budden [ Понедельник, 28 Январь, 2019 09:51 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
А, кстати, в идентификаторе ваш рецепт сработал, после того, как я пропатчил сканер. Т.е. в строке «ю» - нельзя, а в идентификаторе - можно. Патченый кусок FoxScanner выглядит примерно так (код неправильный, поэтому его стёр я) Код: тут была неправда. Правда, TRACE уже не смог напечать имя «ю», т.е. в любом случае похоже, что обход всего с вмешательством повсюду неизбежен. Потому что чтение идентификатора - одно, чтение строки - другое, печать - третье. Именно поэтому введение типа для литер в кодировке UCS4 (например, CHAR32), позволяет создать уровень абстракции, при котором труда понадобится меньше. |
Автор: | budden [ Понедельник, 28 Январь, 2019 10:28 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
Понял, я не там пропатчил. В общем, похоже, что можно как-то пинками заставить работать KOI-8R, например, однобуквенные идентификаторы в KOI-8R уже работают (см. код GetNextSymbol и в конце его ELSE, которая считает, что всё непонятное - это начало идентификатора - скорее всего это баг, но в данном случае он полезен!). Но это всё неправильно. Если у нас культ простоты, то должен быть один тип CHAR. Если мы дружим с CJK, то 32 бита. Если нет - то 16. При этом мы понимаем, что простота имеет свою цену. Например, нам может понадобиться более мощный компьютер для решения простой задачи. Это входит в цену простоты - зато у нас только один CHAR, а не несколько, определения типов и их конвертация упрощается. А также должен быть тип BYTE. |
Автор: | budden [ Понедельник, 28 Январь, 2019 12:33 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
Борис Рюмшин писал(а): Шило на мыло? Отнюдь. Хотя бы возьмите операцию взятия i-го элемента строки. Но вообще разница очевидна, странно, что тут вопрос возникает. Цитата: Там даже порядок букв через одно место, чтобы коррелировать с латиницей. В utf-8 всё ещё хуже - там русских букв как объекта в памяти вообще нет. При чтении из потока это две идущих подряд буквы, т.е. все алгоритмы работы с текстом резко усложняются и требуют ручной переработки с привлечением ума. 8-битная кодировка мне не особо нравится, но если рассчитывать только на свои силы, то выкинуть utf-8 и перейти на 8-битную кодировку в компиляторе мне по силам. А вот допилить полноценную поддержку юникода - уже вовсе не факт. Т.е. решения принимаются исходя из наличных ресурсов. |
Автор: | Kemet [ Понедельник, 28 Январь, 2019 12:40 ] |
Заголовок сообщения: | Re: Есть ли в природе живые специалисты по A2? |
budden писал(а): Дальше вопрос к Вам, kemet, как к одному из представителей сообщества A2 - что Вы думаете на тему замены utf8 внутри везде на UCS4 (или 16-разрядную, если китайцев побоку) кодировку, допиливания типа CHAR32 или CHAR16? И что на эту тему думает сообщество? Всё же Texts.Char32 - это не более, чем псевдоним для LONGINT. Такой уровень сервиса со стороны компилятора явно недостаточен. UTF8, на мой взгляд, хорошая транспортная кодировка. Для чтения и записи достаточно байтового потока. Данные могут храниться в обычных однобайтовых строках и это хорошо, так как переделки заключаются в увеличении длины строки и использованиb процедур из USF8Strings вместо Strings, а это делается простой заменой в импорте Strings := UTF8Strings. Остальное правится быстро по мере надобности. Дело в том, что есть коммерческий софт, основанный на А2. И нужны минимальные телодвижения, чтобы оно продолжало работать. Вспоминается эпичный период, когда в Дельфи таки решили перейти на юникод, поломав многое из того, что работало. В чем-то UTF8 не оптимальна, но глобальное использование UTF32 это вообще маразм - чудовищный оверхед и это, в общем-то мало чего решает, так как и в UTF32 нельзя просто адресоваться по индексу, необходимо сканировать строку. Да, в гораздо меньших объемах чем UTF8 или UTF16, но всё же. Единственный плюс - более-менее прямое использование таблиц преобразования. С UTF16 другая проблема - суррогаты, хотя он более оптимальный по хранению, но и технокалия больше. Но всё-же UTF16 хороший выбор для подсистемы Text, в которой сейчас UCS4. Я думаю, что нельзя оставить один тип. Мне в микроконтроллерах более чем достаточно однобайтового CHAR а если не достаточно - UTF8 спасает отцов русской демократии. В общем - исходники должны храниться в UTF8, никаких экзотических кодировок в системе быть не должно и не должно быть предположений об их существовании = где нужно принимаем/передаем UTF8. |
Страница 2 из 6 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |