Forth
http://www.fforum.winglion.ru/

обсуждение не понял чего
http://www.fforum.winglion.ru/viewtopic.php?f=25&t=2758
Страница 3 из 5

Автор:  chess [ Чт сен 08, 2011 15:20 ]
Заголовок сообщения:  Re: наследование..

вопрос писал(а):
может быть это соотношение декларативность -императивность ?

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

Автор:  _Harry [ Чт сен 08, 2011 16:46 ]
Заголовок сообщения:  Re: наследование..

вопрос писал(а):
Я думаю, это ошибка, т.е. да - кое-что можно и даже нужно делать без NOTFOUND, но в ряде случаев это добавляет работы, усилий
Это я к тому что в форке есть более удобные способы транслировать не фотовский текст. Они более удобны чем простой NOTFOUND.
Для других фортов NOTFOUND очень даже может пригодится, но только нельзя чересчур увлекаться отбирая у штатного интерпретатора все чего не попадя :wink:

Автор:  вопрос [ Чт сен 08, 2011 16:48 ]
Заголовок сообщения:  Re: наследование..

_Harry писал(а):
Это я к тому что в форке есть более удобные способы транслировать не фотовский текст. Они более удобны чем простой NOTFOUND
в любом случае ведь слово сначала нужно "не найти", а потом уж более удобные способы

Автор:  _Harry [ Чт сен 08, 2011 16:51 ]
Заголовок сообщения:  Re: наследование..

можно ведь сделать через NOTFOUND, который будет распознавать в array[index] обращение к массиву и компилировать строчку выше, а можно ухищряться
array[ index ]@[/quote]

И чем второй вариант хуже я бы выбрал именно его.
( я и на Си все пробелами разделяю так лучше читается)

Автор:  вопрос [ Чт сен 08, 2011 17:05 ]
Заголовок сообщения:  Re: наследование..

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

Автор:  mOleg [ Чт сен 08, 2011 18:02 ]
Заголовок сообщения:  Re: наследование..

chess писал(а):
mOleg писал(а):
вот теперь я точно уверен что вы на своем компьютеры все файлы храните в одной корневой папке избегая излишней сложности (И диск у вас тоже разделов не имеет). Ведь так однозначно проще!

Да нет. У меня как раз много разделов на диске ( C, D, E....L, M) и каталогов всяких много и иерархия в каталогах тоже есть.

8) тогда уже легче

chess писал(а):
Аналогия в организации словарей и каталогов чисто внешняя, а не по существу. Манекен тоже смахивает на человека, ну и что.

вполне себе по существу.

chess писал(а):
Динамическая составляющая это набор структур данных с изменяемой структурой и соответственно набор процедур для работы с такими структурами. По отношению к программисту алгоритм тем проще реализуем, чем больше его статическая составляющая по отношению к динамической. Это следует из того, что статическая составляющая какой-бы большой она не была легко укладывается в долговременной памяти программиста. Динамическая составляющая(оперативный контекст) удерживается в кратковременной памяти программиста, объем которой (объем внимания) на порядки меньше объема долговременной памяти. Из этого момента следует два вывода:
1.Нужно из алгоритмов, которые дают один результат выбирать для реализации те, для которых соотношение стат/дин больше.
2. Для реализации алгоритма выбирать такую инструментальную среду, в которой инструментальный вклад в динамическую составляющую алгоритма минимален.

вот ничего не понял, вообще как оно к словарям относится?

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

Автор:  _Harry [ Чт сен 08, 2011 18:09 ]
Заголовок сообщения:  Re: наследование..

вопрос писал(а):
тем, что нужно отследить поведение 3 слов, притом. таковые создаются отдельно и могут играть другую рольв другой ситуации, которая может пересекаться с обсуждаемой и создавать дополнительные сложности (как со словарями)
Мама дорогая :!: давайте совсем без слов обходится и словари тогда уж точно не нужны. Ну что вы в самом деле :!: :shock: :?:

Автор:  mOleg [ Чт сен 08, 2011 18:15 ]
Заголовок сообщения:  Re: наследование..

вопрос писал(а):
пример - обращение к массиву array @ index @ CELLS + @
можно ведь сделать через NOTFOUND, который будет распознавать в array[index] обращение к массиву и компилировать строчку выше, а можно ухищряться
array[ index ]@

обычно делается таки иначе, пишется:

: AI ( # --> addr ) elem * arr_base + ;
и далее
1 AI elem@
2 AI elem!
а возможно даже так:

: E@ ( # --> elem ) AI elem@ ;
: E! ( elem # --> ) AI elem! ;

а вот с кракозябрами и кучей NOTFOUND в цепочке получается таки незнамо непредсказуемо что.

Автор:  вопрос [ Чт сен 08, 2011 19:48 ]
Заголовок сообщения:  Re: наследование..

mOleg писал(а):
все же это, скажем, таки не тот стиль, не та методика, которую создавал Мур

это - важнее
Действительно ли методика Мура настолько совершенна, чтобы следовать ей особо старательно?
Замечу - самому Муру она показалась недостаточной и он решил её "раскрасить"
mOleg писал(а):
кучей NOTFOUND в цепочке получается таки незнамо непредсказуемо что

да, но если это - стабильный синтаксис, то откуда возьмётся непредсказуемость?

Автор:  chess [ Чт сен 08, 2011 20:16 ]
Заголовок сообщения:  Re: наследование..

mOleg писал(а):
вот ничего не понял, вообще как оно к словарям относится?

Ну что я еще могу сделать. Я объясняю как могу. :(
вопрос писал(а):
Замечу - самому Муру она показалась недостаточной и он решил её "раскрасить"

Это он так убрал из объема внимания оперативный контекст связанный со STATE.
Я это тоже планирую сделать, уже иногда начинает доставать.
Со словарями он тоже разобрался - по существу сократив их до двух(второй для слов немедленного исполнения). Я планирую оставить только один словарь.
Могу только предполагать, что в какой-то момент задачи стали сложнее и он улучшил для этого свой форт.

Автор:  Hishnik [ Чт сен 08, 2011 20:26 ]
Заголовок сообщения:  Re: наследование..

chess писал(а):
Это он так убрал из объема внимания оперативный контекст связанный со STATE.
Я это тоже планирую сделать, уже иногда начинает доставать.


Аналогия с Си.

Код:
int function1(int x)
{

}


Я правильно понимаю, что начинает доставать необходимость определения, находимся мы внутри фигурных скобок, или снаружи?

Автор:  chess [ Чт сен 08, 2011 20:43 ]
Заголовок сообщения:  Re: наследование..

Хищник писал(а):
Я правильно понимаю, что начинает доставать необходимость определения, находимся мы внутри фигурных скобок, или снаружи?

Нет. Мешает необходимость описывать поведение кода процедуры в режиме интерпретации и в режиме компиляции.

Автор:  Hishnik [ Чт сен 08, 2011 21:06 ]
Заголовок сообщения:  Re: наследование..

chess писал(а):
Нет. Мешает необходимость описывать поведение кода процедуры в режиме интерпретации и в режиме компиляции.

Это как? :shock:

Автор:  chess [ Пт сен 09, 2011 10:21 ]
Заголовок сообщения:  Re: наследование..

Хищник писал(а):
Это как?

Интерпретатор в зависимости от состояния STATE(true\false) по разному реагирует на имя(name)
true - исполняет код1
false - исполняет код2
Соответственно для name эти два кода должны быть предварительно созданы.

Если убрать STATE из интерпретатора и состояние запихивать в имя name все упрощается.
к примеру
name - компиляция имени
name` - исполнение имени
name: - запись имени в словарь
и далее в том же духе...

В итоге оперативный контекст состояния интерпретатора отсутствует.

Автор:  Hishnik [ Пт сен 09, 2011 11:32 ]
Заголовок сообщения:  Re: наследование..

Все хорошо и красиво. Есть о чем поговорить с применением крутых терминов. Остается непонятным, зачем решается задача, которая не ставилась, и где результат в виде объективных метрических показателей. Типа того, что "вот раньше, с оперативным контекстом интерпретатора, программы писались за три месяца, а если его убрать, и потратить две недели на изучение нового инструмента, то пишутся за два месяца".

P.S. Ну не заставляют меня термины оцепенеть и прикинуться обывателем из сказки про голого короля, который боится, как бы его дураком не посчитали.

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