SP-Forth - DEV (rus)

word, vocabulary, namespace

34 Messages

1 2

Ruvim Pinka

word, vocabulary, namespace

Reply Threaded

Привет!

2008/8/3 Andrey Cherezov <andrey@...>

В случае "синтаксиса" можно указать: my_cool_function(3,2)

Щас буду кусаться :-[]

:) ну, ты же допускаешь отдавать даже целой строкой, а тут отдается одним словом. Принципиальной разницы нету, имхо.

Цитирую (по Message-ID: <4894DEE6.2070001@...>):
> можно вызывать нечто по имени или по номеру, или еще как (допустим, просто целой строкой нескольких команд на чуждом языке, передаваемую исполнителю через единую точку входа

В случае синтаксиса факт указания числа параметров поддается
автоматической проверки,

А факт указания чего-то там в скобках делу проверки не поможет,

Проверяется всего лишь то, указанны эти дополнительные параметры, или не указанны. (т.к. зевки заключаются в их пропуске).

[...]

Не принимай близко к сердцу число параметров, мы ведь обычно не используем
API напрямую, а все равно всегда пишем более удобные форт-обертки, т.е. эта
"сложность" сразу же инкапсулируется, после чего голову можно проветрить, забыть
детали и писать на еще более простом форте.

Да, согласен. Но, мы то уже о более широком, о применимости вообще в форте "сложных" слов — т.е., слов, которые для форт-транслятора — слова (монолитный токен), а для целевой подсистемы — набор токенов. Тоже самое и о строках (для форт-транслятора строка, для целевой подсистемы фраза на его языке).

[...]

Ты что, забыл, что форт-программисты
1) не ошибаются :), поэтому могут, в частности, легко обходиться без контроля типов
и всех прочих прибамбасов, которые придумали для тупых и ленивых за 40 лет;
форт-программисты используют только "спеллчекер" - "слово не найдено".
2) когда они все-таки ошибаются (временно становятся не-форт программистами,
а усталыми и невнимательными студентами), форт быстро выводит их на чистую
воду магическими словами exception и т.п.

Да, это сила! :)
Но, с пропуском доп-параметра я поначалу тупил: как это так, я даю все, что надо, прямо по доке, а оно падает! ;)

Я пишу "синтаксис" в кавычках, т.к. для форт-трарнслятора это
все-равно одно слово, а его внутренний формат разбирала бы подсистема
поддержки so. Точно так же, как мы пишем ~ac/lib/str5.f и spf
отрабатывает подключение файла; для транслятора это одно слово, но оно
имеет внутренний формат (путь, каталоги, слэши), который разбирает
файловая подсистема.

Ну, вообще-то я и для файловой системы сделал словари - files.f :)

Да, точно!
[...]

Припоминаю, что была идея фикс, что это тоже должна понимать
форт-система, и тогда достаточно писать через пробел вместо слэша: ~ac
lib str5.f

Ну да, так и есть: см.
WINDOWS system32 drivers etc hosts

Но, это не работает внутри определений. Да и вообще не понятно, как откладывать такой код. Ведь, эти имена надо связывать поздне, при исполнении, а не при откладывании. Т.е., я нахожу, что сама идея с отображением файловой системы на иерархию форт-словарей еще не достаточно проработана.

[...]

— но, такое использование трудно поддается контролированию
в простом форт-тексте.

Контролируется-то оно нормально

Я говорю о следующем контроле:
[...]

можем случайно найти одноименное слово в совсем другом несовместимом namespace.

Это проблема существует в классическом форте на очень глубоком уровне.
Например, фраза ALSO ABC ... PREVIOUS небезопасна в принципе, т.к. в словаре ABC может быть слово PREVIOUS со совсем другим значением (или оно там может как раз быть создано). Это одно из обстоятельств, породивших forthml ;) Т.к. фараза abc <also> ... </also> безопасна всегда.

[...]

Раньше мы вообще не могли вызывать API-функции просто по имени
без их предварительного объявления (т.е. компиляции обертки)

Кстати. А ведь сейчас все еще требуется объявление библиотеки. Может,
и эту декларацию завтоматизировать подобным образом? ;)

Искать словарь по слову?

Нет, я о следующем:

[...]

ALSO SO NEW: sqlite3.dll
Ok
ALSO SO NEW: sqlite3.dll
sqlite3.dll isn't unique
Ok

А что если обойтись совсем без "NEW:", а создавать обертку при первом упоминании, как это делается для функций?

ALSO SO sqlite3.dll
Ok
ALSO SO sqlite3.dll
Ok
(тут два верхних значения стека контекста — это словарь sqlite3.dll, один и тот же форт-объект).

Получается, логически в словаре SO собранны все все dll с сишным форматом вызова функций.

Ну а самое главное - внешние dll/so - это словари и есть. Разве нет?

Конечно, словари! :)  Просто, они не нативно-фортовые.

Только тем, что readonly.

я имею ввиду, что конкретный dll-файл физически содержит в себе некий словарь, как упорядоченное множество ассоциаций имен и точек входа. И, ессно, этот словарь не является нативным форт-словарем. Точки входа не являются исполнимыми токенами форта (xt) и не позволяют вызов по EXECUTE (в общем случае так, но, могут быть и исключения ;).

Один подход: сделать обертку над этим словарем, так что из форт-системы он будет виден как форт-словарь (например, при поиске создавать в отдельном хранилище xt — обертки к точкам входа).
Другой, независимый от первого, подход: иметь аналоги слов EXECUTE и COMPILE, работающие для токенов из этого внешнего словаря.

В so-xt.f сделана смесь этих подходов. При поиске в режиме 0 создается xt прямо в текущем хранилище и это xt возвращается, а при поиске в режиме 1 делается компиляция вызова прямо в текущее хранилище и возвращается xt слова NOOP. Т.е., аналоги COMPILE и EXECUTE присутствуют, но без выделения их в независимую часть.

Кстати, было бы очень заманчиво научиться сохранять
любой словарь форта в виде dll ;)

Сохранять в виде dll весь образ (со всеми словарями, и т.п.), а экспортировать только имена из заданного словаря? Это не трудно. Было бы трудней сохранить "только один словарь" ;)

"дерево" конекста.

[...]

Хотя, если ветки не жестко привязаны, к родителям,
то возможностей такая схема дает больше, согласен. Но и путаницы больше. Контексты
и без того любят сложные ошибки устраивать...

Да, ветки не жестко привязанны к родителям.

--
Ruvim

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Spf-dev mailing list
Spf-dev@...
https://lists.sourceforge.net/lists/listinfo/spf-dev

Ruvim Pinka

Re: word, vocabulary, namespace

Reply Threaded

Предыдущее письмо было ответом на сообщение "Message-ID: <489520B3.4000303@...>" под темой "FFI" от ~ac, "Sun, 03 Aug 2008 06:06:27 +0300". Gmail-клиент, злыдень, упустил заголовок In-Reply-To при смене темы письма :(

--
Ruvim

Andrey Cherezov

Re: word, vocabulary, namespace

Reply Threaded

In reply to this post by Ruvim Pinka

Some javascript/style in this post has been disabled (why?)

Добрый день, Ruvim Pinka!

Ваше сообщение от 03.08.2008 16:05:

:) ну, ты же допускаешь отдавать даже целой строкой, а тут отдается одним словом. Принципиальной разницы нету, имхо.

Принципиальная разница в том, что целой строкой передается предложение на языке другой системы (sql, например, или javascript,
или файловый путь), а ты предлагаешь придумывать новый синтаксис _для форта_.

Ну да, так и есть: см.
WINDOWS system32 drivers etc hosts

Но, это не работает внутри определений.

Примеры я вроде давал в итераторах.

Да и вообще не понятно, как откладывать такой код. Ведь, эти имена надо связывать поздне, при исполнении, а не при откладывании. Т.е., я нахожу, что сама идея с отображением файловой системы на иерархию форт-словарей еще не достаточно проработана.

Да, такие примеры как ns/files.f, ns/xml.f, ns/sqlite3.f даны просто как демонстрация универсальности идеи - все внешние namespaces можно легко и достаточно логично обрабатывать теми же способами, как словари форта. Для "промышленного" использования из всего этого готовы лишь привязки dll/so, а остальные на уровне реально работающих прототипов. Т.е. их можно использовать, например, в IMAP-сервере для отображения иерархий любых словарей, внешних и внутренних (скриншоты я приводил неоднократно - год или два назад, или даже ранее), но даже в случае конкретно IMAP это может работать хуже (с точки зрения потребления ресурсов), чем более низкоуровневые, менее "генерализованные" методы. Но это, увы, всегда так.

Что касается раннего/позднего связывания - да, "по умолчанию" внешние словари привязываются уже в рантайме, конечно. На этапе компиляции можно контролировать наличие имен только в статичных namespaces типа dll/so/idispatch, а в БД/xml/файлов уже нельзя (без накладывания ограничений на обрабатываемые структуры).

