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/ |