Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт окт 23, 2020 15:33

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 61 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Вт авг 01, 2006 23:49 
Не в сети

Зарегистрирован: Пт май 12, 2006 23:42
Сообщения: 300
Откуда: Kиев
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
oleg писал(а):
для слов, которые могут быть удалены но при этом могут использоваться либо производить длительну процедуру анализа( не хочется) либо оставлять слово-заглушку вызывающее ошибку при вызове слова,
А смысл их тогда вообще удалять?
oleg писал(а):
Вообще вариантов может быть много.
Вариантов - да, толковых решений - практически нет. Поэтому и удаляем (если сильно хочется) исполнимый код только с конца...


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

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5016
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 21 раз.
Поблагодарили: 58 раз.
ArtemKAD писал(а):
oleg писал(а):
для слов, которые могут быть удалены но при этом могут использоваться либо производить длительну процедуру анализа( не хочется) либо оставлять слово-заглушку вызывающее ошибку при вызове слова,
А смысл их тогда вообще удалять?

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

ArtemKAD писал(а):
Вообще вариантов может быть много.
Вариантов - да, толковых решений - практически нет. Поэтому и удаляем (если сильно хочется) исполнимый код только с конца...

Решение толковое есть. По крайней мере есть ощущение, что такое решение должно быть.
Выглядеть оно должно примерно так:

Каждый словарь знает, как проводить операции внутри себя.
К каждому словарю есть минимальный интерфейс, а так же возможность расширения интерфейса.
Поиск в самой системе ведется за счет вызова методов поиска по каждому из словарей.
Стек словарей ( контекст ) и текущий словарь остаются но малость модифицируются.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


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

Зарегистрирован: Пт май 12, 2006 23:42
Сообщения: 300
Откуда: Kиев
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
oleg писал(а):
Я, кажется, говорил не о удалении кода, а о создании более гибкоги интерфейса для работы со словарями.
Я хочу дать больше свободы словарям! В случае кода у нас ничего не изменится, а вот если работать с файловой системой, как со словарем, то уже нужно уметь удалять! Изменять, переименовывать.

Хм... Тогда скорее всего Вам прямой путь к варианту SPF 2.2 в котором пространство кода и пространство имен были разными. Тогда с заголовками слов можно вытворять все, что угодно (хоть БД вместо списка делать) не затрагивая исполнимую часть.
oleg писал(а):
Поиск в самой системе ведется за счет вызова методов поиска по каждому из словарей.
А что это даст? В любом случае поиск это сравнение с шаблоном в списке. Позволит менять формат списка - переходить от связанного списка к таблицам - а толку? Позволит искать во внешних источниках как в словаре? Но тогда появится куча вопросов, а что с этим найденым делать в исполнимом коде - как его в код компилировать или как его выполнять(не говоря уже о том, а насколько найденное эквивалентно обычным словам). Если это-бы был обычный словарь, то компилировалось и исполнялось слово-интерфейс (часть DOES> при создании слов в зеркале), а так еще надо сверху на словарную структуру накручивать кучу контекстно зависимых интерфейсов. Причем не факт, что их набора хватит "на все случаи жизни"...


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

Зарегистрирован: Чт май 04, 2006 18:18
Сообщения: 456
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
oleg писал(а):
Ну что ж. Никто не сказал о главном 8(
Попробую я обьяснить, что хотел бы от словарей.

~ac/lib/ns/*.f ? По-моему реализовано как раз то, про что Вы говорите..

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


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

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5016
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 21 раз.
Поблагодарили: 58 раз.
ArtemKAD писал(а):
oleg писал(а):
Я, кажется, говорил не о удалении кода, а о создании более гибкоги интерфейса для работы со словарями.
Я хочу дать больше свободы словарям! В случае кода у нас ничего не изменится, а вот если работать с файловой системой, как со словарем, то уже нужно уметь удалять! Изменять, переименовывать.

Хм... Тогда скорее всего Вам прямой путь к варианту SPF 2.2 в котором пространство кода и пространство имен были разными. Тогда с заголовками слов можно вытворять все, что угодно (хоть БД вместо списка делать) не затрагивая исполнимую часть.


Да причем тут это?
Части словарных статей можно хранить как угодно. И в зависимости от типа кода и в зависимости от других моментов. И об исполнимой части кода речь ни в коем случае не идет!
ArtemKAD писал(а):
Поиск в самой системе ведется за счет вызова методов поиска по каждому из словарей.
А что это даст? В любом случае поиск это сравнение с шаблоном в списке. Позволит менять формат списка - переходить от связанного списка к таблицам - а толку?

Это позволит сделать инсрумент более гибким и мощным.
Это позволит использовать одну структуру(словарь) для работы с любыми данными не создавая собственных сложных решений. Не создавая сложныс структур Case и пр. А так же формализует методы доступа к различным как по методу хранения так и по методу поиска и исполнения данные.

ArtemKAD писал(а):
Позволит искать во внешних источниках как в словаре? Но тогда появится куча вопросов, а что с этим найденым делать в исполнимом коде - как его в код компилировать или как его выполнять(не говоря уже о том, а насколько найденное эквивалентно обычным словам).

Об этом и вопрос. Потому что сразу возникает вопрос, как копмилировать те или иные слова.
Я могу предложить некоторые варианты. Например компилировать ссылку ну имя в таком виде:
" disk_c dir_a file_name" EVALUATE
Ну, или можно грузить мапить файл в память и делать на него ссылку.

Вобщем тут и находится главный вопрос: как сделать это просто и удобно. Чтобы не выйти за рамки форта и избавить одновременно форт от костылей типа OPEN_FILE CLOSE_FILE и т.п.

ArtemKAD писал(а):
Если это-бы был обычный словарь, то компилировалось и исполнялось слово-интерфейс (часть DOES> при создании слов в зеркале), а так еще надо сверху на словарную структуру накручивать кучу контекстно зависимых интерфейсов. Причем не факт, что их набора хватит "на все случаи жизни"...

А и не надо делать все на все случаи жизни. Нужно научиться выполнять простейшие действия и расширять методики работы словаря. Ну что-то вроде такого:

: execute ( ix id --> iy ) S" execute" CURRENT @EXECUTE ;

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 03, 2006 02:40 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5016
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 21 раз.
Поблагодарили: 58 раз.
yGREK писал(а):
~ac/lib/ns/*.f ? По-моему реализовано как раз то, про что Вы говорите..


Вроде да. Но только частично 8) Так как все-таки это надстройка над фортом. И возможно по-этому выглядит сложнее. Но уже очень близко, к тому, что бы мне хотелось 8) Так что обращу свое пристальное внимание.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 03, 2006 22:07 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5016
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 21 раз.
Поблагодарили: 58 раз.
Кстати не только я озабочен такой проблемой: http://www.forth.org.ru/~mlg/#t32 вот 8) :

Исполнимый стек словарей T32 — расширение языка Форт: словари являются функциями, и можно определять функции, ведущие себя как словари.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


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

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5016
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 21 раз.
Поблагодарили: 58 раз.
И еще кое-что по этой теме нашел: http://www.forth.org.ru/~mlg/COP-93/cop93.html
.. Вроде уже на много ближе к тому, что мне хоца.
Может у кого еще есть что-нить на примете?

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


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

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

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

НО. есть в форте группа слов, которые являются наиболее часто разыскиваемыми - это слова форт-вм и управляющие конструкции. Кроме того проблемы возникают с литералами, которые распознаются лишь после того, как будут просмотрены все словари в контексте.

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

Эта проблема известна давно и большинство старых фортов(потому что машины тогда были очень медленными) оптимизировало методику поиска. Для этого использовались обычно хеш методы, но вроде были и бинарные деревья. Были статьи об экзотических подходах, когда слова в словаре сортировались по частоте обращения к ним, или заранее вычислялось, что например : ; DUP DROP и прочие должны всегда лежать на вершине словаря.

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

: ` [COMPILE] LITERAL ; IMMEDIATE

` 123 ` 234 + .
правда слово- ` - тоже будет искаться в словаре и на это будет потрачено определенное время. Кроме того придется все время пользоваться ` что мягко говоря непривычно. Тем не менее форт использует и такой подход, когда работает с символами - Char" [CHAR] CHAR ,,,- а так же для работы со строковыми литералами - " S" C" A" Z" ,,,.


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

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5016
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 21 раз.
Поблагодарили: 58 раз.
Итак, скорость работы конкретного интерпретатора\компилятора форта сильно зависит от методики поиска по словарю. В то же время сложность форт-системы определяется во многом сложностью поиска по словарю. То есть, если вы хотите быстро написать свою систему и не хотите заморачиваться, то вы просто берете и делаете односвязный список - благо это легко реализуется даже на Си. И соответственно получаете очень медленный интерпретатор.
Так поступает СПФ, хотя уже давно не стремится к простоте...

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


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7047
Благодарил (а): 17 раз.
Поблагодарили: 116 раз.
А какие-нибудь оценки производительности есть? А то я не особо замечал разницу между просто загрузкой файла и его интерпретацией - все упирается в скорость обмена с диском.


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

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5016
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 21 раз.
Поблагодарили: 58 раз.
Хищник писал(а):
А какие-нибудь оценки производительности есть? А то я не особо замечал разницу между просто загрузкой файла и его интерпретацией - все упирается в скорость обмена с диском.


насчет скорости поиска уже здесь на форуме проскакивали цифры.
очень даже показательные. Вот только где это я не помню.


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

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
oleg писал(а):
Для этого нужно как минимум, чтобы методы find execute были у каждого словаря свои...


Только назвать их надо по другому. Можно добавить префих, на пример - VOC_ .


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

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5016
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 21 раз.
Поблагодарили: 58 раз.
Mihail писал(а):
oleg писал(а):
Для этого нужно как минимум, чтобы методы find execute были у каждого словаря свои...

Только назвать их надо по другому. Можно добавить префих, на пример - VOC_ .

зачем называть как-то иначе? Лучше делать так, чтобы менять ничего не пришлось, все бы работало, как обычно, но при этом можно было бы использовать и по-новому. Тот же подход, я предлагал для форматного преобразования строк, тот же практически подход работает при эффекте, который ты назвал "неявная компиляция". То есть у меня вопрос возникает именно как лучше интегрировать, чтоб было просто, удобно и гибко. А так я бы согласился с СОР или Черезовским ns.

В том то и дело, что я вижу, к этому все идет, но идет не тем путем. В спф-е начинаются усложнения сверху, надстройки, которые не дают системы, не дают решать задачи в рамках стандартного похода.
КОП - вроде начинает снизу, но вокруг него понакручено слишком много. Я не понял зачем там так все сложно!


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

Зарегистрирован: Чт янв 25, 2007 15:29
Сообщения: 7
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Все конечно хорошо, но вот кто объяснит - почему sp-forth 4.18 (http://sourceforge.net/forum/forum.php?forum_id=640855) под "родимой" XP, не находит слов, в частности "FORGET" и т.д. Хотя в словаре они есть??? Вопрос, конечно, новичка в Forth, но писать-то я умею!!!!!

_________________
Новичок


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

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


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

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


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

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