Это проблема существует в классическом форте на очень глубоком уровне.
Например, фраза ALSO ABC ... PREVIOUS небезопасна в принципе, т.к. в словаре ABC может быть слово PREVIOUS со совсем другим значением (или оно там может как раз быть создано). Это одно из обстоятельств, породивших forthml ;) Т.к. фараза abc <also> ... </also> безопасна всегда.

Да, в форте очень глубоко засела философская идея отрицания необходимости жесткого набора ключевых слов. Твоё безопасное <also> - это ключевое слово. Это просто не форт-стиль. А в форте принимаешь свободу вместе с её недостатками. Указанная тобой проблема чаще всего всплывает в целевых компиляторах. Там это решается удержанием на вершине стека словарей инструментального словаря, т.е. чтобы целевой IF не перекрывал инструментальный IF, например. Это та причина, по которой стек словарей 94 лучше (практичнее) дерева словарей 83. Т.е. вершина стека словарей является временным набором "ключевых слов" без необходимости соблюдения этого договора вечно.

ALSO SO NEW: sqlite3.dll

А что если обойтись совсем без "NEW:", а создавать обертку при первом упоминании, как это делается для функций?

А как форту узнать, что это первое упоминание - упоминание некой dll, а не просто опечатка (или автоматический литерал типа чисел)?
С функциями dll все понятно - если нет в контексте (включая контекстные dll/so), то опечатка. Если контекстным словарем является файловая
система (files.f), то можно, конечно, предусмотреть выполнение найденного (в словаре файловой системы) слова sqlite3.dll, делающее его словарем. Но тогда мы потеряем возможность читать такой файл как файл. Т.е. либо нужны разные контексты файловых систем, либо литеральная запись для не-выполнения файлов (ну как кавычка " ' "). В общем, это тянет за собой слишком много предположений или соглашений.

ALSO SO sqlite3.dll
Ok
ALSO SO sqlite3.dll
Ok
(тут два верхних значения стека контекста — это словарь sqlite3.dll, один и тот же форт-объект).

Ты удалил "sqlite3.dll isn't unique", а эта строка - то, ради чего приводился пример. Форт не делает предположений о том, зачем программист дважды определяет одно и то же слово - программисту виднее. Он просто смиренно говорит "я где-то это уже видел".

Получается, логически в словаре SO собранны все все dll с сишным форматом вызова функций.

Ну, в каком-то смысле так, все доступные системе dll. Так удобно. Но автоматически перебирать все эти dll неудобно (нереально по скорости (если сделать SO спец-словарем "все dll", то он будет просматриваться при компиляции каждого слова, когда включен в контекст, а оно и при однократном-то применения затянется на полчаса), и неуправляем порядок перебора), поэтому лучше указать имя dll явно. Или вести кэш имен всех функций всех dll в какой-то БД, что наверное черезчур, да даже и в этом случае будет тормоз и по-прежнему с неуправляемым порядком поиска. И системной (ОС) поддержки вычленения списка функций из dll нет, в отличие от поиска по имени dlopen.

В общем, с какой стороны не подходи, лучше чем реализованный вариант сложно найти. Или у меня уже глаз замылен?

я имею ввиду, что конкретный dll-файл физически содержит в себе некий словарь, как упорядоченное множество ассоциаций имен и точек входа. И, ессно, этот словарь не является нативным форт-словарем. Точки входа не являются исполнимыми токенами форта (xt) и не позволяют вызов по EXECUTE (в общем случае так, но, могут быть и исключения ;).

В этой либе я сделал так, что они являются выполнимыми xt. Т.е. физически у них, конечно, разный формат, но это можно 1) почти безболезненно игнорировать, 2) или сделать так, чтобы форт-словарь имел в точности ту же бинарную структуру, что и в dll. Мешает только различие в соглашениях о связях между фортом и Си, т.е. необходимость копирования параметров в другое место при вызове. Но это различие тоже можно игнорировать, т.к. синтаксическая разница несущественна (указание числа параметров, но ведь мы имеем опыт работы и без указания числа параметров - просто это оказалось непортабельным). Между виндовым (паскалевским) и юниксовым (сишным) соглашениями о связях та же самая существенная разница, требующая разного кода вызова и поэтому _разного синтаксиса_ в объявлении таких функций в Си (при экспорте). Т.е. форт ничуть не менее "нативен" для dll, чем виндовый "паскаль". Си не требуется указания числа параметров только потому что он это число берет из заголовочных файлов, и если их нет, то компилятор не сможет работать вообще. А форт сможет, т.е. работает с Си лучше чем Си, потому что мы учитываем эту "физику" явно :)

Один подход: сделать обертку над этим словарем, так что из форт-системы он будет виден как форт-словарь (например, при поиске создавать в отдельном хранилище xt — обертки к точкам входа).

Так и реализовано, разве что хранилище не отдельное - это на одну строку исправлений, если так надо.

Другой, независимый от первого, подход: иметь аналоги слов EXECUTE и COMPILE, работающие для токенов из этого внешнего словаря.

Это не независимый, а на самом деле продолжение того же метода: в идеале для каждой пары разнородных ("физически") словарей должен быть свой способ откладывания ссылки (позднего связывания) из одного на другой, т.е. свой вариант COMPILE, для этой конкретной пары классов словарей. И способ представления ссылки для выполнения при интерпретации (EXECUTE), который при наличии такового общего COMPILE _всегда_ универсально может быть реализован как, грубо говоря, HERE SWAP COMPILE, EXECUTE, т.е. откладывание в текущий словарь и тут же выполнение (т.е. именно так, как и сделано в данной либе, т.е. не в отдельном хранилище). Если делать в отдельном хранилище, но тогда уже методом COMPILE того отдельного словаря на пару с контекстным словарем, но механизма тройки текущих словарей у нас сейчас нет, есть только двойка - контекст-стек и current. Т.е. если делать в отдельном хранилище, то это много чего за собой тянет, если делать это "по-честному".

В so-xt.f сделана смесь этих подходов. При поиске в режиме 0 создается xt прямо в текущем хранилище и это xt возвращается, а при поиске в режиме 1 делается компиляция вызова прямо в текущее хранилище и возвращается xt слова NOOP. Т.е., аналоги COMPILE и EXECUTE присутствуют, но без выделения их в независимую часть.

Теперь понятно почему так?

Кстати, было бы очень заманчиво научиться сохранять
любой словарь форта в виде dll ;)

Сохранять в виде dll весь образ (со всеми словарями, и т.п.), а экспортировать только имена из заданного словаря? Это не трудно. Было бы трудней сохранить "только один словарь" ;)

Да, конечно обычно нужен весь образ, с видимым наружу заданным словарем (т.е. как в DCOM-сервере, легко и давно реализованном в SPF в виде exe, или как серверы Eserv, в которых заданный форт-словарь экспортируется как команды заданного TCP-протокола). А по отдельности у нас словари кроме FORTH не функциональны, и это не надо - форт-программы без встроенного форта ущербны. Т.е. задача откусывания конкретного словаря от "родни" не ставится, разве что из принципа "чтобы было" или как обобщенный вариант целевого компилятора (хотя ЦК так фактически и реализован, как генерация и экспорт автономного словаря, но постоянное программирование в стиле ЦК нам не требуется).

Я не говорил, что экспорт в виде dll - это трудно. Просто этого никто пока не сделал (не считая хаков), хотя вещь периодически нужная. В итоге те, кому это было особенно нужным (для встраивания форта в виде скриптового движка как dll) предпочли использовать FICL вместо встраивания SPF. А не озаботились реализации этой нетрудной фичи. Все остальные просто не связываются с такими задачами, где хорошо бы подошел spf4.[dll|so]. Вообще внутреняя структура словарей форта достаточно логично ложится в сложносоставной бинарник exe,dll,elf. Т.е. каждая секция exe может соответствовать словарю, и тогда форт получает много выгод типа флагов страничного доступа (защищенные системой (процессором) readonly-словари в частности), использования системного инструментария для исполнимых модулей, и т.п. То, что это не делается по умолчанию - тоже просто результат того, что я в своё время "недопроектировал" запись в exe в spf3. Наверное в spf5 или spf6 мы это таки починим :)

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Spf-dev mailing list
Spf-dev@...
https://lists.sourceforge.net/lists/listinfo/spf-dev

Ruvim Pinka

Re: word, vocabulary, namespace

Reply Threaded

Привет!

2008/8/4 Andrey Cherezov <andrey@...>

Это проблема существует в классическом форте на очень глубоком уровне.
Например, фраза ALSO ABC ... PREVIOUS небезопасна в принципе, т.к. в словаре ABC может быть слово PREVIOUS со совсем другим значением (или оно там может как раз быть создано). Это одно из обстоятельств, породивших forthml ;) Т.к. фараза abc <also> ... </also> безопасна всегда.

Да, в форте очень глубоко засела философская идея отрицания необходимости жесткого набора ключевых слов. Твоё безопасное <also> - это ключевое слово. Это просто не форт-стиль.

