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 очень даже может пригодится, но только нельзя чересчур увлекаться отбирая у штатного интерпретатора все чего не попадя |
Автор: | вопрос [ Чт сен 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) и каталогов всяких много и иерархия в каталогах тоже есть. тогда уже легче chess писал(а): Аналогия в организации словарей и каталогов чисто внешняя, а не по существу. Манекен тоже смахивает на человека, ну и что. вполне себе по существу. chess писал(а): Динамическая составляющая это набор структур данных с изменяемой структурой и соответственно набор процедур для работы с такими структурами. По отношению к программисту алгоритм тем проще реализуем, чем больше его статическая составляющая по отношению к динамической. Это следует из того, что статическая составляющая какой-бы большой она не была легко укладывается в долговременной памяти программиста. Динамическая составляющая(оперативный контекст) удерживается в кратковременной памяти программиста, объем которой (объем внимания) на порядки меньше объема долговременной памяти. Из этого момента следует два вывода: 1.Нужно из алгоритмов, которые дают один результат выбирать для реализации те, для которых соотношение стат/дин больше. 2. Для реализации алгоритма выбирать такую инструментальную среду, в которой инструментальный вклад в динамическую составляющую алгоритма минимален. вот ничего не понял, вообще как оно к словарям относится? Вы пришете код. Для Форта наиболее удобной методикой является создание большого количества маленьких определений с последующим созданием лексикона, пригодного для решения задач нужного вам типа. Чем больше вы создаете определений - тем больше вы вынуждены выдумывать имен (а это лично для меня сложно), ведь наш лексикон достаточно ограничен. Иногда создаваемые определения оказываются очень полезны в большом количестве мест, т.е. их удобно использовать в разных типах задач, примером такого лексикона являются базовые определения форт-системы, но чаще приходится создавать узкоспециальные определения и узкоспециальный контекст и с ним иметь дело. Очень непросто создавать универсальные определения не только в плане пригодности, но и в плане совместимости (это одна из серьезных проблем Форта), т.е. таких определений которые можно использовать совместно с другими без побочных эффектов. То есть в итоге получаются специфические замкнутые лексиконы, которые и стоит "упаковывать" в отдельные пространства имен, при этом снаружи оставляются только интерфейсные имена, через которые производится взаимодействие с ограниченным содержимым нужного лексикона. В рамках такой модели создания ПО на Форте словари незаменимы. То, что вы пишете огромные определения и определения со структурой, несвойственной форту мне говорит о том, что на так тоже можно писать, но, все же это, скажем, таки не тот стиль, не та методика, которую создавал Мур (ИМХО). |
Автор: | _Harry [ Чт сен 08, 2011 18:09 ] |
Заголовок сообщения: | Re: наследование.. |
вопрос писал(а): тем, что нужно отследить поведение 3 слов, притом. таковые создаются отдельно и могут играть другую рольв другой ситуации, которая может пересекаться с обсуждаемой и создавать дополнительные сложности (как со словарями) Мама дорогая давайте совсем без слов обходится и словари тогда уж точно не нужны. Ну что вы в самом деле
|
Автор: | 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 писал(а): Нет. Мешает необходимость описывать поведение кода процедуры в режиме интерпретации и в режиме компиляции. Это как? |
Автор: | 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/ |