?

Log in

No account? Create an account

[icon] /^.in$/
View:Recent Entries.
View:Archive.
View:Friends.
View:Profile.
View:Website (/me (домен, хотящийся в углу комнаты)).
Missed some entries? Then simply jump to the previous day or the next day.

Tags:
Security:
Subject:От текста к звёздам
Time:02:03 am
В последние несколько месяцев (лет?), на фоне посвящения себя во всё большее количество различных языков, у меня сложилось убеждение, что все современные инженерные проблемы в компутер сайанс происходят от недостаточных языковых абстракций. Сейчас я тут говорю о натуральных языках, а не языках программирования.

Пожалуй, окончательное понимание смысла жизни мне пришло после изучения персидской и более ранних клинописей.
Для всех изученных мной языков, фактом является то, что форма глифов их символов имеет чисто визуальные корни. Например, из книжки по иероглифическому письму я узнал, что латинская «A» — это корова (если перевернуть вверх ногами, то ножки станут рогами), а «S» — горы (если повернуть на 90 градусов). То есть вся письменность изначально была иероглифическая, а позже, повинуясь желанию людей писать много и быстро она упрощалась и спрямлялась. В результате получились сохранившиеся до сих пор китайские иероглифы (для которых существуют хронологии трансформаций символов, демонстрирующие как, например, изображение птицы превратилось в иероглиф 鳥), несохранившаяся клинопись, египетские иероглифы, латинский алфавит, а также, всякие другие письменности о которых я почти ничего не знаю (например, вязь).
Почему люди, придумавшие латинский алфавит отбросили смысловые значения глифов (типа «S <=> горы»), а сделали их только звуковыми — для меня остается загадкой, но мысль была весьма здравой, поскольку, например, носители языков со слоговым письмом очень плохо усваивают звуковой алфавит, а владеющие звуковым с легкостью осваивают слоговой. Конец введения.

Вооружившись этими знаниями у меня возникает сразу куча вопросов. Рассмотрим, например, такую интересную штуку как «БОЛЬШИЕ БУКВЫ». «Большого» иероглифа 鳥 нет, вообще для иероглифов нет деления на «прописные» и «строчные». В клинописи тоже нет такого деления. Зато и клинопись и китайские иероглифы сначала писали справа налево в столбики, а потом стали слева направо в строчки. Короче, я веду к тому, что прописные глифы символов оправданы только удобством деления предложений при чтении и, на самом деле, являются такими же элементами типографической разметки, как и переносы, курсив, полужирный, подчёркивания, перечёркивания и выделение цветом.
Однако почему-то символа, обозначающего букву «а», написанную салатовым курсивом («а») в таблице UNICODE нет, и чтобы её получить мне пришлось написать пару HTMLных тегов, а зато прописная буква «А» и символ смены направления теста в таблице UNICODE почему-то есть.

Теперь рассмотрим символ « » (пробел), который, по сути, является символом «предыдущее слово кончилось». Почему его нельзя использовать в URI? А почему символ «.» (точка), который означает «предыдущее предложение кончилось» в URI использовать можно? Потому что когда-то компьютеры были большими, а программисты, которые для них писали программы, не знали другого языка кроме английского. Так получился великий и ужасный ASCII, соблюдая обратную совместимость с которым, и не желая абстрагироваться от тупого кодирования всё новых и новых символов в таблицу UNICODE мы имеем все те чудесные проблемы, которыми наслаждаемся ежедневно, впечатывая в строку браузера что-то типа somedomain.org/some%20file.txt.

На мой взгляд, автоматическое преобразование из
это первое предложение. а это второе предложение

в
Это первое предложение. А это второе предложение.

не является столь уж непосильной задачей. А если надо специально что-то написать БОЛЬШИМИ БУКВАМИ, то и следовало бы ввести для этого специальные способы разметки.

Кроме того, если мне нужно ввести какой-то специальный значок для обозначения чего-нибудь, и я собираюсь его использовать в тексте в качестве термина, (например, значком кружки со смайликом я буду обозначать свою и только свою комнату), то чтобы произвести такую махинацию мне будет недостаточно юникода, потому что в нём наверняка нету моей кружки со смайликом. А пусть теперь все хотят добавить какой-нибудь свой значок в качестве глифа символа, тогда нам нужно коллоборативное (надеюсь я правильно написал это страшное слово) редактирование таблицы UNICODE, а такого нет.

Итого. Я постарался объяснить почему UNICODE — это плохо (кратко: поддерживает обратную совместимость с кошмарным ASCII, невозможно добавить новые символы), и что именно из проблем UNICODE вытекают проблемы современного представления данных, на примере URI, однако сюда же можно отнести и регулярные выражения (эскейпинг специальных символов достаточно часто используемыми символами), и теги HTML/XML (я хочу писать «>_<» по-человечески!), и прочие смешения мух с котлетами.

Что делать? Отделить котлеты от мух. Ровно так, как это делается в PostScript и DjVu.
По сути каждый символ (в самом низком представлении данных) — целое число. То как следует «понимать» и «рисовать» этот символ описывается таблицей соответствий (в рассматриваемом выше случае — таблицей UNICODE). Если разрешить определять свои таблицы, то можно разрешить определять и свои символы и свои глифы (и так оно и сделано в PostScript).

Например, будем кодировать текст символами не таблицы UNICODE, а давая глифам произвольные номера. Для того чтобы нарисовать такой текст, будет достаточно обеспечить его таблицей соответствий наших номеров глифам их символов, т.е. мы как бы «вшиваем» подмножество шрифта, которым этот текст должен быть отображён, в сам документ. Да, тут есть некий оверхед, но PostScript так делает и все довольны. Кроме того, если мы используем только символы таблицы UNICODE, то можно научить наше представление сообщать об этом, чтобы лишнего оверхеда вообще не было. Но это все технические глупости.

Вернёмся к логической части рассуждений. Можно заметить, что информация о том, что есть конкретный символ (номер) нас интересует только тогда, когда мы собираемся произвести над этим символом какое-то вычисление. Например, когда мы хотим нарисовать символ ­— нам нужен его глиф, когда хотим заставить компьютер произнести его — его звуковое представление, хотим перевод иероглифа на знакомый язык — нужна соответствующая запись словаря.

Теперь слегка абстрагируемся и перейдём от термина «таблица» к термину «функция» и вернёмся к таблице UNICODE.
По сути UNICODE — является функцией (отображением) из целых чисел в «смысл символов». Если посмотреть на его спецификацию, то он ровно так и устроен:
...
U+0041	LATIN CAPITAL LETTER A
U+0042	LATIN CAPITAL LETTER B
U+0043	LATIN CAPITAL LETTER C
U+0044	LATIN CAPITAL LETTER D
U+0045	LATIN CAPITAL LETTER E
...
U+00B3	SUPERSCRIPT THREE
U+00B4	ACUTE ACCENT
U+00B5	MICRO SIGN
U+00B6	PILCROW SIGN
U+00B7	MIDDLE DOT
U+00B8	CEDILLA
U+00B9	SUPERSCRIPT ONE
...

Также любой UNICODE шрифт, в свою очередь тоже является некоторой «функцией смысла», только на этот раз этот смысл — глиф символа.

Представим теперь, что у нас нет глобальной функции смысла (таблицы UNICODE), и рассмотрим ситуацию нескольких вычислительных процессов, где каждый из них имеет свою собственную функцию смысла. До тех пор пока эти процессы работают каждый над своим набором данных (символов) и пользуются только помощью своих функций смысла для выполнения каких-то задач (например, отображения текста на экране), то никаких проблем не возникает (каждый процесс преобразует текст в набор пикселей, а ОС этот набор рисует). Однако, как только два процесса хотят обменяться данными (например, я хочу сделать copy-paste из PostScript документа в текстовый редактор), то им необходимо соблюсти условие эквивалентности по Лейбницу (неразличимость) их функций смысла на множествах используемых ими символов. Например, если у меня есть просмотровщик документов и текстовый редактор, то при копировании текста из первого во второй им следует договориться о глифах символов, передаваемых через буфер обмена.

Можно сказать, что это всё элементарно, но если мы реализуем «функции смысла» и поддержание их неразличимости на общих данных между различными вычислительными процессами, то система получается куда более мощная чем UNICODE. Ведь до тех пор пока мы только читаем текст нам вообще не нужно соблюдать какие бы то ни было условия, кроме эквивалентности глифов одних и тех же символов в разных приложениях. А что-то столь же большое как UNICODE требуется только при поиске (потому что поиск — это обмен данными того кто ищет со всеми у кого он ищет), в свою очередь проблема создания такой глобальной функции смысла для организации поиска является локальной проблемой кластеризации, а не работой некой организации, порождающей огромные таблицы соответствий, на которые никак невозможно повлиять обычному индивиду. И на мой взгляд это тоже своего рода часть свободы слова: свобода символа и свобода глифа. С UNICODE такой свободы нет.
Многие ли из вас хранят на винчестере документы на пяти языках и больше? Я — нет. А тогда нафига мне нужны 200 мегабайт шрифтов, если мне достаточно двух процентов от всех этих символов?

Что касается пресловутого UNICODE, то единственное место, где он может быть полезен — кодирование данных в web.
Хотя и тут можно и без него обойтись, поддерживая неразличимость функций смысла между моей машиной и, например, специфическим доменом. Да, в результате, на глобальном уровне, получится что-то типа такой огромной распределённой таблицы символов, но эта таблица будет эволюционировать самостоятельно, а не под контролем какой-то организации. И, по-моему, это очень круто.
Кроме того, для каждого узла такой сети можно содержать локальную функцию смысла (получаемую кластеризацией локально используемых данных) и ещё функцию смысла функций смысла, предназначенную для поддержания глобальной таблицы соответствий. Тогда локальные данные будут хранится весьма оптимально (сколько символов используется, столько и есть в системе), а обмен с внешним миром будет производится с небольшим оверхедом (конвертация из локальной системы в глобальную и обратно).

Короче, можно сказать, что я тут описал своего рода Freenet, но для символов.

Такие дела.
withComments $ arr (take 31) >>> delay new

[icon] /^.in$/
View:Recent Entries.
View:Archive.
View:Friends.
View:Profile.
View:Website (/me (домен, хотящийся в углу комнаты)).
Missed some entries? Then simply jump to the previous day or the next day.