Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт мар 28, 2024 23:58

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 61 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Чт янв 25, 2007 17:39 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
уже сказал, нет у СПФ-а слова FORGET! так как не предусмотрено это слово в ansi94 стандарте
а какие другие слова не находит?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт янв 26, 2007 07:10 
Не в сети

Зарегистрирован: Ср сен 13, 2006 10:06
Сообщения: 636
Откуда: Омск
Благодарил (а): 0 раз.
Поблагодарили: 3 раз.
В доке по sp 4.18 сказанно что слово FORGET исключенно.

_________________
Меня нет, не будет и не было.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт янв 26, 2007 10:30 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
mOleg писал(а):
А вот теперь вопрос: у кого есть какие наработки в этом направлении?
То есть кто занимался расширением возможностей словарей и какие идеи есть по этому поводу?


В Win32Forth (STC) такая вот структура словарей:

Код:
LIB and PROC structures
  -----------------------

  These are in support of the Windows API interface.

  LIB structure as of V0.01.00

        [ link field       ]  0         LFA  LIB link field
        [ libhandle        ]  4         HANDLE of the library after load
        [ name             ]  8         NAME counted string

  PROC structure as of V0.01.00

        [ link field       ]  0         LFA  PROC link field
        [ entry point      ]  4         EP   entry point
        [ lib struct ptr   ]  8         LIB  ptr to lib entry
        [ parm&flags       ]  12        PCNT Parm counter & flags
        [ name             ]  13        NAME counted string

  PCNT: MSB 8  128  UNKNOWN#; we don't know the number of parms
            7   64  off=MULTI, on=SINGLE
                    MULTI -- ignore the library field if loading the proc, and
                    search all the libraries defined for the name
                    SINGLE -- search only the library specified in the lib pointer
            6   32  EXTERN -- don't call, an external variable that's fetched
            5   16  unused
        LSB 4-1     COUNT of # of parms (0 to 15)

  Header structure
  ----------------

  State of flux; see the HEADER word for details.

        [ link field       ] -4  4     lfa
        [ compile, action  ] -8  4     ct: comp
        [ compile, xt      ] -4  4     ct: ctc
  +---- [ xt ptr field     ] +0  4     xt-ptr
  |     [ file field       ] 12  4     ffa
  |     [ view field       ] 16  2     vfa
  |     [ stk effects      ] 18  2     ste
  |     [ optimize field   ] 20  1     ofa
  |     [ count byte       ] 21  1     nfa
  |     [ the name letters ] 22  n
  |     [ alignment bytes  ]  0 to 3 bytes for name alignment
  |
  |
  |     [ xt to compile    ] -4  4     ct: ctx
  +---> [ xt field         ] +0        xt code field (the xt)


  ct:  Compilation token, a 2 dword pair.
       ctc: what to do when compiling this word
       ctx: what to do when executing this word

  ct-ptr: points to the ct pair (arrow not shown)

  ofa: msb 8  128  immediate flag
           7-1 64  type of name
                   0 unknown
                   1 create
                   3 constant
                   4 variable
                   5 value
                   6 local
                   7 defer
                   8 user
                   9 vocabulary
                  10 proc
                  11 code (both code and colon defintions)
                  91 class
                  92 object
                  93 method

  ste: byte 1    stk-i effects input
       byte 2    stk-o effects output
       -ve indicates stack effects are unknown.

  ofa: msb 15      immediate flag (superceded by ct?)
       lsb 14-0    length of the xt code field

  ffa: dword ptr to the filename where this xt defined.

  vfa: unsigned word (0-64k) line number in file ffa.
       Allows input files of up to 64k lines; >64k simply wraps around.


  Vocabulary dictionary structure
  -------------------------------

  Vocbularies are self-defining, self-searching and iterable. In other
  words, the internal structure of a vocabulary is hidden from the end
  user by a simple OO type technique. The header contains entry points
  for

    vhead -- used to define a word in this vocabulary
    vsrch -- used to find a word in this vocabulary
    viter -- used to iterate over the contents of the vocabulary

  This allos vocabularies and wordlists to be independant of any structure;
  they could be held on disk, in SQL tables, defined as trees etc.

    voc [ num voc threads  ] +0           #threads
        [ voc header       ] +4           vhead
        [ voc search       ] +8           vsrch
        [ voc iterate      ] +12          viter
        [ voc xt           ] +16          nfa ---> xt for this vocab
        [ voc link         ] +20          vlink
    wid [ voc thread 0     ] +24          voc thread 0 = voc-address
        [ voc thread 1     ] +28          voc thread 1
        [ voc thread 2     ] +32          voc thread 2
        [ voc thread ...   ] +n*4+24      voc thread n

  vtype: 1   Standard vocabulary
         2   Lexicon
         3   PROC list
         4   Class
         90+ User

Размахнулись конечно они широко - пишут что сделано это с целью ускорить форт-код.
Правда оптимизатора пока нет - говорят, что делают.

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт янв 26, 2007 17:07 
Цитата:
This allos vocabularies and wordlists to be independant of any structure;
they could be held on disk, in SQL tables, defined as trees etc.

~ac же занимался и решил (?) эти вопросы для SPF. Например, ~ac/lib/ns/files.f -- представление директории как дерева словарей (с возможностями создания "слов"-файлов). А также: ~ac/lib/ns/dll-xt.f -- представление DLL-файлов как подключаемых словарей, ~ac/lib/ns/xml.f -- представление внешних XML-файлов как словарей и ~ac/lib/ns/sqlite3.f -- представление БД как словарей.

У меня по этому поводу ничего не спрашивайте -- как-то не довелось попользовать...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт янв 26, 2007 18:55 
Не в сети

Зарегистрирован: Чт май 04, 2006 18:18
Сообщения: 456
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
Описание - XmlAsWordlist

_________________
http://forth.org.ru/~ygrek


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб янв 27, 2007 18:01 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
profiT писал(а):
~ac же занимался и решил (?) эти вопросы для SPF. Например, ~ac/lib/ns/files.f


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

chess писал(а):
В Win32Forth (STC) такая вот структура словарей:

спасибо chess. Внимательно смотрю


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб янв 27, 2007 18:47 
mOleg писал(а):
То есть на уровне ядра, а не на уровне заплаток.

Оно и есть на уровне ядра: http://wiki.forth.org.ru/VectSheader.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб янв 27, 2007 18:50 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
profiT писал(а):
mOleg писал(а):
То есть на уровне ядра, а не на уровне заплаток.

Оно и есть на уровне ядра: http://wiki.forth.org.ru/VectSheader.


а я не о том, речь идет о WORDLIST а не о HEADER!!!


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс янв 28, 2007 11:19 
Не в сети

Зарегистрирован: Пт июн 23, 2006 14:05
Сообщения: 126
Благодарил (а): 1 раз.
Поблагодарили: 16 раз.
mOleg писал(а):
Ну что ж. Никто не сказал о главном 8(
Попробую я обьяснить, что хотел бы от словарей.

Хочется, чтобы небыло, например слов для работы с файлами, а файловая система виделась как словарь форт-системы, хочется, чтобы работать с COM можно было, как с обычным словарем, хочется, чтобы та же динамическая память ( распределенные и свободные блоки) виделась как словарь. То есть хочется, чтобы словарь форта был подобен линуксевой VFS, но при этом был бы на много проще.
Для этого нужно как минимум, чтобы методы find execute были у каждого словаря свои...


Такие расширения для SPF уже сделаны, причем для этого даже введены изменения в ядре. Идею эту обсуждали много лет. Одна из реализаций - ~ac/lib/ns/ns.f (первая версия - в начале 2005 года), ~ac/lib/ns/xml.f, ~ac/lib/ns/files.f (см. примеры в конце) . Как словари подключаются - файловые системы, xml-файлы, DLL и SO, базы данных и т.д. Причем для xml и файлов - read/write. Это все в позапрошлом году. Рувим недавно еще сделал монтирование хранилищ для временных словарей.

Так что читайте cvs log, и мы избежим изобретения велосипедов.

Про свой execute для каждого словаря - тоже обсуждалось многократно. Но надо разделять задачи поиска (словарь как список для поиска, NS) и задачи компиляции/выполнения (словарь как хранилище).

Низкая активность в этом направлении связана с тем, что это имеет мало практических применений, т.к. требует серьезных изменений в мышлении, причем не только со стороны фортеров :) Ну и есть технические проблемы - усложнение управления памятью в таких приложениях; усложнение интеграции с ОС (ей ведь все-равно нужны пути файлов в традиционном виде).

