Quantcast

word, vocabulary, namespace

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

word, vocabulary, namespace

Ruvim Pinka
Привет!

2008/8/3 Andrey Cherezov <[hidden email]>

В случае "синтаксиса" можно указать: my_cool_function(3,2)
Щас буду кусаться :-[]

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

Цитирую (по Message-ID: <[hidden email]>):
> можно вызывать нечто по имени или по номеру, или еще как (допустим, просто целой строкой нескольких команд на чуждом языке, передаваемую исполнителю через единую точку входа
 
В случае синтаксиса факт указания числа параметров поддается
автоматической проверки, 
 
А факт указания чего-то там в скобках делу проверки не поможет,

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


 [...]
Не принимай близко к сердцу число параметров, мы ведь обычно не используем
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

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

--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Andrey Cherezov
In reply to this post by Ruvim Pinka
Добрый день, 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Ruvim Pinka
Привет!

2008/8/4 Andrey Cherezov <[hidden email]> 
Это проблема существует в классическом форте на очень глубоком уровне.
Например, фраза 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

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Andrey Cherezov
Добрый день, 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Ruvim Pinka
Привет!

On 8/4/08, Andrey Cherezov <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Ruvim Pinka
In reply to this post by Andrey Cherezov
On 8/4/08, Andrey Cherezov <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Andrey Cherezov
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Ruvim Pinka
Привет!

2008/8/5 Andrey Cherezov <[hidden email]>
 
> Рабочий пример: ~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

О, спасибо, исправил!


[...]
Понятно, к ForthML-программам обертка тоже на ForthML.
Ну, хорошо, есть есть еще один повод вникнуть в ForthML :)

Накинь файлик spf4-ffi-sugar.f.xml на ~pinka/fml/fml2ans-ext.cmd — оно выдаст текст, приближенный к классическому форту. Причем, всего-то процентов на 5 меньше по размеру (учитывая, что некоторые элементы не переведены на классик-форт, т.к. длинно и трудно получается).
Тем не менее, полученный текст поможет понять значения xml-элементов в исходном тексте.


> честно идет в отдельное хранилище, чтобы не портить пользовательскую
> область.
Со словом "портить" не согласен. Ничего там не портится моими либами, а
просто используется.

Это расширение системы, и оно не знает, с какой целью пользователь вызывал SEARCH-WORDLIST и не должно полагать, что может безопасно что-то записать в текущее хранилище. Пользовательский контекст ему неведом ;)



[...]
Но тогда становится непонятным, как создавать
именованные объекты других классов, у которых нет внешнего отражения?

Не знаю пока, нужен пример или востребованная задача.
 
 
И как создавать привязку dll (или каталогов файлов, узлов xml и т.п. из
наших namespaces), которых нет на момент компиляции?

Делать привязку к dll/so, которых нет на момент компиляции, таким способом невозможно вообще (т.е., через so-xt.f тоже невзможно). Для них остается старый способ через явное предварительное объявление.



[...]
Хотя мне нынешний вариант
ALSO SO NEW: libxml2.dll
ALSO SO NEW: /usr/lib/libxml2.so.2
(который тоже оказался прямым незапланированным следствием подхода)
нравится как раз тем, что можно без IF/[IF] обходиться - поиск сам
"бесплатно" все решает.

Небольшии минусы этого решения:

1. Надо знать, загруженна уже эта либа, или нет. Если загружена, делать:
   ALSO libxml2.dll
а если не загруженна, то делать:
  ALSO NEW: libxml2.dll
(конечно, можно всегда делать "NEW:", но это некий оверхед и предупреждения).

2. Надо перечислять все платформы (и пути?), даже когда нет зависимости от платформы. Т.е., каждый раз вместо одного ALSO делать два (или три). При добавлении совместимой платформы надо править все такие места.

При добавлении платформ или альтернативных совместимых
библиотек (как openssl/gnutls) просто добавляются декларирующие строки,
а не выбирающий код.

По изящности это похоже на сопоставление с образцом :)  По идее, аналогичное решение (без IF-ов) можно сделать и на другом уровне, чтобы не приходилось повторять по пять раз ALSO и PREVIOUS каждый раз.


[...]
Это кэширование и временные словари - все-таки частный случай. Что нам
толку от листания, если оно на самом деле листает не реальный список, а его
подмножество?

Да, частный случай. Просто, это лучше, чем совсем ничего не листать.

 
Кстати, да, с ходу непонятно как сработает SAVE в твоем варианте.

