Forth
http://fforum.winglion.ru/

RuF09: Словари
http://fforum.winglion.ru/viewtopic.php?f=36&t=1851
Страница 2 из 4

Автор:  chess [ Вс янв 11, 2009 21:39 ]
Заголовок сообщения: 

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

Насчет медленно - можно быстро. Насчет неудобно - спорно, в реальных задачах все может быть завязано гораздо "интереснее" чем
слова в словарях и словари между собой.
Дело в том, что усложнение кодохранилища(словарей) приводит к затруднению реализации (на мой взгляд) гораздо более "нужных" возможностей конструирования программ.
mOleg писал(а):
либо посмотреть в форк Smile где они де факто все являются словами!
и распознают числа словари.

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

Никаких проблем с макросами у меня нет, наоборот я их широко использую.
mOleg писал(а):
Тем не менее любое слово в форте остается словом и находится в словаре (даже если словарь подразумевается, и слов поддержки нет)

Что-то вот это совсем непонятно.

Автор:  mOleg [ Пн янв 12, 2009 21:09 ]
Заголовок сообщения: 

chess писал(а):
Насчет медленно - можно быстро. Насчет неудобно - спорно, в реальных задачах все может быть завязано гораздо "интереснее" чем
слова в словарях и словари между собой.
Дело в том, что усложнение кодохранилища(словарей) приводит к затруднению реализации (на мой взгляд) гораздо более "нужных" возможностей конструирования программ.

и мы опять приходим к ситуации: мнение против мнения ;)
мне очень удобно, и реализацию упрощает - вам - "приводит к затруднению реализации"
и тут мы не договоримся судя по всему.

chess писал(а):
mOleg писал(а):Тем не менее любое слово в форте остается словом и находится в словаре (даже если словарь подразумевается, и слов поддержки нет)
Что-то вот это совсем непонятно.

это как в ООП - что бы там ни было, по сути оно объект.

Хотя странно, что не понимаете, ведь в форте кроме слов ничего другого и нет! это просто языковая среда.

Автор:  VoidVolker [ Пн янв 12, 2009 21:33 ]
Заголовок сообщения: 

Лично я вижу слова, словари, форт и код вот так:
слово - последовательность символов, несущая иформацию о взаимосвязи участка кода и того что он делает;
словарь - некоторый набор взаимосвязанных слов;
программа - как набор взаимных связей различных участков кода и как набор слов в исходнике.

Автор:  вопрос [ Пн янв 12, 2009 21:56 ]
Заголовок сообщения: 

Цитата:
Хотя странно, что не понимаете, ведь в форте кроме слов ничего другого и нет! это просто языковая среда.
Ещё правила их сочетания

Автор:  mOleg [ Пн янв 12, 2009 21:59 ]
Заголовок сообщения: 

вопрос писал(а):
Ещё правила их сочетания

да нету никаких особых правил сочетания :)

Автор:  mOleg [ Вт фев 17, 2009 15:40 ]
Заголовок сообщения: 

ладно, по словарям и словарным статьям (что вытекает одно из другого)
предложениe:

рассматривать любую словарную статью как произвольный набор аттрибутов различного вида.
работать с полями с помощью интерфейсных слов GET-ATTR и SET-ATTR (вместо старых >BODY >CODE и пр)
базовым аттрибутом, по которому можно найти все остальные считать LFA
GET-ATTR ( lfa u--> attr 0 | err )
SET-ATTR ( attr lfa u --> 0 | err )
где u - индекс атрибута; lfa указатель на слово; attr - адрес, данные, строка и т.п;err - код ошибки
количество атрибутов может быть произвольным, но обязательно зафиксировать следующие атрибуты:
1 - lfa предыдущего слова
2 - поле имени
3 - поле кода
4 - поле данных
5 - флаг immediate
6 - флаг smudge
порядок следовани должен быть строго фиксирован

методы SET-ATTR и GET-ATTR могут быть у каждого словаря свои.

таким образом слово ?IMMEDIATE будет выглядеть следующим образом:
: ?IMMEDIATE ( lfa --> flag ) 5 GET-ATTR THROW ;
еще пример: вернуть имя слова по его lfa
: ID> ( lfa --> asc # ) 2 GET-ATTR THROW ;

замечу, что возможны ситуации, когда у слова нет определенных полей, к примеру:
:NONAME слова не имеют поля имени (другие поля быть должны)
ALIAS слова по сути не имеют собственных поля кода и данных, хотя флаги у него свои
не все словари могут возвращать ссылку на предыдущее слово из текущего
и т.п.

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

Автор:  WingLion [ Вт фев 17, 2009 19:18 ]
Заголовок сообщения: 

хмм... первая мысля, пришедшая после прочтения последнего поста -- WordSQL ;)

Автор:  mOleg [ Вт фев 17, 2009 23:11 ]
Заголовок сообщения: 

WingLion писал(а):
хмм... первая мысля, пришедшая после прочтения последнего поста -- WordSQL

нет, на данный момент fork :)

Автор:  WingLion [ Ср фев 18, 2009 05:48 ]
Заголовок сообщения: 

Это я к тому, что после:

mOleg писал(а):
GET-ATTR ( lfa u--> attr 0 | err )
SET-ATTR ( attr lfa u --> 0 | err )


может захотеться:

NEW-ATTR ( создание нового атрибута )
DROP-ATTR
REPLACE-ATTR

и т.д и т.п.

Автор:  mOleg [ Ср фев 18, 2009 20:05 ]
Заголовок сообщения: 

WingLion писал(а):
NEW-ATTR ( создание нового атрибута )

это функциональность словаря, то есть количество аттрибутов определяет словарь.
возможно и можно NEW-ATTR но не стоит это относить к базовой функциональности. То есть для стандарта достаточно только SET и GET

Автор:  Kopa [ Чт фев 19, 2009 08:30 ]
Заголовок сообщения: 

mOleg писал(а):
WingLion писал(а):
NEW-ATTR ( создание нового атрибута )

это функциональность словаря, то есть количество аттрибутов определяет словарь.
возможно и можно NEW-ATTR но не стоит это относить к базовой функциональности. То есть для стандарта достаточно только SET и GET


Можно сделать ещё один шаг и определить понятие структуры как определяющее слово
для следующего. т.е. один из атрибутов слова - это возвращаемый тип параметров:)
при использовании имени структуры в создании словарной статьи.
Двоеточие определяющее слова без специфицирования типа и количества возращаемых
параметров. Заранее указание на возвращаемый тип может оказаться полезной при
реализации слова ( близкое понятие локальные переменные слова )

P.S. Имя слова словарика тоже можно сделать определяющим для словарной статьи, но
это уже сильно изменит синтаксис использование его:)

Автор:  вопрос [ Чт фев 19, 2009 09:31 ]
Заголовок сообщения: 

WingLion писал(а):
Это я к тому, что после:
может захотеться:

NEW-ATTR ( создание нового атрибута )
DROP-ATTR
REPLACE-ATTR

и т.д и т.п.
чем это плохо, или хорошо :?:

Автор:  Hishnik [ Чт фев 19, 2009 10:42 ]
Заголовок сообщения: 

Многие внутренние механизмы Форта интуитивно понятны. Человек может прочитать про основную идею, и сразу получить в голове целый спектр собственных вариантов. Несколько таких идей - и в голове собственная форт-машина. Это очень мощно, это резерв для маневрирования и создания систем с определенным, хорошо адаптированным под задачу набором свойств. Как инструмент мастера-ювелира, которым можно делать шедевры в одиночку. А стандартизация - это из раздела крупноблочного строительства, когда панель должна быть состыкована с водопроводными трубами и отоплением. Вот откуда мне должно быть интуитивно понятно, что надо завести атрибуты (какие?) и GET-ATTR SET-ATTR к ним? А если я поле данных не использую (а я не использую)? И так далее. Потому и речь о том, что для конкретных проектов может оказаться возможным "протянуть руку и взять то, что нужно", сделав минимально-работоспособную форт-систему. А не устраивать сначала ритуальные танцы с выписыванием посторонних функций, которые к решаемой задаче ну вообще никаким боком.

Автор:  WingLion [ Чт фев 19, 2009 12:45 ]
Заголовок сообщения: 

вопрос писал(а):
чем это плохо, или хорошо


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

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

Автор:  mOleg [ Чт фев 19, 2009 21:16 ]
Заголовок сообщения: 

Хищник писал(а):
Вот откуда мне должно быть интуитивно понятно, что надо завести атрибуты (какие?) и GET-ATTR SET-ATTR к ним?

интуитивная понятнось понятие сложное - лично мне чаще всего сложно разбираться с интуитивно-понятными интерфейсами, потому что многие из них с точки зрения логики не понятны нифига.

фактически должно быть закреплено всего несколько слов:
SET-ATTR GET-ATTR и несколько констант, работающих с ними &code &name &size &prev &imm &smg
реализация не сложна и достаточно понятна.
таким образом мы отвязываемся от фиксированной модели словаря, и со словарем можно работать как с БД или как с ФС - по-моему это большой плюс. Ведь сложность иногда выгоднее нарастить снизу, чем значительно большую сложность наращивать сверху.

WingLion писал(а):
Я лишь намекнул, что подобное построение становится похожим на построение базы данных, но намек остался не понят

понят. Это действительно так, потому что словарь по сути и есть БД, только урезанная сильно по функциональности.

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