Но как минимум одно применение этого подхода за эти два года прижилось очень хорошо - это подключение *.DLL и *.SO к форту в качестве внешних read-only словарей - ~ac/lib/ns/dll-xt.f и so-xt.f - намного удобнее, чем ручное определение через WINAPI, причем работает (испытано) и на Linux-SPF. Не требует использования NOTFOUND (в отличие от api-func.f Андрея Филаткина, 2003г).


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс янв 28, 2007 11:21 
Не в сети

Зарегистрирован: Пт июн 23, 2006 14:05
Сообщения: 126
Благодарил (а): 1 раз.
Поблагодарили: 16 раз.
Во, недочитал тред, и в итоге повторился :) Прошу прощения :)

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс янв 28, 2007 11:41 
Не в сети

Зарегистрирован: Пт июн 23, 2006 14:05
Сообщения: 126
Благодарил (а): 1 раз.
Поблагодарили: 16 раз.
mOleg писал(а):
а я не о том, речь идет о WORDLIST а не о HEADER!!!

Одно другого не исключает :)

Через виртуальный SEARCH-WORDLIST мы сделали возможность ПОИСКА в любом namespace - будь то файлы, базы, xml, dll или родные фортовые словари (и столь же легко добавить поиск в чем угодно, хоть в гугле :-).

Через виртуальный SHEADER мы сделали возможность СОЗДАНИЯ новых именованых элементов в тех namespaces, в которых только что научились искать.

Обе эти задачи не требуют изменений в WORDLIST, имеющаяся в SPF структура и так больше 10 лет назад получила дополнительные поля (как раз для этого, кстати - виртуальные словари использовались в SPF в разных видах еще в DOS-времена).

Остались нерешенными задачи компиляции _тела статьи_ в произвольный (в т.ч. внешний namespace, если он допускает запись в отличие от dll) словарь и последующего выполнения из этого словаря. Для компиляции нужно виртуализовать ",", "CALL," и т.п. или менять сам INTERPRET. Некоторые шаги в этом направлении см. ~pinka/spf/storage-core.f , там есть даже "форматирование" словарей как дисков :) Сейчас эта библиотека используется ("промышленно", т.е. в Eserv :) для компиляции во временные словари - более полноценной и потоко-безопасной, чем в реализации временных словарей в ядре. Т.е. потоки могут заниматься не только интерпретацией, но и компиляцией, одновременно, не боясь пересечься на HERE.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс янв 28, 2007 12:18 
Не в сети

Зарегистрирован: Пт июн 23, 2006 14:05
Сообщения: 126
Благодарил (а): 1 раз.
Поблагодарили: 16 раз.
mOleg писал(а):
Кстати не только я озабочен такой проблемой: http://www.forth.org.ru/~mlg/#t32 вот 8) : Исполнимый стек словарей T32 — расширение языка Форт: словари являются функциями, и можно определять функции, ведущие себя как словари.

Исполнимые словари в SPF это тоже были, еще во времена SPF/1.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс янв 28, 2007 12:28 
Не в сети

Зарегистрирован: Пт июн 23, 2006 14:05
Сообщения: 126
Благодарил (а): 1 раз.
Поблагодарили: 16 раз.
mOleg писал(а):
То есть, если вы хотите быстро написать свою систему и не хотите заморачиваться, то вы просто берете и делаете односвязный список - благо это легко реализуется даже на Си. И соответственно получаете очень медленный интерпретатор.
Так поступает СПФ, хотя уже давно не стремится к простоте... Чем хороши хешированные словари?:


Я не понимаю, mOleg, к чему все это пишется? SPF действительно стремится к простоте (и если кто-то когда-то засунул в ядро что-то лишнее, то это еще не значит, что это укладывается в изначальную философию SPF; и это уже признано [теми кем-то] и может быть исправлено в SPF5, т.е. он снова станет проще и меньше).

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс янв 28, 2007 23:46 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Огромное спасибо за ответы, Андрей!

ac писал(а):
Я не понимаю, mOleg, к чему все это пишется? SPF действительно стремится к простоте (и если кто-то когда-то засунул в ядро что-то лишнее, то это еще не значит, что это укладывается в изначальную философию SPF; и это уже признано [теми кем-то] и может быть исправлено в SPF5, т.е. он снова станет проще и меньше).

СПФ5 я еще не видел. А спф4 имеет достаточно много неудобностей.
На работый Рувима я сейчас смотрю, но все-же замечу, что даже в 18 сборке еще не было данных файлов, а мои вопросы были написаны раньше. Кроме того, как мне кажется, все прикручивается не с той стороны - то есть сейчас все делается поверх существующих словарей, а надо бы вместо них - то есть менять снизу. Но этим я сейчас занимаюсь и в ближайшее время надеюсь представить на всеобщее обозрение результат.
Прикручивание хешей поверх существующего словаря красиво, но сложнее(точнее очень сильно перетяжелено), чем если бы было сделано снизу. И так далее и тому подобное.
К тому же ни в коем случае не стоит считать написанное мною наездами на СПФ.
Пока хватит


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: словари
СообщениеДобавлено: Вс мар 27, 2011 03:17 
Не в сети
Аватара пользователя

Зарегистрирован: Ср фев 23, 2011 20:42
Сообщения: 600
Откуда: Карелия
Благодарил (а): 3 раз.
Поблагодарили: 24 раз.
Сейчас читал стандарт Forth-79 и понял, что не понимал раньше как работают
словари. Точнее как мыслилась их работа в старых стандартах.
Вижу, также, что не понимал этого не только я один.
В своем Форте я реализовал все так, как понял по Баранову и Ноздрунову
и у меня все получилось удобно и логично.
Но в старых стандартах написано совсем совсем не то, что я сделал :cry:
Вот, что пока обнаружил :

Из стандарта Forth-79 из описания слова : "colon"
Select the CONTEXT vocabulary to be identical to CURRENT.

Из определения слова : "colon" в FIG-Forth :
Код:
      DW   CURR,   AT
      DW   CONT,   STORE
, т.е.
CURRENT @ CONTEXT !

Из стандарта Forth-83 из описания слова : "colon"
The search order is changed so that the first vocabulary in the search order is
replaced by the compilation vocabulary. The compilation vocabulary is unchanged.


Так-что вот это
mOleg писал(а):
Изначально форт умел работать только с двумя словарями,
один словарь находился в переменной context другой в переменной current - в первом словаре велся поиск во второй производилась компиляция слов. Таким образом откомпилированные слова не всегда могли быть найдены.
неправильно. Скомпилированные слова всегда будут найдены, поскольку
само слово : "colon" во всех 3-х старых стандартах cделает current контекстом.

Но, обнаружив такую вещь я оказался в полных непонятках.
Получается, что нельзя определять слово в одном словаре в контексте другого
словаря ? Но если так, то словари тогда теряют половину смысла.
Или как-то можно ? Как мыслилась работа с разными словарями в старых
стандартах при определении новых слов ?

Предположим, что у меня есть словарь FLOAT в котором плавающее сложение +
и вычитание - . И я хочу добавить слово к словарю FORTH и при этом
использовать плавающий + . Как мне это сделать ?
Пока в голову только такое пришло.
: SHIT ... [ FLOAT ] + [ FORTH ] ... ;
Т.е. переключение словарей уже внутри определения перепрыгиванием
из режима компиляции в режим интерпретации и обратно.
Это что - мыслилась такая работа со словарями ?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 61 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB