Forth http://fforum.winglion.ru/ |
|
RuF09: Словари http://fforum.winglion.ru/viewtopic.php?f=36&t=1851 |
Страница 1 из 4 |
Автор: | WingLion [ Вс янв 04, 2009 21:44 ] |
Заголовок сообщения: | RuF09: Словари |
Помнится в F83 ограничений на словари не было, не считая тех, что связаны с ограничением на реальный объем форт-систем. В F94 возникло что-то непонятное со словарями, в чем я (честно!) так и не разобрался. (В причинах подобного поворота, а не в словарях!) А по сему, есть предложение вернуть все назад, убрать все ограничения, сделать возможность использовать одновременно сколь угодное количество словарей (сколько в память влезет) и продумать здесь, как с ними работать по новому. Не с линейным ограниченным списком, а, как минимум, с разветвленным деревом словарей, зависимых и независимых друг от друга. Скажем, для примера имеем такую структуру словарей (не все, но часть): Код: FORTH
+-------------+----------+-----------------------+ STRINGS FILE-System | | +-------------+--------------+------ +------------+-------+ | | | FS.FAT16 FS.FAT32 FS.NTFS STR.BYTE STR.WORD STR.DWORD работать приходится одновременно с несколькими, соответственно, должен быть некий механизм параллельной работы независимых словарей и механизм их подключения. Стек словарей в этом контексте вполне подходит. Манипуляции на стеке словарей меняют пути поиска, но не меняют структуры форт-системы и самих словарей. Деревообразная структура требует, чтобы в корневых узлах были ссылки на все ветви, т.е. STRINGS должен ссылаться на все возможные варианты строк, FILE-System - на все варианты способов хранения данных. Стандартный сцепленный список слов в этом случае вполне подойдет, и тогда корневое слово фактически оказывается словом, имеющим два поля связи - одно, указывающее на цепочку, в которую оно само входит, второе - указание на цепочку словарей верхнего уровня. Структура получается ровно такая, как в F83, только для поиска нужно иметь стек словарей, который не должен иметь ограничений на объем, но должен иметь несколько иные свойства чем обычный стек данных или возвратов. Во первых, в стеке словарей все элементы равноправны (почти). Поиск начинается со словаря, на который указывает верхний элемент, если поиск неудачем, происходит переход на следующий словарь и так далее, пока словно будет не найдено или не исчерпается стек словарей (стек при этом не опустошается!) Специальные слова могут только производить некие перестановки/очистку/заполнение стека, без каких-либо операций (словари нельзя складывать и вычитать!) Для того, чтобы программисту не задумываться каждый раз, какие словари он подключил, а какие забыл, надо вводить специальные слова с копиями состояния стека словарей, которые при своем исполнении затирают весь стек и заполняют его новыми ссылками. Так же должны быть быть и слова добавления в стек словарей, умеющие добавлять не только один словарь, а целые группы. Возможно, я не все сказал, что-то напутал или что-то забыл. Прошу комментировать. |
Автор: | вопрос [ Вс янв 04, 2009 23:26 ] |
Заголовок сообщения: | |
почему стек словарей, если на рисунке дерево? "дерево словарей" |
Автор: | WingLion [ Вс янв 04, 2009 23:44 ] |
Заголовок сообщения: | |
Стек словарей для порядка поиска, а дерево словарей - структура их хранения. |
Автор: | mOleg [ Пн янв 05, 2009 21:07 ] |
Заголовок сообщения: | |
мне кажется, что данная тема преждевременно поднята. Словари достаточно высокоуровневая абстракция, чтобы ее оставить на потом, а сначала разобраться с разными моделями памяти, шитого кода, методик хранения данных, методов передачи управления и пр. |
Автор: | WingLion [ Вт янв 06, 2009 00:04 ] |
Заголовок сообщения: | |
А в моделях памяти, шитого кода и т.д. и т.п. за последнее время произошел какой-нибудь кардинальный сдвиг, что их надо пренепременно менять? Сдвиг произошел большей частью в более высокоуровневых частях языков. Потому их и надо рассматривать в первую очередь. А именно, способы подключения к Форту новых возможностей компьютеров и минимизации усилий для их интеграции в язык. А для этого и нужны словари. Если же это дело не продумать с самого начала, завтра окажется, что для подключения словарей/библиотек/чертовых-стульев надо всю основу перелопачивать, потому что не хватает двух гаек, без которых все рассыпается на первом повороте. |
Автор: | chess [ Ср янв 07, 2009 13:44 ] |
Заголовок сообщения: | |
WingLion писал(а): А для этого и нужны словари.
Пусть в словаре VOC1 есть WORD1, и в словаре VOC2 есть WORD1. Eсли писать VOC1.WORD1 VOC2.WORD1 то достаточно одного словаря. Разница получается в количество символов слов(оно стало больше). Наличие большого количества словарей в подавляющем большинстве случаев это дань более компактному представлению исходников. Работает механизм умолчаний, для поддержки которого появляется, например, стек контекста. В конечном итоге все это приводит к усложнению транслятора и как следствие(из-за разных реализаций форт-систем) к ограничению выразительных возможностей форта по причине соблюдения совместимости. |
Автор: | mOleg [ Ср янв 07, 2009 19:20 ] |
Заголовок сообщения: | |
chess писал(а): Пусть в словаре VOC1 есть WORD1, и в словаре VOC2 есть WORD1. Eсли писать VOC1.WORD1 VOC2.WORD1 то достаточно одного словаря. формально это так, в реальности замучишься писать FORTH.OVER FORTH.+ FORTH.SWAP ) с другой стороны ведь не всегда определено, где должно находиться слово!!! то есть контекст еще позволяет делать выбор, откуда брать слово. chess писал(а): Наличие большого количества словарей в подавляющем большинстве случаев это дань более компактному представлению исходников. не согласен. Словари используются для другого. В конце концов мог бы быть вообще один словарь (так бывает), только не удобно. chess писал(а): Работает механизм умолчаний, для поддержки которого появляется, например, стек контекста. В конечном итоге все это приводит к усложнению транслятора и как следствие(из-за разных реализаций форт-систем) к ограничению выразительных возможностей форта
по причине соблюдения совместимости. а вот это уже совсем не понятно, а что понятно не верно. Усложнение транслятора не происходит (усложнение FIND и самих словарей да, но не транслятора, который всегда очень прост). О каких ограничениях идет речь тоже совсем не понятно. |
Автор: | chess [ Ср янв 07, 2009 22:09 ] |
Заголовок сообщения: | |
mOleg писал(а): формально это так, в реальности замучишься писать FORTH.OVER FORTH.+ FORTH.SWAP Looool) Никто не предлагает так писать. Просто одного словаря(кодо-хранилища) достаточно. Имена слов(кодов) вторичны, сами коды слов - первичны. mOleg писал(а): с другой стороны ведь не всегда определено, где должно находиться слово!!! то есть контекст еще позволяет делать выбор, откуда брать слово. Под контекстом в форте понимается только порядок поиска. Если нет слов с одинаковыми именами, то порядок поиска теряет смысл. mOleg писал(а): а вот это уже совсем не понятно, а что понятно не верно.
Усложнение транслятора не происходит (усложнение FIND и самих словарей да, но не транслятора, который всегда очень прост). Я говорю не о цикле INTERPRET, а трансляторе, в который входят кроме INTERPRET еще структуры данных в виде кодо-хранилища и стеков. Механизм умолчаний - дело ненадежное, требующее очень тщательной проработки вариантов реализации транслятора. Нужно все делать явно/однозначно. Число это не слово, макрос это не слово. Слово немедленного исполнения это не обычное слово. Все проще задавать явно. |
Автор: | mOleg [ Ср янв 07, 2009 23:06 ] |
Заголовок сообщения: | |
chess писал(а): mOleg писал(а):формально это так, в реальности замучишься писать FORTH.OVER FORTH.+ FORTH.SWAP Looool) Никто не предлагает так писать. Просто одного словаря(кодо-хранилища) достаточно. Имена слов(кодов) вторичны, сами коды слов - первичны. не всегда. Бывает что само имя первично (то есть кроме имени ничего и нет). chess писал(а): mOleg писал(а):с другой стороны ведь не всегда определено, где должно находиться слово!!! то есть контекст еще позволяет делать выбор, откуда брать слово. Под контекстом в форте понимается только порядок поиска. Если нет слов с одинаковыми именами, то порядок поиска теряет смысл. нет, не теряет! бывает необходимо ограничить видимость слов, кстати именно эта фукнциональность словаря первична. chess писал(а): mOleg писал(а):а вот это уже совсем не понятно, а что понятно не верно.
Усложнение транслятора не происходит (усложнение FIND и самих словарей да, но не транслятора, который всегда очень прост). Я говорю не о цикле INTERPRET, а трансляторе, в который входят кроме INTERPRET еще структуры данных в виде кодо-хранилища и стеков. Механизм умолчаний - дело ненадежное, требующее очень тщательной проработки вариантов реализации транслятора. Нужно все делать явно/однозначно. Число это не слово, макрос это не слово. Слово немедленного исполнения это не обычное слово. Все проще задавать явно. Если ты говоришь не о цикле INTERPRET, то ты уже не о трансляторе говоришь Транслятору до того, где как и что делает слово до одного места. Дело в том, что и число слово и макрос слово (иначе вы не о форте говорите). |
Автор: | chess [ Чт янв 08, 2009 08:33 ] |
Заголовок сообщения: | |
mOleg писал(а): нет, не теряет! бывает необходимо ограничить видимость слов, кстати именно эта фукнциональность словаря первична. Чтобы не быть голословным приведи пример когда без совпадающих по имени слов это надо. mOleg писал(а): не всегда. Бывает что само имя первично (то есть кроме имени ничего и нет). Это очень отдельный случай. mOleg писал(а): Если ты говоришь не о цикле INTERPRET, то ты уже не о трансляторе говоришь Wink Транслятор шире чем INTERPRET, в нем заложена доп. информация из словаря. mOleg писал(а): Дело в том, что и число слово и макрос слово (иначе вы не о форте говорите).
Это далеко не так. |
Автор: | mOleg [ Чт янв 08, 2009 20:27 ] |
Заголовок сообщения: | |
chess писал(а): mOleg писал(а):нет, не теряет! бывает необходимо ограничить видимость слов, кстати именно эта фукнциональность словаря первична. Чтобы не быть голословным приведи пример когда без совпадающих по имени слов это надо. сколько угодно смотри в devel\~moleg\lib\struct\struct.f , и примеры с описанием, или, как вариант http://fforum.winglion.ru/viewtopic.php?p=18529#18529 и если покопаться много еще чего. Тут ведь вопрос лишь в том, на сколько ты широко используешь возможности. chess писал(а): mOleg писал(а):не всегда. Бывает что само имя первично (то есть кроме имени ничего и нет). Это очень отдельный случай. да, но факт в том, что бывает и такое chess писал(а): mOleg писал(а):Дело в том, что и число слово и макрос слово (иначе вы не о форте говорите).
Это далеко не так._________________ интересно, а как же тогда? |
Автор: | chess [ Вс янв 11, 2009 16:31 ] |
Заголовок сообщения: | |
mOleg писал(а): Тут ведь вопрос лишь в том, на сколько ты широко используешь возможности. Тут вопрос как раз в том, можно ли сделать не сложнее, а проще, в рамках только одного кодохранилища(словаря) чем при нескольких словарях. mOleg писал(а): да, но факт в том, что бывает и такое Вопрос опять в том, что вот без "этого бывает" можно без хлопот обойтись, ничего при этом не потеряв, а наоборот упростив форт-систему. mOleg писал(а): интересно, а как же тогда?
Чтобы числа(строковые литералы особого вида в исходнике) стали словами(имели свойства слов) нужно сделать что-то типа: Код: : 123 123 ; или, что практически тоже самое, превратить их в константы с именами равными, например, самим лексемам этих чисел: Код: : $ NextWord 2DUP 0 0 2SWAP >NUMBER 2DROP DROP -ROT SHEADER ['] _CONSTANT-CODE COMPILE, , ; $ 123456 STARTLOG SEE 123456 CR ' 123456 EXECUTE лог Код: CODE 123456 (8 bytes)
572643 E8F4F9FDFF CALL 55203C ( _CONSTANT-CODE ) 572648 A; 1E240 , Ok ( 123456 ) Хотя это только иллюстрация, но и реально в программах бывает небольшое количество числовых литералов и их можно превратить в слова(константы), но это должен делать транслятор на автомате. В этом есть некоторые сложности с существующей концепцией организации словаря - для генерации слов-чисел, внутри, например, определений через двоеточие - существующая организация словаря не годится. Макросы(исполняемые строковые литералы) позволяют формировать исходник(структурировать текст) с гораздо меньшими ограничениями, чем это можно сделать с помощью обычных слов, что во многом упрощает кодирование (доп. возможности появляются из-за более позднего связывания имен с кодом). Но возможности интерактивной отладки макросов значительно уже чем у обычных форт-слов. Так что общего у слов, чисел и макросов только то, что для транслятора в исходнике они все лексемы. |
Автор: | WingLion [ Вс янв 11, 2009 18:15 ] |
Заголовок сообщения: | |
такое ощущение, что тема ушла в некую дикую частность, не относящуюся к реальному топику. |
Автор: | mOleg [ Вс янв 11, 2009 19:12 ] |
Заголовок сообщения: | |
chess писал(а): mOleg писал(а):Тут ведь вопрос лишь в том, на сколько ты широко используешь возможности. Тут вопрос как раз в том, можно ли сделать не сложнее, а проще, в рамках только одного кодохранилища(словаря) чем при нескольких словарях. вот даже не знаю как ответить на это утверждение. Просто удобно ограничивать набор слов (пускай даже уникальных) изолируя их в отдельные словари. Куча же слов в одном словаре всегда напрягает (это и медленно, и неудобно), это конечно же, имхо. Вот мне удобно во время написания чего бы то ни было (от двух слов и выше) делать это в отдельном словаре. chess писал(а): mOleg писал(а):да, но факт в том, что бывает и такое
Вопрос опять в том, что вот без "этого бывает" можно без хлопот обойтись, ничего при этом не потеряв, а наоборот упростив форт-систему. смысл не упрощении, а в компромиссе между простотой и удобством. Кстати, вот я приводил в пример свою библиотечку поддежки структур. Основное свойство которой удобное управление словарями. И там же лежат примеры описания устройств (нескольких микросхем с командами и регистрами) Можно было бы это в один словарь определить, но дико же неудобно (я ведь с этого и начинал! ) Мне более по душе писать: 82C45 CTL Chanel0 Mode2 Both 82C54 FirstChanel CLC - при этом еще есть и контроль того, что я делаю. Без словарей это получится неудобнее. |
Автор: | mOleg [ Вс янв 11, 2009 19:18 ] |
Заголовок сообщения: | |
chess писал(а): mOleg писал(а):интересно, а как же тогда? Чтобы числа(строковые литералы особого вида в исходнике) стали словами(имели свойства слов) нужно сделать что-то типа: Код:: 123 123 ; либо посмотреть в форк где они де факто все являются словами! и распознают числа словари. chess писал(а): Макросы(исполняемые строковые литералы) позволяют формировать исходник(структурировать текст) с гораздо
меньшими ограничениями, чем это можно сделать с помощью обычных слов, что во многом упрощает кодирование (доп. возможности появляются из-за более позднего связывания имен с кодом). Но возможности интерактивной отладки макросов значительно уже чем у обычных форт-слов. Так что общего у слов, чисел и макросов только то, что для транслятора в исходнике они все лексемы. все что вы пишете понятно, хотя это скорее ваша личная проблема (я не испытываю проблем с макросами). Тем не менее любое слово в форте остается словом и находится в словаре (даже если словарь подразумевается, и слов поддержки нет), причем и сам словарь является словом. |
Страница 1 из 4 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |