это еще чего, вот появилась мысля каждый файл в отдельный словарь упихивать.
решил попробовать... вот:
<pre>
\ 21.10.2009 ~mOleg
\ Сopyright [C] 2009 mOleg
mininoleg@yahoo.com
\ сложное поведение контекста при транслировании источников...
vocs/ vocab.fts
vocs/ shadow.fts
string/ add.fts
util/ order.fts
ALSO ROOT DEFINITIONS
VOCABULARY LIBR \ словарь, в котором будут создаваться словари с именами либ
HIDDEN DEFINITIONS
\ действия при входе в каждый источник
: ent ( --> )
SAVE-ORDER
ALSO LIBR DEFINITIONS
SOURCE-NAME SelFName SVOCAB DROP
VOC-LIST A@ MOUNT
DEFINITIONS ;
\ действия при выходе из каждого источника
: ext ( --> )
RESTORE-ORDER
\ CR ~CONTEXT \ если хочется видеть контекст поиска для каждого источника
DEFINITIONS ;
\ действия выполняемые по требованию lib/ name.fts
: aus ( asc # --> asc # )
lFrame>
\ DDUP TYPE SPACE \ если хочется видеть "требуемые" библиотеки, раскоментировать
FINDVOC *IF
\ тут можно проверять, есть ли уже данный словарь в контексте и если он там
\ уже упомянут, извлекать его из глубины контекста наверх
\ это может дать ускорение поиска по словарям
ALSO WITH UNDER ;THEN
DROP
\ ERROR" Нет такого словаря!"
;
' ent IS ON-SOURCE-START ' ext IS ON-SOURCE-EXIT
' aus IS ON-LIB-NAME
RECENT SAVE-ORDER
\? а как быть с одноименными либами-то? требовать чтобы имена библиотек были уникальны?
\EOF
теперь, можно попробовать из консоли набрать, к примеру:
list/ namespace.fts
в LIBR будет список подключенных библиотек, в виде списка словарей
внутри каждого словаря находятся список слов, которые определены в файлах.
</pre>
Вобщем идея в стиле Си, когда область видимости имен ограничена файлом.
То есть содержимое файла по умолчанию образует собственную область видимости (словарь)
Дальше внутри подключаемого файла должны перечисляться требуемые библиотеки,
точнее ссылки на них в виде lib/ name.fts . Они определяют "наследование" других
пространств имен. То есть попросту эти библиотеки (если еще не подключены - подключаются
в собственные словари) оказываются в контексте под верхним (то есть текущим словарем).
В процессе трансляции источников (файлов) для каждого в контексте находится
"требуемый" список словарей.
\! 18.10.2009 идея
возможно есть смысл задавать порядок поиска в подключаемых библиотеках, впрочем,
это достаточно сложный вопрос. Но основная идея в том, что каждая либа может находиться
в собственном словаре. При подключении имен в виде lib/ name.fts на вершину
контекста выкладывать словари в указанном порядке, а после подключения библиотеки,
когда заканчивается файловый поток, делать откат контекста (убирать эти словари из
контекста, однако, нельзя при этом затрагивать другие изменения контекста!).
Интересно, что при этом не нужно выдумывать сложный синтаксис типа voc::name или
что-то подобное. Но контроль имен будет достаточно жесткий. Впрочем, такой подход
будет требовать скорее всего сильной смены "парадигмы", в любом случае со словарями
будет уже несколько меньше ручной работы (точнее она должна будет быть более осторожной).
Вобщем, можно даже пощупать. Ценность данного "изобретения" на мой взгляд сомнительна, однако она добавила два новых полезных вектора в процесс трансляции: ON-SOURCE-START и ON-SOURCE-EXIT , на которые у меня имеются другие планы
это еще чего, вот появилась мысля каждый файл в отдельный словарь упихивать.
решил попробовать... вот:
<pre>
\ 21.10.2009 ~mOleg
\ Сopyright [C] 2009 mOleg mininoleg@yahoo.com
\ сложное поведение контекста при транслировании источников...
vocs/ vocab.fts
vocs/ shadow.fts
string/ add.fts
util/ order.fts
ALSO ROOT DEFINITIONS
VOCABULARY LIBR \ словарь, в котором будут создаваться словари с именами либ
HIDDEN DEFINITIONS
\ действия при входе в каждый источник
: ent ( --> )
SAVE-ORDER
ALSO LIBR DEFINITIONS
SOURCE-NAME SelFName SVOCAB DROP
VOC-LIST A@ MOUNT
DEFINITIONS ;
\ действия при выходе из каждого источника
: ext ( --> )
RESTORE-ORDER
\ CR ~CONTEXT \ если хочется видеть контекст поиска для каждого источника
DEFINITIONS ;
\ действия выполняемые по требованию lib/ name.fts
: aus ( asc # --> asc # )
lFrame>
\ DDUP TYPE SPACE \ если хочется видеть "требуемые" библиотеки, раскоментировать
FINDVOC *IF
\ тут можно проверять, есть ли уже данный словарь в контексте и если он там
\ уже упомянут, извлекать его из глубины контекста наверх
\ это может дать ускорение поиска по словарям
ALSO WITH UNDER ;THEN
DROP
\ ERROR" Нет такого словаря!"
;
' ent IS ON-SOURCE-START ' ext IS ON-SOURCE-EXIT
' aus IS ON-LIB-NAME
RECENT SAVE-ORDER
\? а как быть с одноименными либами-то? требовать чтобы имена библиотек были уникальны?
\EOF
теперь, можно попробовать из консоли набрать, к примеру:
list/ namespace.fts
в LIBR будет список подключенных библиотек, в виде списка словарей
внутри каждого словаря находятся список слов, которые определены в файлах.
</pre>
Вобщем идея в стиле Си, когда область видимости имен ограничена файлом.
То есть содержимое файла по умолчанию образует собственную область видимости (словарь)
Дальше внутри подключаемого файла должны перечисляться требуемые библиотеки,
точнее ссылки на них в виде lib/ name.fts . Они определяют "наследование" других
пространств имен. То есть попросту эти библиотеки (если еще не подключены - подключаются
в собственные словари) оказываются в контексте под верхним (то есть текущим словарем).
В процессе трансляции источников (файлов) для каждого в контексте находится
"требуемый" список словарей.
\! 18.10.2009 идея
возможно есть смысл задавать порядок поиска в подключаемых библиотеках, впрочем,
это достаточно сложный вопрос. Но основная идея в том, что каждая либа может находиться
в собственном словаре. При подключении имен в виде lib/ name.fts на вершину
контекста выкладывать словари в указанном порядке, а после подключения библиотеки,
когда заканчивается файловый поток, делать откат контекста (убирать эти словари из
контекста, однако, нельзя при этом затрагивать другие изменения контекста!).
Интересно, что при этом не нужно выдумывать сложный синтаксис типа voc::name или
что-то подобное. Но контроль имен будет достаточно жесткий. Впрочем, такой подход
будет требовать скорее всего сильной смены "парадигмы", в любом случае со словарями
будет уже несколько меньше ручной работы (точнее она должна будет быть более осторожной).
Вобщем, можно даже пощупать. Ценность данного "изобретения" на мой взгляд сомнительна, однако она добавила два новых полезных вектора в процесс трансляции: ON-SOURCE-START и ON-SOURCE-EXIT , на которые у меня имеются другие планы 8)