FFI

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

FFI

Ruvim Pinka
Привет!
В ядре SPF должен быть простой базовый API для вызова внешних функций
(FFI), он должен быть обобщенным (унифицированным) и независимым от
ОС. А "синтаксический сахар" пусть опционально цепляется сверху (при
этом, если реализация этого "сахара" привносит мешающие ограничения,
то можно было бы обойтись и без него).

Для связи с внешней функцией необходимы: имя библиотеки, имя функции,
число параметров на входе и выходе, формат вызова.
У нас есть общие слова DLOPEN и DLSYM, но нет общего интерфейса для
представления внешнего ext-xt, его вызова и откладывания вызова
(компиляции вызова, которая может отличатся от простого вызова в целях
эффективности). Этот интерфейс должен учитывать различные форматы
вызова и число параметров на входе и выходе (в некоторых случаях число
параметров одной функции отличается при разных вызовах). Как вариант,
на низком уровне вызов можно разбить на три части (и сделать три
откладывающих слова): экспорт входных параметров, вызов, импорт
выходных параметров.
(В некотором роде, описываемая подсистема FFI аналогична нативной: xt
(BIRTH, CONCEIVE), EXECUTE, "EXEC," и является расширением
кодогенератора).

Вопрос в следуюем. Есть ли аргументы в пользу того, что общий
интерфейс такого рода в рамках SPF неоправдан, и пусть в каждой ОС или
сборке будет свой вариант?


Не зависим от этого, интерфейс более высокого уровня тоже должен быть общим.
Есть несколько вариантов такого интерфейса, позволяющих эффективный
вызов внешних функций:
1) определяющее слово (как "WINAPI:");
2) немедленное слово-парсер (заглядывающее вперед, как это слово "))"
или CALL в некоторых форт-системах);
3) расширение транслятора (как NOTFOUND, "умные" словари или стек
трансляторов слов в придачу к стеку контекста словарей).

На данный момент, самый проработанный и реально работающий вариант —
это dll-xt.f и so-xt.f (расширение транслятора, "умные" словари) от
Андрея (~ac).
Но, в этом решении есть такие особенности и подводные камни, как:
  — операция разрешения имени (поиска) небезопасна, она может породить
новые структуры и нарушить код, что противоречит обычному опыту (если
операция поиска что-то создает, это должно быть в изолированной
области, не пересекающейся с "пользовательским" пространством);
  — дополнительный праметр вначале, дающий число экспортируемых
параметров (не обобщается на выходные параметры, непривычно, я бы
предпочел указывать синтаксически, типа "curl_easy_setopt(3)");
  — сильная завязка на словари, не выделено низкоуровневой базы, не
зависящей от словарей, не выделена часть кодогенератора ("SO-CALL,"
требует wid, в SO-CALL параметр передается через стек возвратов).
Тем не мнее, это пока лучшее решение из независящих от ОС :)

--
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
|

Re: FFI

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

Ваше сообщение от 02.08.2008 7:26:
> На данный момент, самый проработанный и реально работающий вариант —
> это dll-xt.f и so-xt.f (расширение транслятора, "умные" словари) от
> Андрея (~ac).
> Но, в этом решении есть такие особенности и подводные камни, как:
>   — операция разрешения имени (поиска) небезопасна, она может породить
> новые структуры и нарушить код, что противоречит обычному опыту (если
> операция поиска что-то создает, это должно быть в изолированной
> области, не пересекающейся с "пользовательским" пространством);
>  
Тут можно было сказать короче:
 - эти либы не доработаны для применения в режиме интерпретации.

Но до тех пор, пока у нас xt обязан быть пригодным для прямого вызова
маш.командой CALL, других вариантов использования внешних функций
без создания оберток их вызова и не может быть. Можно, конечно,
компилировать обертки (при интерпретации) куда-нибудь не в основной HERE,
а во временный допустим, но это уже глубоко вторичный частный вопрос.
Раньше мы вообще не могли вызывать API-функции просто по имени без
их предварительного объявления (т.е. компиляции обертки), можно продолжать
это делать, но более кратко (сама dll/so объявляется один раз как
словарь) и с
большей пользой, сразу создавая "value added" обертку
: слово,упрощающее_внешнюю_функцию ... внешняя_функция ... ;
В общем, по любому в сравнении с синтаксисом "WINAPI" большой шаг вперед.
Можно только пожалеть, что я не сделал этого сразу - еще в 95м году.
>   — дополнительный праметр вначале, дающий число экспортируемых
> параметров (не обобщается на выходные параметры, непривычно, я бы
> предпочел указывать синтаксически, типа "curl_easy_setopt(3)");
>  
А я против неестественного (для форта) синтаксиса. Число параметров - это
реально существующий параметр вызова (так же как и в колбэках), а в
традициях
форта принято все параметры класть на стек перед вызовом.
И я не понял, что значит "не обобщается на выходные параметры"?
>   — сильная завязка на словари, не выделено низкоуровневой базы, не
> зависящей от словарей, не выделена часть кодогенератора ("SO-CALL,"
> требует wid, в SO-CALL параметр передается через стек возвратов).
>  
Не понял, чем плохо перечисленное тобой в скобках. "SO-CALL," требует
словаря,
т.к. мы из словаря (внешнего!) вызываем. SO-CALL передает параметры через
стек возвратов, т.к. именно на стеке возвратов и принято передавать
параметры
в Си (который мы вызываем) - это мудрое упрощение API-CALL я подглядел
у Миши в его варианте LinuxSPF (который вперемешку с Си). Т.е. не надо
даже никакого API-CALL - затолкал все сишные параметры в сишный стек и
делаешь обычный EXECUTE. API-CALL и его предшественников я реализовал
иначе, т.к. был уверен в необходимости сохранения регистров. Практика
использования нового способа показала, что сохранение регистров - это
излишняя
и дорогая перестраховка. Выходит, что сишные функции сами
сохраняют/восстанавливают то, что меняют.

Ну а самое главное - внешние dll/so - это словари и есть. Разве нет?
> Тем не мнее, это пока лучшее решение из независящих от ОС :)
>  
Главное, что реально рабочее. Может по мере дальнейшего использования
и понадобятся переделки, но пока все нормально (под виндой не первый год
реально используется, и на линуксе легкость использования без переделок либ
радует). И очень компактное - всего 4кб бин.кода. Было бы полезнее в
ядре, чем
некоторые существующие там компоненты, но оно и вне ядра неплохо работает :)

Более важной, чем перечисленные здесь, проблемой в dll-xt/so-xt я бы назвал
способ указания имени внешней dll и её связи с реальным именем и
расположением.
Сейчас в портабельных либах просто приходится указывать имя dll и имя so,
т.е.
ALSO SO NEW: libexpat.dll
ALSO SO NEW: libexpat.so
Это объявляет и подключает два словаря как обычные контекстные словари.
Само по себе это совершенно естественно при подходе к dll как к словарю
(и дальнейшее использование при необходимости как "ALSO libexpat.dll" тем
более). Но (как уже обсуждалось) может быть логичнее указывать просто имя
внешней библиотеки, а файловые её детали упрятать в некую виртуальность...
Но, с другой стороны, мы ведь и свои родные фортовые либы по файловым
именам вызываем, и как-то с этим четвертую пятилетку живем. Может оно так и
надо просто в лоб. Там и ОС помогает искать,.. да и переопределить vDLOPEN
каждый может на свой вкус в меру своей испорченности высокими технологиями.
Я обычно переопределяю, чтобы кроме текущего каталога [и прочих в рамках
системой процедуры поиска dll/so] смотрелось еще в ext, ../ext,
../../ext от модуля,
чтобы можно было разделять общие dll между проектами, но не добавлять эти
каталоги в глобальный PATH, и использовать при желании локальные копии
общих dll (другую версию, например). Это реально работает в Eserv'е и
нескольких
других программах, т.е. уже можно считать надежным и устоявшимся способом.

Я готов принять и использовать любую другую лучшую реализацию подключения
внешних dll/so. Но две вещи для меня существенны:
1) dll/so - это словари (во всех смыслах, только с readonly-режимом).
2) базовый синтаксис должен быть фортовым (я и вызовы COM/IDispatch
переписал так в конце-концов - Юрин синтаксис[ы] automate/automation я
хоть и
использовал активно много лет, но так и "не прирос").

Да, кстати, к слову, IDispatch - это тоже словари, т.е. когда-нибудь и
это надо
упростить еще дальше - объявлять COM-интерфейсы контекстными словарями,
как это сделано наконец для dll/so). И вызывать в контексте напрямую по
имени
без объявлений и без доп.синтаксиса.

Т.е. за пп.1 и 2 я буду стоять насмерть, и иную идеологию уже не приму
(в _свою_
практику :) Очень уж это хорошо прижилось и расцвело :)


-------------------------------------------------------------------------
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
|

Re: FFI

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

Ваше сообщение от 02.08.2008 7:26:
> Вопрос в следуюем. Есть ли аргументы в пользу того, что общий
> интерфейс такого рода в рамках SPF неоправдан, и пусть в каждой ОС или
> сборке будет свой вариант?
>  
А на вопрос-то я забыл ответить :)
Мой ответ - конечно, унифицированные методы лучше. Но если считать dll/so
словарем, то это и есть его унификация - пишем имя, и не думаем об xt :)
И тогда дробить и унифицировать низкоуровневые детали реализации не
обязательно
(мы же не обсуждаем формат откладывания вызовов  собственных слов форта,
т.е. машинную команду CALL или косвенные вызовы, или оптимизированные
подстановки на месте, другие процессоры и т.д.). Вопрос на самом деле в
другом -
быть или не быть xt для "чуждых" функций, и быть ли ему единым. Если быть,
то разницу между локальным  вызовом и междуязыковым (и межпроцессным,
и сетевым...) надо как-то внутри xt скрывать, значит делать обертки. А
уж как именно
их делать - вопрос второстепенный. Я вот код команды CALL уже не помню -
C9 или C3? ;)

А если общему xt быть не обязательно, т.е. если должны быть xt и ext-xt с
разными способами использования, то можно это считать двумя разными
вопросами,
и второй (ext-xt) собственно к xt и не относящимся: можно вызывать нечто
по имени
или по номеру, или еще как (допустим, просто целой строкой нескольких
команд на
чуждом языке, передаваемую исполнителю через единую точку входа (а не по
отдельной
для каждой функции)), т.е. даже не вводя xt как промежуточное представление,
в общем в стиле "...а с лошадьми по-немецки".


-------------------------------------------------------------------------
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
|

Re: FFI

Ruvim Pinka
In reply to this post by Andrey Cherezov
Привет!

Andrey Cherezov:
> Тут можно было сказать короче:
> - эти либы не доработаны для применения в режиме интерпретации.

я хотел прикрутить их в транслятор forthml (даже и для компиляции) —
сходу не получилось, по указанным причинам.

> Не понял, чем плохо перечисленное тобой в скобках.

\ SO-CALL ( на стеке возвратов адрес структуры импорта вызываемой функции )
— зачем адрес этой структуры передается через стек возвратов? (не, я
понимаю зачем: так удобно было для реализации; но, это неудобно для
повторного использования).

\ SO-CALL, ( funa funu n dll-wid xt -- addr )
— зачем тут нужна завязка на dll-wid? (да, чтобы взять имя файла
библиотеки, но wid-то тут не причем, лучше бы обойтись без этой
завязки).

>И я не понял, что значит "не обобщается на выходные параметры"?
Как быть, если выходных параметров более одного? (например, если
вызываем функцию из другой форт-системы)
В случае "синтаксиса" можно указать: my_cool_function(3,2)  (три
входных параметра, два выходных). А как быть в случае, если это числа
на входе слова?
Как вариант, особо объявить всю библиотеку/so, и указывать для всех
функций из нее два дополнительных параметра, вместо одного. Непривычно
и главное автоматичесчки не проверить (у меня поначалу куча зевков
было на эти доп. параметры!).
В случае синтаксиса факт указания числа параметров поддается
автоматической проверки, и, кроме того, сам вызов просто поддается
оптимизации (например, если один параметр всего, то сделать ему >R
вместо DRMOVE).

Я пишу "синтаксис" в кавычках, т.к. для форт-трарнслятора это
все-равно одно слово, а его внутренний формат разбирала бы подсистема
поддержки so. Точно так же, как мы пишем ~ac/lib/str5.f и spf
отрабатывает подключение файла; для транслятора это одно слово, но оно
имеет внутренний формат (путь, каталоги, слэши), который разбирает
файловая подсистема.
Припоминаю, что была идея фикс, что это тоже должна понимать
форт-система, и тогда достаточно писать через пробел вместо слэша: ~ac
lib str5.f — но, такое использование трудно поддается контролированию
в простом форт-тексте. Если добавить над-структуру (forthml ;), то
будет проще. Например, <fs> ~ac lib str5.f </fs> — слова, которые
передаются на трансляюцию модулю filesystem, четко ограничены.



> Раньше мы вообще не могли вызывать API-функции просто по имени
> без их предварительного объявления (т.е. компиляции обертки)
Кстати. А ведь сейчас все еще требуется объявление библиотеки. Может,
и эту декларацию завтоматизировать подобным образом? ;)  И еще, по
идее, стоит отлавливать повторные декларации библиотеки и сводить их к
одному объекту.



> Ну а самое главное - внешние dll/so - это словари и есть. Разве нет?
Конечно, словари! :)  Просто, они не нативно-фортовые.

Поэтому, у меня есть идея использовать несколько стеков со словарями.
Т.е., не один единственный стек (список) контекста, в который пихается
все, а "дерево" конекста.

--
Ruvim

--
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
|

Re: FFI

Ruvim Pinka
> Более важной, чем перечисленные здесь, проблемой в dll-xt/so-xt я бы назвал способ указания имени внешней dll и её связи с реальным именем и расположением.

Я решил, что этот момент имеет малое отношение к собственно FFI, и сам
по себе распространяется не только на внешние библиотеки, но и на
фортовые тоже, как ты верно заметил. Рабочее название темы: sharedlex
— разделяемые лексиконы. Тема в процессе обдумывания и
прототипирования :)

--
Ruvim

--
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
|

Re: FFI

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

Ваше сообщение от 03.08.2008 2:02:
я хотел прикрутить их в транслятор forthml (даже и для компиляции) —
сходу не получилось, по указанным причинам.
  
Ну, значит в forthml компиляция несовместима с spf. Т.е. тебе это нужно переписать
также по своему, как ты переписал компиляцию.
\ SO-CALL ( на стеке возвратов адрес структуры импорта вызываемой функции )
— зачем адрес этой структуры передается через стек возвратов? (не, я
понимаю зачем: так удобно было для реализации; но, это неудобно для
повторного использования).
  
А это вообще запрещено к повторному использованию указаниями в начале
файла "Из определенных здесь слов рекомендуется к использованию только
словарь SO" (а не слова SO-*).

"Я это сам себе не позволяю" (C) :)
\ SO-CALL, ( funa funu n dll-wid xt -- addr )
— зачем тут нужна завязка на dll-wid? (да, чтобы взять имя файла
библиотеки, но wid-то тут не причем, лучше бы обойтись без этой
завязки).
  
Чем же лучше? Имя файла библиотеки - это родное свойство словаря. С момента
объявления "SO NEW:" wid является полномочным представителем всего что
связано с подключением этой библиотеки. Т.е. фактически oid, через него все и
виртуализуется. Это же центральная идея. Причем не только здесь, а везде, где
используются имена чего либо. Имя неотделимо от контекста. Если его не указывать
явно при использовании (как в этом слове), то нужно где-то хранить для неявного
использования (как стек контекстов в форте).

И даже если бы не было этих (основных) доводов, SO-CALL пытается сохранять
обратную совместимость с WINAPI по формату создаваемых структур.
Как быть, если выходных параметров более одного? (например, если
вызываем функцию из другой форт-системы)
  
Вот когда будем вызывать внешний форт из форта, тогда и поговорим. Интим между
двумя форт-системами - особая отдельная тема. Мы тут о привязке чуждых сишных
интерфейсов, а с фортами можно по-фортовому поговорить без нагромождения огородов.
Вон даже с тем же DCOM'ом можно вполне по-свойски (а не по-сишному) беседовать.
В случае "синтаксиса" можно указать: my_cool_function(3,2)
Щас буду кусаться :-[]
  (три
входных параметра, два выходных). А как быть в случае, если это числа
на входе слова?
  
3 2. Или, если угодно, 2 3.
Как вариант, особо объявить всю библиотеку/so, и указывать для всех
функций из нее два дополнительных параметра, вместо одного. Непривычно
и главное автоматичесчки не проверить (у меня поначалу куча зевков
было на эти доп. параметры!).
  
У меня тоже. Но это потому что мы привыкли к "WINAPI:", который я неправильно
спроектировал (не думал о существовании различных соглашений о связях). Посыпал
голову пеплом и сделал правильно.

Не принимай близко к сердцу число параметров, мы ведь обычно не используем
API напрямую, а все равно всегда пишем более удобные форт-обертки, т.е. эта
"сложность" сразу же инкапсулируется, после чего голову можно проветрить, забыть
детали и писать на еще более простом форте.
В случае синтаксиса факт указания числа параметров поддается
автоматической проверки, и, кроме того, сам вызов просто поддается
оптимизации (например, если один параметр всего, то сделать ему >R
вместо DRMOVE).
  
Да забудь ты про DRMOVE. Я его и не знал. Используй слова :)
А факт указания чего-то там в скобках делу проверки не поможет, т.к. сравнивать
автоматизировано не с чем, нет базы данных "сигнатур" сишных функций (в отличие
от сиплюсплюсных).
Вообще если речь об автоматизированной ловле ошибок, то это как бы совсем
оффтопик. Ты что, забыл, что форт-программисты
1) не ошибаются :), поэтому могут, в частности, легко обходиться без контроля типов
и всех прочих прибамбасов, которые придумали для тупых и ленивых за 40 лет;
форт-программисты используют только "спеллчекер" - "слово не найдено".
2) когда они все-таки ошибаются (временно становятся не-форт программистами,
а усталыми и невнимательными студентами), форт быстро выводит их на чистую
воду магическими словами exception и т.п.
Я пишу "синтаксис" в кавычках, т.к. для форт-трарнслятора это
все-равно одно слово, а его внутренний формат разбирала бы подсистема
поддержки so. Точно так же, как мы пишем ~ac/lib/str5.f и spf
отрабатывает подключение файла; для транслятора это одно слово, но оно
имеет внутренний формат (путь, каталоги, слэши), который разбирает
файловая подсистема.
  
Ну, вообще-то я и для файловой системы сделал словари - files.f :)
И ~ac/lib/str5.f мы пишем вместо S" ~ac/lib/str5.f" INCLUDED, когда спешим или
ленимся. А изначальная реализация этого хака была сделана мною только для того,
чтобы состыковать общепринятый способ вызова трансляторов
"транслятор.exe имя_файла.язык" с возможностью использования в ком.строке
программы любых слов форта (как фортовым способом реализуются у меня "опции
командной строки"). Т.е. убил двух зайцев.
И вообще никакого противоречия тут нет - запись пути файловой системы через
слэши - таков язык файловой системы, т.е. с лошадью мы говорим на её родном
немецком :) Но это вовсе не значит, что с фортом мы должны говорить на
свежевыдуманном самодельном языке. Логичнее все же с фортом на форте, когда это
возможно.
Припоминаю, что была идея фикс, что это тоже должна понимать
форт-система, и тогда достаточно писать через пробел вместо слэша: ~ac
lib str5.f 
Ну да, так и есть: см.
WINDOWS system32 drivers etc hosts
в ~ac/lib/ns/files.f - т.е. идея не фикс, а все та же идея "нет дыма без огня", точнее
"нет имён без словарей", реализованная мною для большинства популярных
типов namespaces, и подходящая вообще для всех. Собственно, это и не моя идея,
а всеобщая, и повсеместно работающая, просто об этом редко задумываются,
поэтому редко видят это общее.
— но, такое использование трудно поддается контролированию
в простом форт-тексте.
Контролируется-то оно нормально (даже внутре такого сложного существа как IMAP-сервер),
но во внешний мир, разговаривающий "на немецком", приходится конвертировать
в традиционный формат (FULLPATH в той же либе files.f) и обратно. Это хоть
и автоматизируется, но все же дорогие операции - строки и словари. А это как раз тот случай
(файлы), когда экономить не вредно (не до жиру, все запасы жира давно съели разработчики NTFS).
 Если добавить над-структуру (forthml ;), то
