Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Ср ноя 21, 2018 08:12

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - [RuF09] Набор управляющих и определяющих слов. Обсуждение.
Автор Сообщение
  Заголовок сообщения:   Ответить с цитатой
Ну да, и в более расширяемом языке Форт конструкции управления выглядят сложнее, чем в С
Сообщение Добавлено: Чт фев 05, 2009 19:15
  Заголовок сообщения:   Ответить с цитатой
вопрос писал(а):
А кто-то против DUP ?

DUP IF оставит флаг на стеке и перейдет.
вопрос писал(а):
Ну а если на стеке требуется оставить 3 флага в 3 ветвлениях?

"Ну а если секретарша попадет под артобстрел в болото с комарами? Ей на ресепшн нужна форма зеленого берета!"
Сообщение Добавлено: Чт фев 05, 2009 18:39
  Заголовок сообщения:   Ответить с цитатой
Общепринятая, мне кажется практика форта, когда любое слово НЕ оставляет на стеке данных свои входные параметры. Ее преимущества очевидны, когда слово явсно возвращает результаты. Ну а когда не возвращает выходы - входы, для единообразия, все равно следовало бы убирать.
Сообщение Добавлено: Чт фев 05, 2009 13:38
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
вопрос писал(а):
наилучший вариант - автоматически запихивать использованные флаги на отдельный стек для возможного повторного использования - код остаётся линейным при любом количестве ветвлений

Наихудший, надо полагать, использовать DUP, если флаг требуется оставить на стеке?

А кто-то против DUP ?
Ну а если на стеке :D :dmad; требуется оставить 3 флага в 3 ветвлениях?
Сообщение Добавлено: Чт фев 05, 2009 10:04
  Заголовок сообщения:   Ответить с цитатой
вопрос писал(а):
наилучший вариант - автоматически запихивать использованные флаги на отдельный стек для возможного повторного использования - код остаётся линейным при любом количестве ветвлений

Наихудший, надо полагать, использовать DUP, если флаг требуется оставить на стеке?
Сообщение Добавлено: Чт фев 05, 2009 09:47
  Заголовок сообщения:   Ответить с цитатой
Иногда флаг "дальше лишний", иногда нет

наилучший вариант - автоматически запихивать использованные флаги на отдельный стек для возможного повторного использования - код остаётся линейным при любом количестве ветвлений
Сообщение Добавлено: Чт фев 05, 2009 08:09
  Заголовок сообщения:   Ответить с цитатой
Декларация свободы программиста находится в самом начале стандарта (в моем предложении, во всяком случае).
Добавлять после этого, что и IF программист волен по-своему сделать, как-то неправильно.

Да, возможны непоглощающие, а возможны и поглощающие дважды, и ...(тут придумать что угодно)...

Если же вписывать в стандарт все, что возможно, он распухнет и лопнет.
Сообщение Добавлено: Чт фев 05, 2009 06:53
  Заголовок сообщения:   Ответить с цитатой
WingLion писал(а):
По моему, давать однозначные ответы на эти вопросы - бессмысленно. Ответы - дело вкусов и предпочтений разработчиков.

Значит, надо записать что-то похожее на "стековые картины условных конструкций определяются реализацией, возможны непоглощающие условные конструкции".
Сообщение Добавлено: Чт фев 05, 2009 04:19
  Заголовок сообщения:   Ответить с цитатой
in4 писал(а):
И еще такой вопрос - логику лучше представлять флагами проца или значениями на стеке?
Условия должны быть поглощающими или нет?


По моему, давать однозначные ответы на эти вопросы - бессмысленно. Ответы - дело вкусов и предпочтений разработчиков.

Понравится ему после каждого IF-а флаги руками подтирать, сделает так. Не понравится - этак.
Кому надо заставлять в стандарте всех ходить строем и с песней?
Сообщение Добавлено: Вт фев 03, 2009 20:13
  Заголовок сообщения:   Ответить с цитатой
вопрос писал(а):
вместо LOOP - +LOOP
и : LOOP 1 +LOOP ;


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


