Форт-2016 - какой он?

KPG

Mihail писал(а):

Хищник писал(а):

Так что я в основном преследую цель показать, насколько просто писать на Форте.

Кому показать? Тем кто Форт использует - доказывать ничего не надо. Тем кто не использует - нет дела до нашего конкурса.
Если программист заинтересовался Фортом ему надо предоставить примеры использования. Игры хорошо подходят
(вне зависимости от времени создания). Участникам конкурса тоже следует больше использовать существующие
разработки в качестве прототипа и материала.
Если мы не научимся использовать старые программы, то и новым грозит то-же забвение.

Hishnik

KPG писал(а):

Кому показать? Тем кто Форт использует - доказывать ничего не надо. Тем кто не использует - нет дела до нашего конкурса.
Если программист заинтересовался Фортом ему надо предоставить примеры использования. Игры хорошо подходят
(вне зависимости от времени создания). Участникам конкурса тоже следует больше использовать существующие
разработки в качестве прототипа и материала.
Если мы не научимся использовать старые программы, то и новым грозит то-же забвение.

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

KPG

vikt писал(а):

И по теме. Я за мораторий по созданию новых компиляторов форта в новом году.

Наверное это невозможно представить, т.к. всегда может возникнуть "чувство" неудовлетворительности по каким то критериям к используе[муму] инструментарию для задач решаемых с помощью него. :shuffle;

Victor__v

Итак, выскажу своё мнение.
В форте малая плотность кода.
Это не есть хорошо, а есть плохо
При этом, данная проблема решается достаточно легко.
Вот мы придумывает слова для решения наших насущных задач. А могли бы часть этой работы спихнуть на notfound и всё это дело "узаконить"
Пример нужно слово компилирующего действия.
Можно писать так : test ['] here compile, ['] , compile, ;
А можно писать чуть более сжато : test #'here compile, #', compile, ;
Сократили кол-во символов при той же функциональности. И то хлеб

Или надо нам сравнить непонятное значение с кодом литеры.
Постоянно писать [char] x = , не есть хорошо
Лучше 'x' = , уже фортово
Также надо удалить несколько значений со стека. Хорошо ежели такая надобность лишь в одном месте, а если нет?
Писать 2DROP DROP как-то не оптимально.
Скинем эту работу снова на notfound
пусть будет слово 3DROP5 ( A B C D -- A 5 )
При этом, этого слова не существует в природе. Notound работает за нас
Аналогичная ситуация с DUP
Можно ещё что-то добавить
К примеру, меня немножко раздражает складывать числа. Не писать же на каждый случай слова : 3+ 3 + ; : 4+ 4 + ; и т.д.
Лучше спихнём эту работу на notfound, пусть уж он складывает.

VoidVolker

А при чем тут notfound-то? Если пользуемся какой-то частой фразой/сочетанием слов - можем легко тут же написать определение.

Victor__v писал(а):

Не писать же на каждый случай слова : 3+ 3 + ; : 4+ 4 + ; и т.д.

Эмм... Это как бы одна дополнительная проверка в парсере чисел.

Victor__v

VoidVolker писал(а):

А при чем тут notfound-то? Если пользуемся какой-то частой фразой/сочетанием слов - можем легко тут же написать определение.

Victor__v писал(а):

Не писать же на каждый случай слова : 3+ 3 + ; : 4+ 4 + ; и т.д.

Эмм... Это как бы одна дополнительная проверка в парсере чисел.

Всё загвоздка в том, что писать частые определения почти одних и тех же слов надоедает
А notfound-то как-раз и призван анализировать "еретические" мысли, и переводить их в нормальный фортовский.
Сложение с определённым числом больше чем одна проверка, если дело касается оптимизации.
Написать-то можно всё, что угодно. Только в одном случае нам нужен вселенский анализатор непонятного т.е. notfound, а в другом локальный. тут мы можем и обычным BL PARSE обойтись.
Зачем переделывать последовательную запись в запись простых смертных, ежели можно обойтись простым эмулятором?
: + PARSE-NAME EVALUATE ['] +
STATE @
IF COMPILE, ELSE EXECUTE THEN ; IMMEDIATE

VoidVolker

Victor__v писал(а):

Всё загвоздка в том, что писать частые определения почти одних и тех же слов надоедает

Эмм... А зачем их писать многократно? Что мешает сделать это один раз?

mOleg

Victor__v писал(а):

Итак, выскажу своё мнение.
В форте малая плотность кода.

мнение - это хорошо, но чем оно подтверждено и с чем сравнивается?

Victor__v писал(а):

Вот мы придумывает слова для решения наших насущных задач. А могли бы часть этой работы спихнуть на notfound и всё это дело "узаконить"

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

Victor__v писал(а):

Можно писать так : test ['] here compile, ['] , compile, ;

почему бы и нет? таких мест в программе обычно одно-два. Оптимизировать ради двух мест можно, но не обязательно.

Victor__v писал(а):

А можно писать чуть более сжато : test #'here compile, #', compile, ;

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

Victor__v писал(а):

Постоянно писать [char] x = , не есть хорошо

опять же, почему постоянно? Сколько таких мест в программе?
Кстати, в СМАЛ32 был вариант записи 'x.
Я предлагал вариант с более умными словарями (в отличии от notfound) легче контролировать и разбор получается более регулярным.

mOleg

Victor__v писал(а):

Скинем эту работу снова на notfound
пусть будет слово 3DROP5 ( A B C D -- A 5 )

это уже предлагал, если не ошибаюсь, Chess, лично мне не нравится очень, кстати там и notfound во всю используется.

Victor__v писал(а):

К примеру, меня немножко раздражает складывать числа. Не писать же на каждый случай слова : 3+ 3 + ; : 4+ 4 + ; и т.д.
Лучше спихнём эту работу на notfound, пусть уж он складывает.

а это вообще не проблема, я пишу везде только 3 + 1 + ,
2+ и тому подобные определения имели смысл, кода писались в коде для ускорения работы, т.е. не просто определение а либо макрос либо ассемблерное определение.

Victor__v

Цитата:

а это вообще не проблема, я пишу везде только 3 + 1 + ,
2+ и тому подобные определения имели смысл, кода писались в коде для ускорения работы, т.е. не просто определение а либо макрос либо ассемблерное определение.

Некоторые ситуации реально бесят.
К примеру, в зависимости от результата прибавить то или иное число
>R
R@ 1 = IF 1+ THEN
R@ 2 = IF 2+ THEN
R@ 3 = IF 3+ THEN \ ошибка, нет такого слова! 3+
и т.д
Конечно, насчёт 3+ можно перетереть, но ежели таких примеров не одна штука..
А две

Hishnik

Victor__v писал(а):

Некоторые ситуации реально бесят.
К примеру, в зависимости от результата прибавить то или иное число

Код:

TABLE[] 0 , 1 , 2 , 3 ,

\ X -- 
CELLS TABLE[] + @ +

А отдельный разбор выражений X+ - это уже синтаксический анализ. Он потянет за собой вычитание, умножение, деление, потом сложные арифметические выражения, потом запись функций со скобками и т.д. Где-то надо остановиться.

mOleg

Victor__v писал(а):

К примеру, в зависимости от результата прибавить то или иное число
>R
R@ 1 = IF 1+ THEN
R@ 2 = IF 2+ THEN
R@ 3 = IF 3+ THEN \ ошибка, нет такого слова! 3+
и т.д

а я написал бы так:

Код:

1 OVER = IF 1 + ;THEN
2 OVER = IF 2 + ;THEN
...

не пойму, что вас бесит, ежели честно. Если кода такого много, можно придумать конструкцию, позволяющую сократить это до, скажем, следующего синтаксиса:

Код:

some: 1 2 3 ;some или, скажем, 
some: 1 1 
          2 2 
          3 3 
;some

но это пример гипотетического кода, лучше такие вещи рассматривать на реальных примерах.

KPG

mOleg писал(а):

а я написал бы так:

Код:

1 OVER = IF 1 + ;THEN
2 OVER = IF 2 + ;THEN
...

Тогда правильнее на этом гипотетическом примере (иначе он выродится в операцию + и возможно проверку допустимости
возврашаемых данных)

Код:

1 OVER = IF DROP 1 + ;THEN
2 OVER = IF DROP 2 + ;THEN
...

P.S. Методологически анализировать возвращаемые данные в вызывающей процедуре не очень хорошая техника.

Victor__v

Цитата:

не пойму, что вас бесит, ежели честно

Меня бесят лишние пробелы :twisted:

А также некоторые вещи, которые быстрее написать на ассемблере, чем на форте, да и на асме понятней выйдет
Прибавить ко второму числу на стеке 1
Форт: >R 1+ R> или SWAP 1+ SWAP
Ассемблер: INC 4 [ESP]

Цитата:

Тогда правильнее на этом гипотетическом примере (иначе он выродится в операцию + и возможно проверку допустимости
возврашаемых данных)

Пример не гипотетический, это часть кода по увеличению числа, которое находится внутри строки.
\ adr - адрес начала числа
: ZAPR>NEW ( ADR -- )
>R
R@ 4 ?SLITERAL 1+
NUM>S
DUP 1 = IF R@ 3 + THEN
DUP 2 = IF R@ 2+ THEN
DUP 3 = IF R@ 1+ THEN
DUP 4 = IF R@ THEN
SWAP MOVE

R@ 5 TYPE CR \ отладка

RDROP
;

Если предложите что-нибудь лучше, буду только рад

Victor__v

Hishnik писал(а):

Victor__v писал(а):

Некоторые ситуации реально бесят.
К примеру, в зависимости от результата прибавить то или иное число

Код:

TABLE[] 0 , 1 , 2 , 3 ,

\ X -- 
CELLS TABLE[] + @ +

А отдельный разбор выражений X+ - это уже синтаксический анализ. Он потянет за собой вычитание, умножение, деление, потом сложные арифметические выражения, потом запись функций со скобками и т.д. Где-то надо остановиться.

Монстроидизация форта, думаю, никому не нужна
Но заглядывать чуточку, только чуточку, вперёд полезно.
Как никак полезней.
А уж насчёт всяких сложностей, это уже будет не форт
Даже простая эмуляция записи операций хромает на все конечности со стеком.
Эмулировать можно, даже нужно, но форт превыше всего

: + PARSE-NAME EVALUATE
['] +
STATE @
IF COMPILE, ELSE EXECUTE THEN ; IMMEDIATE

Просто? Просто
Где применить? Для наглядной записи.
А где ещё? А хрен его знает
К тому же со стеком эта эмуляция не уживается
10 + dup выдаст 20. Логика уже потусторонняя
А если надо вычислить на сколько приостановить поток в минутах?
Запросто [ 1000 * 60 * 10 lit, ]
Это как-то проще воспринять чем [ 1000 60 * 10 * lit, ]
Хотя, кому как

Форт-2016 - какой он?

Кто сейчас на конференции