будет проще. Например, <fs> ~ac lib str5.f </fs> — слова, которые
передаются на трансляюцию модулю filesystem, четко ограничены.
  
Если проблемы только с визуальным восприятием, то можно написать это на отдельной строке
и даже отделить пустыми строками... А если меня будут заставлять писать галочки,
то я лучше уйду в монастырь писать скобочки (на лиспе), хоть на слэшах и запятых сэкономлю :).
Или в крайнем случае буду в визуальном редакторе слова раскрашивать как Мур (и генерировать
из них твой forthml автоматически).
Раньше мы вообще не могли вызывать API-функции просто по имени
без их предварительного объявления (т.е. компиляции обертки)
    
Кстати. А ведь сейчас все еще требуется объявление библиотеки. Может,
и эту декларацию завтоматизировать подобным образом? ;)
Искать словарь по слову? Во-первых, это долго (по причине жирной файловой системы).
Во-вторых, неправильно, т.к. противоречит идее явного управления контекстами, т.е.
можем случайно найти одноименное слово в совсем другом несовместимом namespace.
Системный PATH (явно заданный контекст поиска в ф.с.) - не столь управляем, как фортовый
стек контекстов.
Объявление библиотеки = объявление словаря, оно всегда должно быть явным, как
и определение переменных.
  И еще, по
идее, стоит отлавливать повторные декларации библиотеки и сводить их к
одному объекту.
  
Можно. Как надстройку, а не запрет на повторное создание объекта. В форте
ведь не запрещены одноименные словари, просто предупреждения выводятся,
то же самое срабатывает и здесь, в качестве вознаграждения за форт-путь :)

ALSO SO NEW: sqlite3.dll
 Ok
ALSO SO NEW: sqlite3.dll
sqlite3.dll isn't unique
 Ok
Ну а самое главное - внешние dll/so - это словари и есть. Разве нет?
    
Конечно, словари! :)  Просто, они не нативно-фортовые.
  
Только тем, что readonly. Кстати, было бы очень заманчиво научиться сохранять
любой словарь форта в виде dll ;) Это был бы САМЫЙ нативный способ из всех возможных
способов создания dll/so (отсутствие нормальных способов генерации dll - самый
большой пробел в SPF). И вообще это самый правильный способ создания любой
внешней структуры - генерация в виде словаря и экспорт его (или даже просто
запись его, если генерация тоже "нативная"). Ведь ничто не мешает нам компилировать
форт напрямую в xml (использовать твой forthml не как исходник, а как "бинарник" :),
или в ресурсы, или в базу данных, или в сеть. Они ничем не хуже локального машкода ;)
Поэтому, у меня есть идея использовать несколько стеков со словарями.
Т.е., не один единственный стек (список) контекста, в который пихается
все, а "дерево" конекста.
  
Дерево контекста - не новая идея. В старых фортах так и было, и в до-94 в SPF тоже.
А в JavaScript и сейчас так. Только вот, как показала практика (форт-практика, по крайней
мере) это сложнее в управлении. Хотя, если ветки не жестко привязаны, к родителям,
то возможностей такая схема дает больше, согласен. Но и путаницы больше. Контексты
и без того любят сложные ошибки устраивать...


-------------------------------------------------------------------------
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
|

Re: FFI

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

2008/8/3 Andrey Cherezov <[hidden email]>
> Вопрос в следуюем. Есть ли аргументы в пользу того, что общий
> интерфейс такого рода в рамках SPF неоправдан, и пусть в каждой ОС или
> сборке будет свой вариант?
>
А на вопрос-то я забыл ответить :)
Мой ответ - конечно, унифицированные методы лучше.

Давайте в будущем использовать фиксированный базовый лексикон для реализации FFI, прототип которого реализован мной в spf/ffi/core.f

Предложения по именованиям, или вообще? :)


--
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