В идеале хотелось бы сохранять в отдельный сегмент, как мы уже упоминали. Пока же, под хранилище для оберток отведено место фиксированного размера из базового хранилища по ALLOT. Но сохранение еще не доработано, т.к. еще не сделана очистка точек входа, см. core.f
Т.е., еще на уровне прототипа.

 
Т.е. атрибуты словаря реализованы в виде словаря? Это в точности то, для
чего предназначалось (и предназначено сейчас) наше древнее слово CLASS@.

Да. И у словаря, который содержит атрибуты, тоже могут быть атрибуты! Моща ;)
Это похоже на дуальность элементы-атрибуты в xml, но тут эта дуальность продолжается и для атрибутов (в xml она продолжается только для элементов).

 
> Доступ к атрибутам идет поименно, через позднее связывание.
> Классы и наследование пока не использованны.
Т.е. классы у тебя на самом деле реализованы (неявно) классическим для SPF
способом, но без наследования, т.к. оно для этого частного случая и не
нужно.

Верно. Список атрибутов знает словарь, к которому он привязан (возможно, для этого стоит использовать PAR@),  и атрибуты эти привязанны к словарю как к экземпляру, а не к классу (всем экземплярам). Т.е., у каждого экземпляра свои атрибуты (правда, через наследование можно иметь и общии). Поэтому, при вызове методов-атрибутов им не надо передавать obj.

 
> Слово SEARCH-WORDLIST неудобно по своей сигнатуре. FIND-WORDLIST

Да, с этим согласен. Я вот тоже мучаюсь с тем что реализовал CP@ (получение
значения property объекта в IDispatch) в традиционном виде ( propa propu
oid -- ... )
Я бы сделал слово : CP@- ROT CP@ ;  (тут дефис в конце имени означает, что "объект" с другого конца списка параметров). И, тогда лучше изменить корень этих имен, чтобы обойтись без "@" в имени.


[...]
> для словарей-объектов CLASS@ используется именно как класс, а для
> словарей классов — CLASS@ означает родителя. Получается, что
> словарь-класс не может выступать  объектом. Но, он может появится в
> контексте и будет интерпретирован как объект. Противоречие, однако.
>
На родителя указывает PAR@.

Да, я тоже считал, что через PAR@ должно идти. Но, в слове SEARCH-WORDLIST-R оно идет к "родителям" всегода через CLASS@
Цитирую:
  CLASS@ DUP 0= IF DROP FORTH-WORDLIST THEN RECURSE \ ищем выше по линии наследования
Конец цитаты. Почему в этом месте не PAR@ ?

Еще, если это действительно классы, непонятно, почему INVOKE не передает методам объект на вершине (или в переменной this). Вроде, в некоторых случаях роль this выполняло CONTEXT @, но это побочными эффектами опасно.


--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Andrey Cherezov
In reply to this post by Andrey Cherezov
Моё сообщение от 05.08.2008 16:20:
> Нет, оказалось не все. Одного файла не хватает:
> Exception #2 at: http://forth.org.ru/~pinka/model/trans/obey.f.xml:0:0:
> ^ -2003 WORD OR FILE NOT FOUND
> Не нашел ни на cvs, ни по указанному url'у.
>  
Вижу коммит, взял.
> Если в твоем примере этой порчи нет, то
> как же сохранять по SAVE использующие dll программы?
>  
Скомпилированное ("попорченное") твоей либой сохраняется, но на другой
машине
не работает. Т.е. надо туда закрутить-таки линкование в WINAPLINK, по
которому
SAVE обнуляет привязки.

> именем нового объекта этого класса, то это упрощает запись. Только пока не
> пойму (без возможности скомпилировать твой пример), не исключает ли это
> из поиска все остальные контекстные словари. Для DLL/SO понятно как не
> исключать - если нужной dll нет, то не создавать объект, возвратить "не
> найдено"
> что разрешит дальнейший поиск. Но тогда становится непонятным, как создавать
> именованные объекты других классов, у которых нет внешнего отражения?
> И как создавать привязку dll (или каталогов файлов, узлов xml и т.п. из
> наших namespaces),
> которых нет на момент компиляции?
>  
Да, эта догадка тоже подтвердилась, объявить несуществующую dll нельзя:
ALSO DLL zzz.dll
              ^ -2003 WORD OR FILE NOT FOUND
Т.е. не сработает и синтаксис автовыбора dll/so, подобный упомянутому:
> ALSO SO NEW: libxml2.dll
> ALSO SO NEW: /usr/lib/libxml2.so.2
В остальном все хорошо, можно считать еще одним правильным способом
привязки внешних dll/so. Хотя в нагрузку это тянет весь ForthML, сумма
раз в 30 толще. При необходимости эту идею (без NEW:) можно переписать
на голом SPF, получится еще компактнее чем ns.f+dll-xt.f за счет
специализации
(выкидывания классов).


-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Andrey Cherezov
In reply to this post by Ruvim Pinka
Добрый день, Ruvim Pinka!

Ваше сообщение от 05.08.2008 4:10:
xml-парсер с собой носить не надо: в каждой ОС, где работает SPF4, эти
парсеры уже есть. А в Eserv/3 даже и носимый с собой xml-парсер есть!
;)
  
Он потому и сделан носимым, что за несколько лет использования MSXML в Eserv/3
убедился, что ему доверять нельзя. Т.е. оно долго работало, а потом вдруг очередной
апдейт винды поломал всем веб-интерфейсы Eserv'ов :) А потом после обхода новой
проблемы - еще раз. Пришлось срочно переводить на носимый.
Т.к. переплетаются они они у нас сейчас исключительно для того, чтобы попасть
в одну секцию.
    
Такой вариант тоже доступен, конечно. Правда, вряд ли оправдано иметь
сотню сегментов в elf-файле. А сотню списов слов слов — легко.
  
Да, но у нас есть выбор, какие словари делать отдельными, какие переплетенными,
т.к. мы сами их создаем. При записи 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Andrey Cherezov
In reply to this post by Ruvim Pinka
Добрый день, Ruvim Pinka!

Ваше сообщение от 05.08.2008 4:10:
> Хм, а ведь тоже вариант. Вместо `./a/b/c.txt FILE-CONTENT
> записать  S" . a b c.txt" NFS-FILE-CONTENT EVALUATE-IN-CONTEXT
>  
Нет, в этом-то случае лучше просто S" a/b/c.txt" FILE
(из str5.f), это как раз тот случай про немецких лошадей.


-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Andrey Cherezov
In reply to this post by Ruvim Pinka
Добрый день, Ruvim Pinka!

Ваше сообщение от 05.08.2008 19:39:
Но тогда становится непонятным, как создавать
именованные объекты других классов, у которых нет внешнего отражения?

Не знаю пока, нужен пример или востребованная задача.
Кроме декларирования линуксовых so под виндой, которое используется теперь
во всех двухОСных либах, можно было бы таким образом реализовать "исполнителей"
xml в стиле либы ~ac/lib/lin/xml/expat.f - их ведь не обязательно по существующему
образцу генерировать, а можно и "наперед", как в исполнителе протокола XMPP.
  
И как создавать привязку dll (или каталогов файлов, узлов xml и т.п. из
наших namespaces), которых нет на момент компиляции?

Делать привязку к dll/so, которых нет на момент компиляции, таким способом невозможно вообще (т.е., через so-xt.f тоже невзможно). Для них остается старый способ через явное предварительное объявление.
Не привязку, а декларацию способов привязки. Там как раз старый способ не работает,
т.к. WINAPI: тоже требовал наличия dll, приходилось делать ' WINAPI: CATCH.
А теперь работает.
1. Надо знать, загруженна уже эта либа, или нет. Если загружена, делать:
   ALSO libxml2.dll
а если не загруженна, то делать:
  ALSO NEW: libxml2.dll
(конечно, можно всегда делать "NEW:", но это некий оверхед и предупреждения).
Надо делать REQUIRE, и всё.
2. Надо перечислять все платформы (и пути?), даже когда нет зависимости от платформы. Т.е., каждый раз вместо одного ALSO делать два (или три). При добавлении совместимой платформы надо править все такие места.
Почему? Надо вообще просто сделать один раз либу с обертками и забыть о том, как оно там внутри.
Или, если один разработчик хочет расширить  обертки другого разработчика, то можно и ALSO,
но это не такая частая задача, чтобы изнывать от необходимости записи лишней строки.
Ты в одной строке ForthML больше лишнего текста пишешь, чем написал бы при дописывании всех моих оберток.
По изящности это похоже на сопоставление с образцом :)  По идее, аналогичное решение (без IF-ов) можно сделать и на другом уровне, чтобы не приходилось повторять по пять раз ALSO и PREVIOUS каждый раз.
Это будет специализированное узкое решение. А описанный способ работает бесплатно (я сам его не сразу увидел, даже не в первый год использования, вначале тупо использовал [IF] :) и всеобще, т.к. использует встроенные механизмы форта, а не какие-то новые специальные.

В твоем варианте ffi исключается создание одноименного словаря, но контролировать наличие dll в контексте все равно нужно.
Т.к. не запрещается возможность сделать ALSO DLL USER32.DLL несколько раз и получить несколько user32.dll в контексте.
Это кэширование и временные словари - все-таки частный случай. Что нам
толку от листания, если оно на самом деле листает не реальный список, а его
подмножество?

Да, частный случай. Просто, это лучше, чем совсем ничего не листать.
Не лучше, т.к. может создать ложные предположения, что так реализованы все namespaces - "что-нибудь листается". А в случае "ничегонелистания" мы знаем, что листание есть только в случае, если оно полноценное, а в противном случае ошибка либо пусто, это проще проверять.
Да, я тоже считал, что через PAR@ должно идти. Но, в слове SEARCH-WORDLIST-R оно идет к "родителям" всегода через CLASS@
Цитирую:
  CLASS@ DUP 0= IF DROP FORTH-WORDLIST THEN RECURSE \ ищем выше по линии наследования
Конец цитаты. Почему в этом месте не PAR@ ?
Так сходу и не вспомню. Линия наследования может не совпадать с линией порождения, как в винде GetParent и GetAncestor имеют разный смысл. Модель классов подгонялась для работы с многочисленными типами namespaces для того, чтобы сделать универсальные "итераторы всего", что и было продемонстрировано в том IMAP-сервере, который не только письма выдавал, но и все словари форта - собственные и внешние xml/БД/файловая_система/ит.п. единообразным способом в едином дереве. Т.е., надо думать, это не баг, иначе бы не работало (если этот кусок кода вообще используется :). Надо будет собраться с мыслями и описать эту 25ю реализацию ООП в SPF отдельной статьёй :-) А может и не надо, пусть будет у каждого своя (и так есть у каждого по нескольку своих :). Я ns.f и не анонсировал как ООП, т.к. главное там - использующие её либы, они документированы независимо от ООП-модели.
Еще, если это действительно классы, непонятно, почему INVOKE не передает методам объект на вершине (или в переменной this). Вроде, в некоторых случаях роль this выполняло CONTEXT @, но это побочными эффектами опасно.
Да, контекст очень просится быть просто объектным стеком. Местами это используется. Для полной складности и красивости там много чего не хватает, но задача была конкретная, и на вылизывание у меня в той итерации времени не хватило. А между итерациями у меня иной раз и больше 10 лет проходит, как в том случае с COM :)

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Ruvim Pinka
Привет!

On 8/5/08, Andrey Cherezov <[hidden email]> wrote:
[...]
>>     Но тогда становится непонятным, как создавать
>>     именованные объекты других классов, у которых нет внешнего отражения?
>> Не знаю пока, нужен пример или востребованная задача.
> Кроме декларирования линуксовых so под виндой, которое используется теперь
> во всех двухОСных либах, можно было бы таким образом реализовать
> "исполнителей" xml в стиле либы ~ac/lib/lin/xml/expat.f

Прихожу к выводу, что если нет внешнего отражения, то именованный
объект надо создавать постфиксно, типа   `ИМЯ СОЗДАТЬ-ОБЪЕКТ
Или, использовать "разметку" в виде слова-перфикса, заглядывающего
вперед, выбирающего имя и создающего объект (как это слово "NEW:").
Такое слово-префикс можно прицепить и в моей реализации ffi-sugar, но
тогда его не стоило и затевать ;)

В некоторых случаях обертка к объекту может быть авто-создана по
формату имени (например, если имя заканчивается на .dll то в словаре
DLL оно находимо, даже если файла такого нету). Но, это немножко
черевато проблемой "совсем другое одноименное слово".


[...]
> Там как раз старый способ не работает,
> т.к. WINAPI: тоже требовал наличия dll, приходилось делать ' WINAPI: CATCH.
> А теперь работает

В тех случаях, когда делали ' WINAPI: CATCH (нет библиотеки и нет
функции, а обертку надо создать на будущее), сейчас фунцию тоже надо
создавать каким-то префиксом, типа ALSO SO NEW: libxml2.dll NEW:
xmlRecoverFile
Или я что-то недопонял.

Принципиально не CATCH (легко сделать и без него), а само
слово-префикс, маскирующее имя объекта (чтобы оно не попало
транслятору как имя слова).


[...]
>>Т.е., каждый раз вместо одного ALSO делать два (или три).
>> При добавлении совместимой платформы надо править все
>> такие места.
> Почему? Надо вообще просто сделать один раз либу с обертками и забыть о
> том, как оно там внутри.

Например, libxml2 очень большая, всю разом не обернешь (да и ненадо).
Поэтому, на разные ее части могут быть разные независимые файлы с
обертками. Поэтому, никакая конкретная либа с обертками не может
полагать, что слово libxml2.dll уже есть, или что его обязательно
нету. Красивого разрешения этой ситуации еще нет.


[...]
> В твоем варианте ffi исключается создание одноименного словаря, но
> контролировать наличие dll в контексте все равно нужно.
> Т.к. не запрещается возможность сделать ALSO DLL USER32.DLL несколько
> раз и получить несколько user32.dll в контексте.

Да. В этом эти спец-словари ничуть не отличаются от обычных словарей.


[...]
>> Просто, это лучше, чем совсем ничего не листать.
> Не лучше, т.к. может создать ложные предположения, что так реализованы
> все namespaces - "что-нибудь листается".

И что с того?  Ну, будет такое предположение у кого-то, а вред какой?

А удобство в рефлексии: видно, какие dll подключены, какие их них
функции запользованны.


>  А в случае "ничегонелистания"
> мы знаем, что листание есть только в случае, если оно полноценное, а в
> противном случае ошибка либо пусто, это проще проверять.

Пример из so-xt.f
  ALSO SO NEW: libxml2.dll
  S" text.xml" DROP 1 xmlRecoverFile .

Если после этого дать WORDS, вываливается AV. Нехорошо, имхо.


--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

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

Ваше сообщение от 05.08.2008 23:48:
В тех случаях, когда делали ' WINAPI: CATCH (нет библиотеки и нет
функции, а обертку надо создать на будущее), сейчас фунцию тоже надо
создавать каким-то префиксом, типа ALSO SO NEW: libxml2.dll NEW:
xmlRecoverFile
Или я что-то недопонял.
  
Да, заставить WINAPI отказаться таким образом от требования наличия dll
не получится, можно лишь поймать ошибку, чтобы не прерывать компиляцию.
У меня это использовалось при компиляции под win95 NT-зависимого кода,
типа ' WINAPI: CATCH PdhOpenQuery PDH.DLL DROP, а также с RAS-звонилкой.

Новый способ позволяет декларировать отсутствующую dll без ошибок.
А искать функции в отсутствующей dll не позволяет. Ты все правильно понял.
Например, libxml2 очень большая, всю разом не обернешь (да и ненадо).
Поэтому, на разные ее части могут быть разные независимые файлы с
обертками. Поэтому, никакая конкретная либа с обертками не может
полагать, что слово libxml2.dll уже есть, или что его обязательно
нету. Красивого разрешения этой ситуации еще нет.
  
По-моему, раз не может ничего полагать, и раз никакие чужие обертки ей не
нужны, то может смело определять повторно ALSO SO NEW:, и ни к каким
сбоям это привести не должно. Даже если будут перечислены не все возможные
расположения/имена для всех возможных ОС/версий - просто под какой-то ОС
_эта либа_ не скомпилируется, только и всего. Тогда автор добавит строку, если
ему эта ОС нужна.
И что с того?  Ну, будет такое предположение у кого-то, а вред какой?
  
Вред, как я уже сказал, в том, что не узнаешь никак, полноценное это листание,
или кэш. Всемирный интернет или кэш локального браузера.
А удобство в рефлексии: видно, какие dll подключены, какие их них
функции запользованны.
  
Это по старинке видно через WINAPLINK, без которого с текущей версией SAVE
все равно не обойтись.
 А в случае "ничегонелистания"
мы знаем, что листание есть только в случае, если оно полноценное, а в
противном случае ошибка либо пусто, это проще проверять.
    

Пример из so-xt.f
  ALSO SO NEW: libxml2.dll
  S" text.xml" DROP 1 xmlRecoverFile .

Если после этого дать WORDS, вываливается AV. Нехорошо, имхо.
  
Вот я и говорю, ошибка :) Явный сбой - лучше, чем потворство ложным предположениям.
На самом деле старый WORDS ставится либой ns.f вне закона, т.к. виртуализация словаря (а
не импорт по частям с кэшированием в словари другого типа) далее предполагает использование
совместимых виртуальных итераторов (с собственной реализацией CAR, CDR для каждого
типа словаря), совместимых конструкторов (SHEADER и т.д.), а не только SEARCH-WORDLIST.
Ты наверное сталкивался там в коде с
: CAR ( wid -- item )
  ." SO exports enumeration isn't supported now." CR
  DROP 0
;
: SHEADER ( addr u -- )
  ." Can't insert " TYPE ."  into " GET-CURRENT VOC-NAME. ."  SharedObject ;)" CR
  5 THROW
;
Вот это должны использовать новые версии WORDS, новые версии ":" и т.д.
(примеры WORDS и конструкторов там тоже даны)

В этом смысле либа ns.f примерно на уровне твоих storage-расширений, которые
тоже с частью старого кода принципиально несовместимы, из-за чего приходится
рекомендовать порядок подключения либ.

Когда все наши новые эксперименты с новыми свойствами словарей утрясутся,
можно будет добавить необходимые точки подключения, поля словарей, предположения
о контекстах в ядро. Толще оно от этого не станет, а гибкость повысится, и хаки
совсем уйдут.


-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Ruvim Pinka
In reply to this post by Andrey Cherezov
Привет!
On 8/4/08, Andrey Cherezov <[hidden email]> wrote:
[...]
> для каждой пары разнородных ("физически") словарей должен быть свой
> способ откладывания ссылки (позднего связывания) из одного на другой,
> т.е. свой вариант COMPILE, для этой конкретной пары классов словарей.

По моему, достаточно уметь откладывать из разных других в форт-словарь
(точнее, в форт-определения). Т.е., достаточно N*1 отношений, вместо
N*N.

Т.к., COMPILE как "откладывание _исполнения_ заданного токена" имеет
смысл только в рамках некоторого (текущего) определения. А настолько
детальное создание определений мало где доступно, кроме форта. Т.е.,
для не-форт словарей такая операция не востребованна.
Например, при создании DLL сохраняется в необходимом формате весь
образ форт-системы разом, без разбиения на особые определения и, в
особенности, на особое откладывание исполнения токенов в эти
определения.

Если же говорить о представлении форт-словарей (и форт-определений) в
различной форме (например, различные формы откладываемого кода,
организации списков имен,  распределения аппаратных ресурсов,
размерности ячейки, и т.п.), то дело далеко не ограничивается
операцией COMPILE. Для таких целей хорошо подходит отдельный экземпляр
целиком форт-транслятора, настроенный на необходимую форму
представления всего, чего нужно. Именно такое решение я использовал
для создания "словарей" макетных форт-системы (32x и 64x), см. в
~pinka/samples/2007/fcomposition/
В обоих случаях в слова в "других" словарях откладывались родные слова из spf4.


> И способ представления ссылки для выполнения при интерпретации (EXECUTE),
> который при наличии такового общего COMPILE _всегда_ универсально может
> быть реализован как, грубо говоря, HERE SWAP COMPILE, EXECUTE, т.е.
> откладывание в текущий словарь и тут же выполнение

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

Выражение EXECUTE-* через COMPILE-*

: EXECUTE-FOREIGN ( i*x foreign-xt -- j*x )
  TMP-STORAGE PUSH-MOUNT
    CONCEIVE COMPILE-FOREIGN BIRTH ( xt )
  DROP-MOUNT EXECUTE
  \ потом тут еще освобождение памяти, если надо
;

Выражение COMPILE-* через EXECUTE-*

: COMPILE-FOREIGN ( foreing-xt -- )
  LIT, ['] EXECUTE-FOREIGN ( xt ) COMPILE
;

Практически же, требования к эффективности COMPILE-* (отложенному
исполнению) обычно выше, чем к эффективности EXECUTE-*
(непосредственному исполнению).


--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

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

Ваше сообщение от 06.08.2008 1:31:
> По моему, достаточно уметь откладывать из разных других в форт-словарь
> (точнее, в форт-определения). Т.е., достаточно N*1 отношений, вместо
> N*N.
>
> Т.к., COMPILE как "откладывание _исполнения_ заданного токена" имеет
> смысл только в рамках некоторого (текущего) определения. А настолько
> детальное создание определений мало где доступно, кроме форта. Т.е.,
> для не-форт словарей такая операция не востребованна.
>  
Я к тому, что было бы полезно или как минимум интересно уметь откладывать
код не в словари форта, а в базу данных или xml (например, хранить в таком
предкомпилированном виде plugin'ы типа твоего TrafC). Код в БД можно
обрабатывать статистически, код в xml можно удобно визуализировать в учебных
или оптимизаторских целях. Да мало ли для чего...
Текущие понятия xt и реализация COMPILE действительно делают реализацию
этого неудобным, если вообще возможным. Надо как-то переходить к
откладыванию
в не-форт словарях не прямых машкодов CALL, а пар wid:xt или
context:xt1:xt2:xt3...,
где wid и xt тоже не ссылки на код, а ссылки на имена (локальные таблицы
импортируемых имен для этих словарей, как таблицы импорта в dll).
> Например, при создании DLL сохраняется в необходимом формате весь
> образ форт-системы разом, без разбиения на особые определения и, в
> особенности, на особое откладывание исполнения токенов в эти
> определения.
>  
C dll, как и с exe, конечно проще - туда что угодно можно записать вместо
с реальным кодом, это "что угодно" как угодно исполняющим.

> Если же говорить о представлении форт-словарей (и форт-определений) в
> различной форме (например, различные формы откладываемого кода,
> организации списков имен,  распределения аппаратных ресурсов,
> размерности ячейки, и т.п.), то дело далеко не ограничивается
> операцией COMPILE. Для таких целей хорошо подходит отдельный экземпляр
> целиком форт-транслятора, настроенный на необходимую форму
> представления всего, чего нужно. Именно такое решение я использовал
> для создания "словарей" макетных форт-системы (32x и 64x), см. в
> ~pinka/samples/2007/fcomposition/
> В обоих случаях в слова в "других" словарях откладывались родные слова из spf4.
>  
Это тоже может пригодится (опять же инкапсуляция всех структур с кодом, как
в exe или dll), но в общем случае это перебор. В сишном мире аналогом
этого было
бы включение ОС в каждый исполнимый модуль. Впрочем, учитывая многообразие
всяких специализированных линуксов или даже поставку демо-версий программ не
в виде exe, а в виде VMware-образов, мир уже начинает осваивать такую
макромодульность. Надо будет попробовать продавать Eserv в комплекте с
заточенным
под него компьютером :-) - с всего тремя разъемами, сетевыми: двумя rj45
и одним 220,
и неизвестно чем внутри, наружу только TCP-порты торчат :)
> Практически же, требования к эффективности COMPILE-* (отложенному
> исполнению) обычно выше, чем к эффективности EXECUTE-*
> (непосредственному исполнению).
>  
Только грань между ними все более размывается со временем.


-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Ruvim Pinka
Привет!

2008/8/6 Andrey Cherezov <[hidden email]>
 
Я к тому, что было бы полезно или как минимум интересно уметь откладывать
код не в словари форта, а в базу данных или xml

Это легко доступно в виде копии: определение идет в обычный словарь системы и параллельно куда-то еще запись делается. Такое мы делали не раз (ты же и начало положил, когда тот xml сгенерил ;).

В общем же случае, существует целый ряд возможных ограничений и требований к такого рода задаче. Без их указания даже говорить не о чем.  Поэтому, давай конкретное ТЗ — будет почва для обсуждения :)


 [...]
 
Текущие понятия xt и реализация COMPILE действительно делают реализацию
этого неудобным, если вообще возможным. Надо как-то переходить к
откладыванию в не-форт словарях не прямых машкодов CALL, а пар wid:xt или
context:xt1:xt2:xt3..., где wid и xt тоже не ссылки на код, а ссылки на имена (локальные таблицы
импортируемых имен для этих словарей, как таблицы импорта в dll).

В таком случае, стоит на время забыть про понятия xt и COMPILE, и разрабатывать идею с чистого листа. Хорошо бы при этом решать какую-то конкретную задачу.


Когда я шел к forthml, то решал задачу о том, как записать, выразить и транслировать отложенное определение (причем, глубина откладывание не ограничена, а связывание имен доложно быть ранним).

--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

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

Ваше сообщение от 06.08.2008 21:34:
Я к тому, что было бы полезно или как минимум интересно уметь откладывать
код не в словари форта, а в базу данных или xml

Это легко доступно в виде копии: определение идет в обычный словарь системы и параллельно куда-то еще запись делается. Такое мы делали не раз (ты же и начало положил, когда тот xml сгенерил ;).
Да. Но это не совсем то. Возможности выполнить такой xml у нас не было. Можно было только посмотреть, поанализировать, пораскрашивать, повизуализировать :) Хотя можно было бы, конечно, довести до возможности выполнения и в том виде, как там это делалось, но, imho, с "виртуальными" словарями путь более прямой, естественный и прозрачный: выделяется набор слов, через которые идёт всё откладывание кода, и этот набор реализуется собственным способом для каждого типа словарей. Как виртуализация SHEADER в ~ac/lib/ns/*, но с продолжением для кода. Тогда в xml-словарь вполне можно было бы компилить код в формате ForthML ! :).
В общем же случае, существует целый ряд возможных ограничений и требований к такого рода задаче. Без их указания даже говорить не о чем.  Поэтому, давай конкретное ТЗ — будет почва для обсуждения :)
Вот, например, как я уже сказал, было бы интересно сделать твой TrafC отдельным плагином, т.е. чтобы он не лежал мертвым кодом внутри всех exe Eserv'а, когда у пользователей этот plugin отключен, а загружался только при подключении plugin'а, т.е. так чтобы он работал как все открытые plugin'ы Eserv'а, но сам TrafC оставался бы при этом закрытым, как сейчас.

Для ядра SPF это менее актуально, но все равно можно представить, например, оптимизатор, лежащий отдельным 100кб куском и загружающимся (без исходников) только когда у пользователя что-то компилится, и если у него включена оптимизация.

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

С подключениями модулей из исходных текстов (как сейчас) все работает прекрасно, но не годится для закрытых модулей, и усложняет установку "раскидистых" модулей. Кроме того могут быть особые зависимости типа нынешней зависимости протокольных расширителей от src\proto.f, которые, как мне кажется, при наличии какого-то LOAD-VOC вместо INCLUDED тоже могли бы разрешаться лучше.
В таком случае, стоит на время забыть про понятия xt и COMPILE, и разрабатывать идею с чистого листа. Хорошо бы при этом решать какую-то конкретную задачу.

Когда я шел к forthml, то решал задачу о том, как записать, выразить и транслировать отложенное определение (причем, глубина откладывание не ограничена, а связывание имен доложно быть ранним).
А здесь задача в том, чтобы скомпилить в нечто такое отдельное от основного модуля, что можно либо сразу каким-то интерпретатором исполнять (в адресном пространстве основного модуля и с привязками к его словам по именам), либо компилировать в основной модуль или временный словарь при загрузке (т.е., грубо говоря, чтобы некий NextWord брал следующее слово для компиляции не из исходника, а из этого полубинарника, причем так чтобы внутренние вызовы в пределах этого загружаемого внешнего модуля могли быть уже связаны на этапе создания этого модуля, а SFIND'у бы приходилось искать только привязки в основном модуле и возможно в других загружаемых словарях (для этого и требуется сохранение имени словаря - того словаря, в котором это слово находилось на момент предкомпиляции)). Т.е. нечто вроде линковки объектных модулей, но не в новый 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: word, vocabulary, namespace

Ruvim Pinka
Привет!

On 8/6/08, Andrey Cherezov <[hidden email]> wrote:
[...]
> с "виртуальными" словарями путь более прямой, естественный и прозрачный:
> выделяется набор слов, через которые идёт всё откладывание кода, и этот
> набор реализуется собственным способом для каждого типа словарей.

Подобный набор слов я "предложил" уже давно.
  — для кодогенерации:
  http://www.forth.org.ru/~pinka/spf/compiler/index.f
  http://www.forth.org.ru/~pinka/model/codegen/  (варианты)

  —  для организации списков слов:
  http://www.forth.org.ru/~pinka/spf/compiler/native-wordlist.f
  http://www.forth.org.ru/~pinka/model/data/wordlist-plain.f.xml  (вариант)


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

Мне понятны термины: имя (идентификатор), исполнимый токен, список
слов (список ассоциаций имен и токенов), область кода, область имен,
область данных, хранилище (как логическое объединение указанных
областей), откладывание исполнения (семантики исполнения).  Трудней с
определением понятий: слово, порядок поиска, область видимости, стек
списков слов, контекст, интерпретация имени, транслятор имени,
транслятор исходного кода. А определить понятие "словарь" совсем уж
невозможно ;)   (все это касательно форта, ессно).


[...]
> отдельным плагином, т.е. чтобы он не лежал мертвым кодом внутри всех exe

Лучше я его сделаю открытым! ;) (будет лежать рядом, и занимать чуть
больше места). Или, на крайняк, тот же dll (еще чуть больше места).


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

У меня есть мысль сделать поддержку пакетов в виде 7z-архива (или
т.п.). А закрытые модули пусть идут в машкод и dll. Делать обфускацию
не хочется.


[...]
> А здесь задача в том, чтобы скомпилить в нечто такое отдельное от
> основного модуля,
[...]
О, очень хорошо, уже понятней! :)
Задача выглядит решабельной при вводе некоторых ограничений на
отделяемый модуль и фиксировании интерфейсов, которые должны быть в
основном модуле.

По большому счету, задача состоит в разработке формата, в котором
будет представлен внешний модуль, и способа его загрузки. Способ же
порождения модуля выбранного формата — отдельная маленькая задача,
условием которой является этот самый формат.

Одно из решений: обычный маш-код spf4, таблица перемещений, таблица
точек вызовов наружу (внешнии точки подстраивается при загрузке, через
разрешения имен); ограничения на отделямый модуль: нельзя записывать
как числа адреса из основного модуля, нельзя делать вызов внешних
анонимных слов, обойтись без оптимизатора; интерфейс: всем необходимым
спискам слов в основном модуле следует дать унифицированные имена
(ввести пространство имен интерфейсов и лексиконов, о котором мы
как-то обсуждали), в основном модуле должен находится загрузчик для
отделямых модулей. По идее, для реализации порождения достаточно
перехватить только момент откладывания исполнения. Подобная техника
(но проще) использовалась для Eserv/2.

--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
123
Loading...