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

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

Автор:  mOleg [ Ср сен 07, 2011 04:12 ]
Заголовок сообщения:  Re: наследование..

chess писал(а):
Да мне они без надобности, вот и не умею.

дык 8(, ну ладно

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

например о чем речь?

chess писал(а):
Там никаких специальных слов для переключения контекста нет однако.

и такие варианты есть у меня. Хотя явное управление ээ пространством поиска удобно.

chess писал(а):
А неинтересно понятно почему - даже простая схема аля F83 на практике не сильно нужна

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

Автор:  WingLion [ Ср сен 07, 2011 04:31 ]
Заголовок сообщения:  Re: наследование..

вопрос писал(а):
репика


В каком словаре искать значение этого э... междометия?

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

mOleg писал(а):
дык 8(, ну ладно

Это вопрос для меня принципиальный.
Что такое контекст поиска для программиста.
Это состояние транслятора. Когда программист тем или иным образом меняет контекст поиска
он меняет состояние транслятора. Соответственно транслятор один и тот же текст воспринимает
по разному в зависимости от своего состояния. Программист это вынужден оперативно учитывать.
Таким образом имеем заполнение оперативного объема внимания программиста этим самым контекстом, что
в целом уменьшает оперативный объем внимания для сущностей задачи. Этот момент снижает эффективность
работы программиста, а это мерило качества инструментария программиста высшей категории значимости. Ладно бы без этого нельзя обойтись, так ведь можно.
Поэтому множество словарей это плохо при любой их организации. Все остальное - выбор меньшего из зол.
Если хотите - выбирайте. Я не хочу, так как есть возможности нормальной работы с одним словарем.

Автор:  вопрос [ Ср сен 07, 2011 11:03 ]
Заголовок сообщения:  Re: наследование..

WingLion писал(а):
вопрос писал(а):
репика

В каком словаре искать значение этого э... междометия?
репЛика

Автор:  Hishnik [ Ср сен 07, 2011 15:00 ]
Заголовок сообщения:  Re: наследование..

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

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

Автор:  mOleg [ Ср сен 07, 2011 17:07 ]
Заголовок сообщения:  Re: наследование..

chess писал(а):
Что такое контекст поиска для программиста.
Это состояние транслятора. Когда программист тем или иным образом меняет контекст поиска
он меняет состояние транслятора. Соответственно транслятор один и тот же текст воспринимает
по разному в зависимости от своего состояния.

Вобщем согласен.

chess писал(а):
Программист это вынужден оперативно учитывать.

И что? Мы в повседневной жизни все время должны учитывать контекст, я не вижу сложности тут.

chess писал(а):
Таким образом имеем заполнение оперативного объема внимания программиста этим самым контекстом, что в целом уменьшает оперативный объем внимания для сущностей задачи.

Не согласен. Словари как и объекты служат для сокрытия лишней информации, вам надо держать в голове меньше а не больше, меньше мучиться с придумыванием имен. Вы ведь не против локальных переменных?

chess писал(а):
Поэтому множество словарей это плохо при любой их организации.

По мне - так свалка в одном месте всего и вся есть бОльщая проблема! При нормальной организации работа со словарями незаметна.

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

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

Автор:  WingLion [ Ср сен 07, 2011 18:14 ]
Заголовок сообщения:  Re: наследование..

chess писал(а):
Поэтому множество словарей это плохо при любой их организации.


"Не надо говорить за всех" (с) FIDO

Автор:  вопрос [ Ср сен 07, 2011 18:38 ]
Заголовок сообщения:  Re: наследование..

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

Автор:  chess [ Ср сен 07, 2011 19:45 ]
Заголовок сообщения:  Re: наследование..

mOleg писал(а):
И что? Мы в повседневной жизни все время должны учитывать контекст, я не вижу сложности тут.

Вот вы не видите, а сложность есть. Надо бы ее вам все-таки увидеть, а то все остальные ваши
доводы строятся как раз на факте игнорирования наличия этой самой сложности.

Автор:  chess [ Ср сен 07, 2011 19:49 ]
Заголовок сообщения:  Re: наследование..

mOleg писал(а):
Не согласен. Словари как и объекты служат для сокрытия лишней информации, вам надо держать в голове меньше а не больше, меньше мучиться с придумыванием имен. Вы ведь не против локальных переменных?

Вывод неверный насчет меньше, а не больше, по причине, указанной в предыдущем посте.

Автор:  chess [ Ср сен 07, 2011 19:51 ]
Заголовок сообщения:  Re: наследование..

mOleg писал(а):
По мне - так свалка в одном месте всего и вся есть бОльщая проблема!

Если свалка, то да. Вопрос - зачем устраивать свалку, но это несколько в сторону - не по теме.

Автор:  mOleg [ Ср сен 07, 2011 20:14 ]
Заголовок сообщения:  Re: наследование..

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

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

chess писал(а):
mOleg писал(а):
По мне - так свалка в одном месте всего и вся есть бОльщая проблема!

Если свалка, то да. Вопрос - зачем устраивать свалку, но это несколько в сторону - не по теме.

это как раз по теме. Аналогия с каталогами очень близкая. Подумайте над тем, что, скажем, ДОСевый (а нонче и виндошный) path является контекстом 8)

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

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

Да нет. У меня как раз много разделов на диске ( C, D, E....L, M) и каталогов всяких много и иерархия в каталогах тоже есть.
Только к теме разговора это никак не относится, как я уже и говорил. Аналогия в организации словарей и каталогов чисто внешняя, а не по существу. Манекен тоже смахивает на человека, ну и что.
Любой алгоритм по отношению к программисту содержит в грубом приближении две составляющие - статическую и динамическую.
Статическая составляющая это набор статических структур данных и процедур работы с этими данными.
Динамическая составляющая это набор структур данных с изменяемой структурой и соответственно набор процедур для работы с такими структурами. По отношению к программисту алгоритм тем проще реализуем, чем больше его статическая составляющая по отношению к динамической. Это следует из того, что статическая составляющая какой-бы большой она не была легко укладывается в долговременной памяти программиста. Динамическая составляющая(оперативный контекст) удерживается в кратковременной памяти программиста, объем которой (объем внимания) на порядки меньше объема долговременной памяти. Из этого момента следует два вывода:
1.Нужно из алгоритмов, которые дают один результат выбирать для реализации те, для которых соотношение стат/дин больше.
2. Для реализации алгоритма выбирать такую инструментальную среду, в которой инструментальный вклад в динамическую составляющую алгоритма минимален.
Манипуляции параметрами на стеке, управление словарями, управление основанием системы счисления, управление режимом компиляции/интерпретации все это вносит инструментальный вклад в динамическую составляющую, занимая место в объеме внимания программиста и тем самым отнимая это место у дин. составляющей алгоритма.
И чем сложнее задачи, тем ситуация хуже.

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

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

Предложите, а мы попробуем доказать обратное. Я так уверен в том что в форке можно вообще забыть о таком слове как NOTFOUND.

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

chess писал(а):
1.Нужно из алгоритмов, которые дают один результат выбирать для реализации те, для которых соотношение стат/дин больше.
может быть это соотношение декларативность -императивность :!: ?
_Harry писал(а):
вопрос писал(а):
мне кажется, что для некотор. задач нет другого средства, кроме NOTFOUND

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

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

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