Дык, и меня напрягают ключевые слова ;) Но <also> — это не ключевое слово. А безопасно оно потому, что ALSO и PREVIOUS в нем (точнее, его постфиксный аналог PUSH-SCOPE и пара к нему DROP-SCOPE) связаны ранне:

<rule match="f:also">
`wordlist GetAttribute T-PLAIN
<m> PUSH-SCOPE <yield/> DROP-SCOPE </m>
</rule>

Во время трансляции элемента f:also неважно, какое значение имеют PUSH-SCOPE или DROP-SCOPE (т.е. типа PREVIOUS) и есть ли они вообще. Даже если внутри <also> ... </also> дать новое определение для f:also, все-равно все четко отработает (неизменно отработает до конца уже запущенное also).
А ключевая в xml-документе разве что левая угловая скобка ;)

А в форте принимаешь свободу вместе с её недостатками. Указанная тобой проблема чаще всего всплывает в целевых компиляторах. Там это решается удержанием на вершине стека словарей инструментального словаря,

Это решается таким путем, пока в целевой системе только один словарь. А когда их несколько, то становится сложней. А через forthml все разом красиво решается ;)

Еще, указанной мной проблема обостряется при отображении разных внешних пространств имен, типа тех же dll/so или файлов (наличие какого-нибудь файлика с именем ALSO на чужом компе трудней контролировать, чем слова в своих исходниках).

ALSO SO NEW: sqlite3.dll

А что если обойтись совсем без "NEW:", а создавать обертку при первом упоминании, как это делается для функций?

ALSO SO sqlite3.dll

(если сделать SO спец-словарем "все dll", то он будет просматриваться при компиляции каждого слова, когда включен в контекст, а оно и при однократном-то применения затянется на полчаса)

Не, словарь SO в контексте только до исполнения слова "sqlite3.dll", которое является словарем и заменит "SO" в контексте.

Если отображения на внешнии словари прозрачно, то и само это отображение можно явно не создавать. Это применяется для внешних функций, почему бы не применять и для самих внешних библиотек.

Или у меня уже глаз замылен?

Эх, непонятно я выражаюсь. Погоди, кодом поясню :)

[...]

Вообще внутреняя структура словарей форта достаточно логично ложится в сложносоставной бинарник exe,dll,elf. Т.е. каждая секция exe может соответствовать словарю, и тогда форт получает много выгод типа флагов страничного доступа (защищенные системой (процессором) readonly-словари в частности), использования системного инструментария для исполнимых модулей, и т.п.

Лучше сказать — по секции на хранилище. Т.к. слова из разных словарей (списков) переплетаются, ведь у нативных словарей нет своей непрерывной области памяти.

То, что это не делается по умолчанию - тоже просто результат того, что я в своё время "недопроектировал" запись в exe в spf3. Наверное в spf5 или spf6 мы это таки починим :)

Да, это нужно :)
Особенно мне нравится идея вынести в отдельную секцию обертки к dll/so (и автоматические, и ручные).

--
Ruvim

Andrey Cherezov

Re: word, vocabulary, namespace

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Добрый день, Ruvim Pinka!

Ваше сообщение от 04.08.2008 21:22:

Дык, и меня напрягают ключевые слова ;) Но <also> — это не ключевое слово. А безопасно оно потому, что ALSO и PREVIOUS в нем (точнее, его постфиксный аналог PUSH-SCOPE и пара к нему DROP-SCOPE) связаны ранне:

<rule match="f:also">
`wordlist GetAttribute T-PLAIN
<m> PUSH-SCOPE <yield/> DROP-SCOPE </m>
</rule>

Ранее связывание для синтаксиса - это и есть определение ключевых слов.

А в форте принимаешь свободу вместе с её недостатками. Указанная тобой проблема чаще всего всплывает в целевых компиляторах. Там это решается удержанием на вершине стека словарей инструментального словаря,

Это решается таким путем, пока в целевой системе только один словарь. А когда их несколько, то становится сложней.

DOS-версии моих ЦК поддерживали несколько целевых словарей. В 3.0 ЦК специально в разы упрощен, чему и новая модель словарей 94 способствовала.

А через forthml все разом красиво решается ;)

Forthml напоминает xslt - тоже очень правильно спроектирован, но совершенно не прельщает перспектива столь многословно выражаться, да к тому же носить с собой xml-парсеры. Только по крайней нужде, в спец.областях, или для тренировки пальцев... Или, как Кнут (кажется) в отношении самого форта говорил - для маш.генерации в него.