Это не предложение для команд в процессор или виртуальную машину, а предложение удобных слов, которыми будут описываться остальные слова. Реализация их будет потом, когда добремся до описания этих слов средствами Форта. Вот тогда и можно будет думать о минимуме, да и то не факт, что он (минимум) потребуется.

Для многократного повторения чего-либо удобнее простой LOOP, нежели +LOOP в котором надо еще думать и о единичке перед +LOOP.


Цитата:
Я так понял, что "тянем" для начала все-таки архитектуру фон Неймана(код программы не отделен от данных).


Нет никакого "тянем". Потому что это всего лишь описание. А на чем оно сделано, на Неймане или Гарварде - не имеет значения.
Сообщение Добавлено: Вт фев 03, 2009 20:09
  Заголовок сообщения:   Ответить с цитатой
вопрос писал(а):
DO - LOOP не обязательно в базовый набор.
Вот FOR - NEXT - лучше взять за базовый, да и проще реализовывать...
А для организации циклов есть еще вариант - рекурсия!

Так ни то ни другое не должно быть в базовом наборе.

in4 писал(а):
И еще такой вопрос - логику лучше представлять флагами проца или значениями на стеке?
Условия должны быть поглощающими или нет?
Непоглощающие условия позволяют проще делать последовательные проверки...

Логика здесь ни при чем. Если вы насчет ветвлений можно сделать и так и так, но опять-таки к
базовому набору это не имеет отношения.
Сообщение Добавлено: Вт фев 03, 2009 13:22
  Заголовок сообщения:   Ответить с цитатой
WingLion писал(а):
Предлагаю следующий "сокращенный" набор для согласования:

определяющие:
: ; - для стандартного фортового определения

CREATE DOES> для определения "определяющих" слов.


управляющие:

EXECUTE EXIT - безусловное изменение хода исполнения

IF ELSE THEN - условное исполнение

DO LOOP I J K QUIT - цикл со счетчиком

BEGIN UNTIL - цикл с постусловием

BEGIN WHILE REPEAT - цикл с предусловием

Я так понял, что "тянем" для начала все-таки архитектуру фон Неймана(код программы не отделен от данных).
Сообщение Добавлено: Вт фев 03, 2009 13:07
  Заголовок сообщения:   Ответить с цитатой
DO - LOOP не обязательно в базовый набор.
Вот FOR - NEXT - лучше взять за базовый, да и проще реализовывать... ;)
А для организации циклов есть еще вариант - рекурсия! ;)

И еще такой вопрос - логику лучше представлять флагами проца или значениями на стеке?
Условия должны быть поглощающими или нет?
Непоглощающие условия позволяют проще делать последовательные проверки...
Сообщение Добавлено: Вт фев 03, 2009 12:20
  Заголовок сообщения:   Ответить с цитатой
вместо LOOP - +LOOP
и : LOOP 1 +LOOP ;
Сообщение Добавлено: Вт фев 03, 2009 09:55
  Заголовок сообщения:  [RuF09] Набор управляющих и определяющих слов. Обсуждение.  Ответить с цитатой
Для того, чтобы однозначно "определять" (или, скорее, выражать/объяснять) новые слова через минимальный набор Для ФП и ФВМ

Подчеркиваю - это набор слов, с помощью которых можно выражать другие слова, безотносительно к их реализации. Ясно, что управляющие в конечном итоге через ?BRANCH выразятся, но неудобно каждый раз писать это выражение, когда можно написать 10 0 DO сделать-что-то LOOP и сразу ясно, что это 10-кратное повторение чего-то.

Предлагаю следующий "сокращенный" набор для согласования:

определяющие:
: ; - для стандартного фортового определения

CREATE DOES> для определения "определяющих" слов.


управляющие:

EXECUTE EXIT - безусловное изменение хода исполнения

IF ELSE THEN - условное исполнение

DO LOOP I J K QUIT - цикл со счетчиком

BEGIN UNTIL - цикл с постусловием

BEGIN WHILE REPEAT - цикл с предусловием
Сообщение Добавлено: Вт фев 03, 2009 09:19

Часовой пояс: UTC + 3 часа [ Летнее время ]


cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB