Forth :: Просмотр темы - Варианты словарей и словарных статей

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

У-у-у-у-у! Консерваторы!

У меня вопрос - зачем много словарей?

Пущай только "инноваторы" напишут игрушку на Форте с применением предлагаемой передовой технологии.

гм, а что такой подход даст?
и чем не устраивает современный "контекст словарей" (стек хранящий список активных словарей?)

А не надоело словарь forth превращать в свалку? Туда же "пихается" все подряд. По мне лучше разделять "темы" на разные словари. Например если я знаю что словарь console содержит код для работы с консолью, а мне консоль не нужна, то я просто не буду изучать слова принадлежащие этому словарю.

Наличие большого количества словарей по большому счету ничего кроме усложнения транслятора не дает, а значит просто ухудшает характеристики транслятора и затрудняет его использование. Да и разделение слов на "темы" во многом искусственно.

Вот я и прошу помочь своими советами скорректировать мою идею, где то что то интересней предложить, что то "отмести" ненужное.

ЗЫ. А игрулю я тебе напишу на СПФ, под консоль пойдет? Или подождете пока я "добъю" граф консоль, там проблемы с вычислением участка обновления окна (просто вставить код расчета, но вот руки-крюки ленью заплыли), мусор иногда на других окнах остается.

Какое же тут усложнение? Помоему наоборот облегчает поиск, а значит увеличивает характеристики транслятора. Что быстрей найти слово в словаре из 10000 имен или найти словарь из 100 существующих и в нем слово из 100 имеющихся?

Где постановка задачи и выводы? Вижу только идею, которая может быть как блестящей, так и провальной, в зависимости от того, что именно она призвана изменить.

... и в других вариантах - скажем, я в кварке предпочитаю статическое наследование словарей (при этом их количество неограничено).

А "словарь словарей" открывает дорогу к "словарю словарей словарей" и далее, что, видимо, и вызывает вопросы.

Хищник писал(а):

... и в других вариантах - скажем, я в кварке предпочитаю статическое наследование словарей (при этом их количество неограничено).

А можно по подробней о этом где то почитать?

Автор:	Pretorian [ Пн сен 08, 2008 06:42 ]
Заголовок сообщения:	Варианты словарей и словарных статей
Хотелось бы поэксперементировать с разными вариантами форматов словарей и словарных статей. Для начала выскажу свою идею, но хотелось бы и другие идеи услышать или развить мою. Идея связанна с тем что в любой момент можно иметь сколько угодно доступных словарей, а так же словари могут совпадать по имени со словарными статьями, а так же словарные статьи из разных словарей могут совпадать по имени, это не должно иметь коолизий. Обращение <слово> доступно только для словаря в контексте, для остальных слов доступ к словам осуществляется ~ <словарь> <слово>. Данный метод позволяет иметь хоть сколько доступных словарей без их учета в отдельной памяти. Поля словарной статьи --------------------- NFA - адрес поля имени LFA - адрес поля связи CFA - адрес поля параметров (кода) PFA - адрес параметров (кода) FPA - флаг вида словарной статьи Структура словарной статьи ┌────────────────────────────────────┐ CFA │ 00 - адрес начала кода │ ├────────────────────────────────────┤ FPA │ 05 - поле признаков слова │ ├────────────────────────────────────┤ LFA │ 06 - адрес связи │ ├────────────────────────────────────┤ NFA │ 0A - длинна имени словарной статьи │ ├────────────────────────────────────┤ │ 0B - имя словарной статьи (LEN) │ ├────────────────────────────────────┤ PFA │ 0B+LEN/16/ - программный код │ └────────────────────────────────────┘ Структура словаря ┌────────────────────────────────────┐ CFA │ 00 = 0 │ ├────────────────────────────────────┤ FPA │ 05 = 0 │ ├────────────────────────────────────┤ LFA │ 06 - адрес связи │ ├────────────────────────────────────┤ NFA │ 0A - длинна имени словарной статьи │ ├────────────────────────────────────┤ │ 0B - имя словарной статьи (LEN) │ └────────────────────────────────────┘ Структура словаря словарей ┌────────────────────────────────────┐ CFA │ 00 = 0 │ ├────────────────────────────────────┤ FPA │ 05 = 0 │ ├────────────────────────────────────┤ LFA │ 06 = 0 │ ├────────────────────────────────────┤ NFA │ 0A - длинна имени словарной статьи │ ├────────────────────────────────────┤ │ 0B - имя словарной статьи (LEN) │ └────────────────────────────────────┘ Словарь: 1. Имеется словарь словарей который содержит все словари в кипе (словарь словарей схож по своей структуре с словарными словами в словаре). 2. Имеется один словарь в контексте к словам которого обращаются простым набором слова (CONTEXT). 3. При обращении к слову через указание словаря слово ищется в конкретном словаре из кипы. (данный метод расчитан для повтора имени слов в различных словарях). Словарь словарей: ┌───────────────┐ │ MAIN │<──┐ └───────────────┘ │ ┌────────────────┐ │ │ FORTH ├─┤ └────────────────┘ │ ... ──┤ ┌────────────────┐ │ │ ... ├─┘ └────────────────┘ Словарь: ┌───────────────┐ │ FORTH │<───┐ └───────────────┘ │ │ SWAP ──┤ │ ... ──┤ │ ... ──┘ 4. В словаре словарей хранится LFA последнего словаря. 5. В словаре хранится LFA последней созданной для словаря статьи. 6. При поиске в текущем словаре берется LFA последней словарной статьи и происходит поиск нужного слова до вершины словаря. 7. При поиске статьи в конкретном словаре ищется словарь, затем внем слово по принципу пункта 6. 8. Добавлять слова можно только в текущий словарь для компиляции (CURRENT). CFA = 0 и LFA = 0 - словарь словарей; CFA = 0 и LFA = n - словарь; CFA = n и LFA = n - словарная статья;

Автор:	chess [ Пн сен 08, 2008 17:28 ]
Заголовок сообщения:
Pretorian писал(а): Идея связанна с тем что в любой момент можно иметь сколько угодно доступных словарей, а так же словари могут совпадать по имени со словарными статьями, а так же словарные статьи из разных словарей могут совпадать по имени, это не должно иметь коолизий. У меня вопрос - зачем много словарей? По мне так хватило бы одного - так проще. Пространство имен каждой программы может быть и так неограниченно большим. Имена могут быть также и в куче, а ненужные(уже отработавшие в этой программе на этапе компиляции) могут затем удаляться.

Автор:	in4 [ Пн сен 08, 2008 18:54 ]
Заголовок сообщения:
А лучше - 2 словаря - forth и macro - так еще проще. И убрать STATE-зависимые слова. Но это уже ColorForth получается с его стилем программирования. И использованием его возможностей - сохранением общей кучи (кодофайла) и периодической очисткой основных словарей. С учетом прекомпилированных исходников и соответственно очень высокой скоростью компиляции - разумное решение. Правда, игнорируемое основным сообществом - это ведь совершенно другой язык... Хоть и Форт!

Автор:	mOleg [ Пн сен 08, 2008 21:02 ]
Заголовок сообщения:
гм, а что такой подход даст? и чем не устраивает современный "контекст словарей" (стек хранящий список активных словарей?)

Автор:	Kamikaze [ Пн сен 08, 2008 21:27 ]
Заголовок сообщения:
У-у-у-у-у! Консерваторы!

Forth http://fforum.winglion.ru/

Варианты словарей и словарных статей http://fforum.winglion.ru/viewtopic.php?f=9&t=1495	Страница 1 из 4

Автор:	вопрос [ Пн сен 08, 2008 21:51 ]
Заголовок сообщения:
А вообще ColorForth это прогресс? Где тут была по нему тема?

Автор:	Hishnik [ Пн сен 08, 2008 22:22 ]
Заголовок сообщения:
Kamikaze писал(а): У-у-у-у-у! Консерваторы! Ххе, да не вопрос - поддержу любое начинание. Пущай только "инноваторы" напишут игрушку на Форте с применением предлагаемой передовой технологии.

Автор:	Pretorian [ Вт сен 09, 2008 05:52 ]
Заголовок сообщения:
chess писал(а): У меня вопрос - зачем много словарей? А не надоело словарь forth превращать в свалку? Туда же "пихается" все подряд. По мне лучше разделять "темы" на разные словари. Например если я знаю что словарь console содержит код для работы с консолью, а мне консоль не нужна, то я просто не буду изучать слова принадлежащие этому словарю. В настоящее время в SPF есть словарь FORTH, и попробуй определи какие слова нужны для разбора, а какие нет, приходится каждое брать и смотреть, а потом анализировать нужно оно мне или о нем в текущий момент просто можно забыть, вот и попробуй самостоятельно найти то в кратчайшие сроки что нужно. Вобще Форт за несколько десятков лет застоялся без развития и новаций (слишком их было мало).

Автор:	Pretorian [ Вт сен 09, 2008 05:59 ]
Заголовок сообщения:
Хищник писал(а): Пущай только "инноваторы" напишут игрушку на Форте с применением предлагаемой передовой технологии. Вот я и прошу помочь своими советами скорректировать мою идею, где то что то интересней предложить, что то "отмести" ненужное. ЗЫ. А игрулю я тебе напишу на СПФ, под консоль пойдет? Или подождете пока я "добъю" граф консоль, там проблемы с вычислением участка обновления окна (просто вставить код расчета, но вот руки-крюки ленью заплыли), мусор иногда на других окнах остается.

Автор:	Pretorian [ Вт сен 09, 2008 06:04 ]
Заголовок сообщения:
mOleg писал(а): гм, а что такой подход даст? и чем не устраивает современный "контекст словарей" (стек хранящий список активных словарей?) То, что вот именно что нужен стек. А если словари не активные, где их хранить, ага, нужен именной участок памяти, доп. слова для мусора. Да и стек не безмерный же.

Автор:	chess [ Вт сен 09, 2008 07:10 ]
Заголовок сообщения:
Pretorian писал(а): А не надоело словарь forth превращать в свалку? Туда же "пихается" все подряд. По мне лучше разделять "темы" на разные словари. Например если я знаю что словарь console содержит код для работы с консолью, а мне консоль не нужна, то я просто не буду изучать слова принадлежащие этому словарю. Это вопрос изучения-обучения-субъективный вопрос и к организации форт-системы имеет третьестепенное отношение. Наличие большого количества словарей по большому счету ничего кроме усложнения транслятора не дает, а значит просто ухудшает характеристики транслятора и затрудняет его использование. Да и разделение слов на "темы" во многом искусственно. Один и тот же код может эффективно работать в разных "темах". Наличие только одного пространства имен не противоречит принципу - каждому имени свой код исполнения. При отсутствии одинаковых имен для разных кодов проблема управления областью видимости для имен решается сама собой.

Автор:	Pretorian [ Вт сен 09, 2008 07:39 ]
Заголовок сообщения:
chess писал(а): Наличие большого количества словарей по большому счету ничего кроме усложнения транслятора не дает, а значит просто ухудшает характеристики транслятора и затрудняет его использование. Да и разделение слов на "темы" во многом искусственно. Какое же тут усложнение? Помоему наоборот облегчает поиск, а значит увеличивает характеристики транслятора. Что быстрей найти слово в словаре из 10000 имен или найти словарь из 100 существующих и в нем слово из 100 имеющихся? Ну а разделение слов на темы, это удобство разработчика ведь, скажем слово ОТКРЫТЬ может быть применено не только для файла, а для других ситуаций. Может как раз "непопулярность" Форта в его свалке слов? Почему бы форту не эволюционировать? Я больше чем уверен, можно много чего придумать еще и это не будет идти в разрез с идеей Форт.

Автор:	Hishnik [ Вт сен 09, 2008 09:46 ]
Заголовок сообщения:
Pretorian писал(а): Вот я и прошу помочь своими советами скорректировать мою идею, где то что то интересней предложить, что то "отмести" ненужное. А что за идея-то? Где постановка задачи и выводы? Вижу только идею, которая может быть как блестящей, так и провальной, в зависимости от того, что именно она призвана изменить. И постановка должна быть не умозрительной, а практической - делали пять проектов, в одном попробовали так - сразу стало быстрее писаться и удобнее отлаживаться. Pretorian писал(а): ЗЫ. А игрулю я тебе напишу на СПФ, под консоль пойдет? Или подождете пока я "добъю" граф консоль, там проблемы с вычислением участка обновления окна (просто вставить код расчета, но вот руки-крюки ленью заплыли), мусор иногда на других окнах остается. Вот-вот... "ленью заплыли" Pretorian писал(а): Какое же тут усложнение? Помоему наоборот облегчает поиск, а значит увеличивает характеристики транслятора. Что быстрей найти слово в словаре из 10000 имен или найти словарь из 100 существующих и в нем слово из 100 имеющихся? Ну это нормальный подход, но ведь контекстные словари есть и в ANS, с изменяемым порядком просмотра, и в других вариантах - скажем, я в кварке предпочитаю статическое наследование словарей (при этом их количество неограничено). А "словарь словарей" открывает дорогу к "словарю словарей словарей" и далее, что, видимо, и вызывает вопросы.

Автор:	Pretorian [ Вт сен 09, 2008 10:34 ]
Заголовок сообщения:
Хищник писал(а): Где постановка задачи и выводы? Вижу только идею, которая может быть как блестящей, так и провальной, в зависимости от того, что именно она призвана изменить. Ну хочется чего то нового и что бы не расходилось с идеей Форт. Задачу нужно еще самому понять, пока только идеи от всех у кого есть идеи. Хищник писал(а): ... и в других вариантах - скажем, я в кварке предпочитаю статическое наследование словарей (при этом их количество неограничено). А можно по подробней о этом где то почитать? Хищник писал(а): А "словарь словарей" открывает дорогу к "словарю словарей словарей" и далее, что, видимо, и вызывает вопросы. Если приглядется, то нет ни какого словаря словарей это просто адрес хранящий последний словарь. Идея только заключается в любом количестве словарей, что бы скажем доступ был не только с контекста (ну понятно что оно по любому будет ставится в контекст при поиске), да в том что бы в разных словарях имена статей могли совпадать. Надоело писать ConsoleOpen, FileOpen, WinOpen и т.д. Структура словаря ┌────────────────────────────────────┐ CFA │ 00 = адрес связи со словами │ ├────────────────────────────────────┤ FPA │ 05 = 0 │ ├────────────────────────────────────┤ LFA │ 06 - адрес связи со словарями │ ├────────────────────────────────────┤ NFA │ 0A - длинна имени словарной статьи │ ├────────────────────────────────────┤ │ 0B - имя словарной статьи (LEN) │ └────────────────────────────────────┘

Автор:	Hishnik [ Вт сен 09, 2008 11:22 ]
Заголовок сообщения:
Pretorian писал(а): Хищник писал(а): ... и в других вариантах - скажем, я в кварке предпочитаю статическое наследование словарей (при этом их количество неограничено). А можно по подробней о этом где то почитать? Как работать - есть в документации на кварк. Вкратце, оставлен порядок работы с VOCABULARY и DEFINITIONS. Словарь - это обычное слово, с установленным флажком vocabulary, у которого в LFA вписан не указатель на LFA предыдущего слова, а указатель на точку входа в словарь-родитель. Таким образом, для перехода дальше надо сделать не @, а @ @ (сначала получаем адрес переменной, хранящей последнее LFA родителя, потом получаем LFA оттуда). Флаг vocabulary и сообщает интерпретатору, что надо сделать двойное разыменование. К словарям, таким образом, применимы ровно те же ограничения, что и к словарным статьям - они могут добавляться, пока не кончится память. Никаких дополнительных накладных расходов вроде поддержания списка словарей нет - они встроены в единственный список поиска. Структура наследования при этом получается статическая - каждый словарь создан в контексте словаря-родителя. В принципе, с помощью хаков можно эту структуру поменять (вписать указатель на другой словарь), но на практике я ни разу такого не видел. В прикладном программирование так даже проще, потому что никому же не приходит в голову пересоздавать иерархию классов в VCL, причем каждый раз при упоминании каждого объекта?

Страница 1 из 4	Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/