Еще, указанной мной проблема обостряется при отображении разных внешних пространств имен, типа тех же dll/so или файлов (наличие какого-нибудь файлика с именем ALSO на чужом компе трудней контролировать, чем слова в своих исходниках).

Пересечения с ALSO/PREVIOUS в "отчуждаемой" программе можно обезопасить конструкцией в стиле ( addr u ) EVALUATE-IN-CONTEXT, т.е. подготовкой/убиранием контекста вне текста. Если самого FORTH-WORDLIST в контексте нет, то нет и проблемы. В общем, также как с TCP-протокольными словарями.

Но мы о наших инструментальных словарях наверное говорим, а не о пользовательских спец.лексиконах. Т.е. как раз о своих полностью контролируемых исходниках, где мы можем избежать пересечения namespaces любым способом.

(если сделать SO спец-словарем "все dll", то он будет просматриваться при компиляции каждого слова, когда включен в контекст, а оно и при однократном-то применения затянется на полчаса)

Не, словарь SO в контексте только до исполнения слова "sqlite3.dll", которое является словарем и заменит "SO" в контексте.

Чтобы выполнить слово sqlite3.dll, его надо сначала найти. Если оно ищется не по косвенным признакам (именам функции), а явно по имени, то чем это отличается от того, что реализовано? Ты хочешь от слова "NEW:" избавиться?

Если отображения на внешнии словари прозрачно, то и само это отображение можно явно не создавать. Это применяется для внешних функций, почему бы не применять и для самих внешних библиотек.

Это отображение декларирует добавление пространства имен. "Монтирование". Т.е. узлами дерева мы управляем вручную. Иначе (при наличии "драйверов" для любых типов пространств имен) у нас сразу весь мир рекурсивно включится в дерево, хотим мы того или нет.

Эх, непонятно я выражаюсь. Погоди, кодом поясню :)

Можно примером синтаксиса. Только не на forthml.

Лучше сказать — по секции на хранилище. Т.к. слова из разных словарей (списков) переплетаются, ведь у нативных словарей нет своей непрерывной области памяти.

Да, но возможность такая есть - временные словари. Ничто не мешает при генерации многосекционного exe все словари создавать "временными". Т.к. переплетаются они они у нас сейчас исключительно для того, чтобы попасть в одну секцию.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Spf-dev mailing list
Spf-dev@...
https://lists.sourceforge.net/lists/listinfo/spf-dev

Ruvim Pinka

Re: word, vocabulary, namespace

Reply Threaded

Привет!

On 8/4/08, Andrey Cherezov <andrey@...> wrote:

> Ты хочешь от слова "NEW:" избавиться?

Да, я именно с этого и начал! Цитирую: А что если обойтись совсем без
"NEW:" [...]? (и рядом там привел пример).

>> Эх, непонятно я выражаюсь. Погоди, кодом поясню :)
> Можно примером синтаксиса. Только не на forthml.

ALSO DLL kernel32.dll
Ok

Рабочий пример: ~pinka/spf/ffi/spf4-ffi-sugar.test.f (все включено)

Реализация самого sugar на ForthML, уж не обессудь, — на нем такие
игры записываются короче и решаются быстрей! :)

Отличия от твоего ns.f следующие

1. При листании словаря (WORDS, NLIST) видны только уже закэшированные
объекты (библиотеки, или функции), которые не использовались — не
видны (т.к. у нас пока нет простых способов листать dll). Кэширование
честно идет в отдельное хранилище, чтобы не портить пользовательскую
область.

2. Словарь kernel32.dll находится в словаре DLL (виртуально он там
находится всегда, но виден только после использования).

3. В словаре SO виртуально находятся тоже все DLL, но функции
вызываются по си-форме. Т.е., это просто разные "view" файловой
системы.

4. Если нужен алиас в другом словаре, то

: libxml2 SO::libxml2.dll ;

и далее ALSO libxml2 ... PREVIOUS

Как вариант, : libxml2 WIN32? IF SO::libxml2.dll EXIT THEN POSIX? IF
SO::libxml2.so EXIT THEN S" libxml2 unknown on the platform" STHROW ;

5. Словари-обертки являются нативными форт-словарями, имеют обычный
список слов (поэтому они листаются без проблем). Но, кроме того, они
расширенны атрибутами. Атрибуты определяют дополнительные свойства
словаря (в частности, процедуру "SWL") и реализованны в виде списка
слов. Доступ к атрибутам идет поименно, через позднее связывание.
Классы и наследование пока не использованны.

Слово SEARCH-WORDLIST неудобно по своей сигнатуре. FIND-WORDLIST
удобней, и, похоже, лучше в форт-системе идти от него, а SWL держать
только для совместимости.

Вообще, кажется, что классы в ns.f как-то несогласованно реализованны:
для словарей-объектов CLASS@ используется именно как класс, а для
словарей классов — CLASS@ означает родителя. Получается, что
словарь-класс не может выступать объектом. Но, он может появится в
контексте и будет интерпретирован как объект. Противоречие, однако.

--
Ruvim
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Spf-dev mailing list
Spf-dev@...
https://lists.sourceforge.net/lists/listinfo/spf-dev

Ruvim Pinka

Re: word, vocabulary, namespace

Reply Threaded

In reply to this post by Andrey Cherezov

On 8/4/08, Andrey Cherezov <andrey@...> wrote:

>> А через forthml все разом красиво решается ;)
> Forthml напоминает xslt - тоже очень правильно спроектирован,

спасибо на добром слове! :)

> но совершенно не прельщает перспектива столь многословно выражаться, да к
> тому же носить с собой xml-парсеры.

xml-парсер с собой носить не надо: в каждой ОС, где работает SPF4, эти
парсеры уже есть. А в Eserv/3 даже и носимый с собой xml-парсер есть!
;)

[...]
> Пересечения с ALSO/PREVIOUS в "отчуждаемой" программе можно обезопасить
> конструкцией в стиле ( addr u ) EVALUATE-IN-CONTEXT,

Хм, а ведь тоже вариант. Вместо `./a/b/c.txt FILE-CONTENT
записать S" . a b c.txt" NFS-FILE-CONTENT EVALUATE-IN-CONTEXT

[...]
> Ничто не мешает при
> генерации многосекционного exe все словари создавать "временными".

(то бишь, каждый словарь в своем собственном хранилище)

> Т.к. переплетаются они они у нас сейчас исключительно для того, чтобы попасть
> в одну секцию.

Такой вариант тоже доступен, конечно. Правда, вряд ли оправдано иметь
сотню сегментов в elf-файле. А сотню списов слов слов — легко.

--
Ruvim
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Spf-dev mailing list
Spf-dev@...
https://lists.sourceforge.net/lists/listinfo/spf-dev

Andrey Cherezov

Re: word, vocabulary, namespace

Reply Threaded

In reply to this post by Ruvim Pinka

Добрый день, Ruvim Pinka!

Ваше сообщение от 05.08.2008 3:36:
> Да, я именно с этого и начал! Цитирую: А что если обойтись совсем без
> "NEW:" [...]? (и рядом там привел пример).
>
А-а! :-)
> ALSO DLL kernel32.dll
> Ok
>
> Рабочий пример: ~pinka/spf/ffi/spf4-ffi-sugar.test.f (все включено)
>
Нет, оказалось не все. Одного файла не хватает:
Exception #2 at: http://forth.org.ru/~pinka/model/trans/obey.f.xml:0:0:
^ -2003 WORD OR FILE NOT FOUND
Не нашел ни на cvs, ни по указанному url'у.
> Реализация самого sugar на ForthML, уж не обессудь, — на нем такие
> игры записываются короче и решаются быстрей! :)
>
Понятно, к ForthML-программам обертка тоже на ForthML.
Ну, хорошо, есть есть еще один повод вникнуть в ForthML :)
> 1. При листании словаря (WORDS, NLIST) видны только уже закэшированные
> объекты (библиотеки, или функции), которые не использовались — не
> видны (т.к. у нас пока нет простых способов листать dll). Кэширование
> честно идет в отдельное хранилище, чтобы не портить пользовательскую
> область.
>
Со словом "портить" не согласен. Ничего там не портится моими либами, а
просто
используется. Можно освобождать маркером, если нужно. Или делать текущим
временный словарь - TEMP-WORDLIST SET-CURRENT - тогда глобальный HERE
тоже не "портится". Но на самом-то деле режим интерпретации при подключении
внешних dll ни разу не потребовался, а при компиляции нам нужна как раз
"порча" пользовательской области. Если в твоем примере этой порчи нет, то
как же сохранять по SAVE использующие dll программы?
> 2. Словарь kernel32.dll находится в словаре DLL (виртуально он там
> находится всегда, но виден только после использования).
>
> 3. В словаре SO виртуально находятся тоже все DLL, но функции
> вызываются по си-форме. Т.е., это просто разные "view" файловой
> системы.
>
Да. Логически это то же самое что и классы DLL/SO. Теперь я понял смысл
записи без NEW:. Действительно, если при поиске в контекстном словаре-классе
(в смысле класса, как он понимается в ns.f) любое ненайденное слово считать
именем нового объекта этого класса, то это упрощает запись. Только пока не
пойму (без возможности скомпилировать твой пример), не исключает ли это
из поиска все остальные контекстные словари. Для DLL/SO понятно как не
исключать - если нужной dll нет, то не создавать объект, возвратить "не
найдено"
что разрешит дальнейший поиск. Но тогда становится непонятным, как создавать
именованные объекты других классов, у которых нет внешнего отражения?
И как создавать привязку dll (или каталогов файлов, узлов xml и т.п. из
наших namespaces),
которых нет на момент компиляции?
> 4. Если нужен алиас в другом словаре, то
>
> : libxml2 SO::libxml2.dll ;
>
> и далее ALSO libxml2 ... PREVIOUS
>
> Как вариант, : libxml2 WIN32? IF SO::libxml2.dll EXIT THEN POSIX? IF
> SO::libxml2.so EXIT THEN S" libxml2 unknown on the platform" STHROW ;
>
Да, это интересное полезное следствие. Хотя мне нынешний вариант
ALSO SO NEW: libxml2.dll
ALSO SO NEW: /usr/lib/libxml2.so.2
(который тоже оказался прямым незапланированным следствием подхода)
нравится как раз тем, что можно без IF/[IF] обходиться - поиск сам
"бесплатно"
все решает. При добавлении платформ или альтернативных совместимых
библиотек (как openssl/gnutls) просто добавляются декларирующие строки,
а не выбирающий код.
> 5. Словари-обертки являются нативными форт-словарями, имеют обычный
> список слов (поэтому они листаются без проблем).
Это кэширование и временные словари - все-таки частный случай. Что нам
толку от листания, если оно на самом деле листает не реальный список, а его
подмножество? Разве что для избавления от WINAPLINK. Кстати, да,
с ходу непонятно как сработает SAVE в твоем варианте.
> Но, кроме того, они
> расширенны атрибутами. Атрибуты определяют дополнительные свойства
> словаря (в частности, процедуру "SWL") и реализованны в виде списка
> слов.
Т.е. атрибуты словаря реализованы в виде словаря? Это в точности то, для
чего предназначалось (и предназначено сейчас) наше древнее слово CLASS@.
> Доступ к атрибутам идет поименно, через позднее связывание.
> Классы и наследование пока не использованны.
>
Т.е. классы у тебя на самом деле реализованы (неявно) классическим для SPF
способом, но без наследования, т.к. оно для этого частного случая и не
нужно.
> Слово SEARCH-WORDLIST неудобно по своей сигнатуре. FIND-WORDLIST
> удобней, и, похоже, лучше в форт-системе идти от него, а SWL держать
> только для совместимости.
>
Да, с этим согласен. Я вот тоже мучаюсь с тем что реализовал CP@ (получение
значения property объекта в IDispatch) в традиционном виде ( propa propu
oid -- ... )
Правда мне неудобна левая часть "строка объект" (несколько действий над
объектом в этом случае требуют R@ или локальных переменных или DUP...ROT
вместо простого DUP S" другое действие"), а тебе правая:
FIND-WORDLIST ( c-addr u wid -- xt true | c-addr u false )
SEARCH-WORDLIST ( c-addr u wid -- 0 | xt 1 | xt -1 )
Т.е. наверное все-таки нужны все варианты нотации, просто определить их
через общий базовый вариант.
> Вообще, кажется, что классы в ns.f как-то несогласованно реализованны:
> для словарей-объектов CLASS@ используется именно как класс, а для
> словарей классов — CLASS@ означает родителя. Получается, что
> словарь-класс не может выступать объектом. Но, он может появится в
> контексте и будет интерпретирован как объект. Противоречие, однако.
>
На родителя указывает PAR@. Ссылка в CLASS@ на родителя означает частный
случай "родитель является классом". Это словарь FORTH, т.к. в нем есть
все методы
класса встроенных словарей.
И словари-классы могут выступать объектом. Они через объектную нотацию и
создаются - через тот же NEW:, завернутый внутрь <<:. Т.е. классы DL,
DLL, SO
и т.п. создаются также как их дети. Но корневой [мета]класс один -
FORTH, у него
есть все права простого объекта кроме возможности создать еще один.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Spf-dev mailing list
Spf-dev@...
https://lists.sourceforge.net/lists/listinfo/spf-dev

Ruvim Pinka

Re: word, vocabulary, namespace