Из практических соображений - Форт остается Фортом до тех пор, пока для работы с ним требуется изучать книги по Форту (а не по, допустим, Си или Бейсику). Это если нестрого.

На ПК контроль памяти, входного потока, CREATE DOES> скорее нужны, чем нет. В форт-процессорах это все не особо приживается, потому что есть на хост-системе. В ПЛИС обычно нужны структуры управления, переменные и массивы.

[quote="Victor__v"]Эх, очередная тема по безсмысленным и безпощадным высказываниям)

Выскажусь и я) [quote]когда форт перестает быть фортом?[/quote] Никогда :mrgreen:[/quote]
"Есть только миг, между прошлым и будущим. Именно он, называется [b]ФОРТ[/b]" :work;

[quote="Victor__v"]Никогда :mrgreen:[/quote]
Все есть Форт &)

Или, как там, дао, путь по которому можно идти бесконечно...

Эх, очередная тема по безсмысленным и безпощадным высказываниям)

Выскажусь и я)
[quote]когда форт перестает быть фортом?[/quote]

Никогда :mrgreen:

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

И вообще, любой язык программирования, который хочет (а Форт хочет?) быть успешным и иметь свою часть пирога, допустим, при программировании микроконтроллеров (а это сейчас едва ли не единственная ниша, в которой Форт пока еще чувствует себя неплохо), просто обязан быть кросс-компилятором (пусть даже ценой упрощения и отказа от каких-то конструкций языка), но может быть (но только как опция) также и интерпретатором, зашиваемым в микроконтроллер. Для слабых микроконтроллеров так вообще единственный вариант - это кросс-компилятор. Превратить программу на языке программирования в исполняемый файл или прошивку в виде файла (а не в виде куска оперативной памяти, с которой потом еще что-то надо делать) - это нормальное человеческое желание. :) Нет, можно конечно и дальше считать Форт языком для когорты спустившихся с небес луноликих старцев и требовать везде интерпретатор, но тогда сразу исключается возможность использования форта для, например, однократно программируемых контроллеров, контроллеров без возможности самопрограммирования флеш, контроллеров с малым количеством flash/ram и т.д. Отпугивает потенциальных программистов от Форта такая его "элитарность" и заметно сужает круг возможных применений :) Поэтому, если не хотим остаться в прошлом тысячелетии, надо идти в ногу со временем и приспосабливаться к текущим реалиям :)
И другая ниша, где Форт достаточно хорош. Это скрипты. Вот здесь-то как раз и нужен интерпретатор, но опять же нельзя всех под одну гребенку. Надо реализовывать только те слова, которые нужны, и тем способом, который удобнее/короче/проще и т.д., а не так, как предписывается в ветхозаветных стандартах :)

[quote="mOleg"][quote="Total Vacuum"]Так вот словарь. Обязан ли словарь являть собой одну из разновидностей шитого кода?[/quote]ну, все же, ШК это не к словарю, а к методу адресной интерпретации (некоторыми нелюбимое название ФВМ)[/quote]Имел ввиду содержимое области памяти, куда в процессе работы обычно складываются заголовки словарных статей и их наполнение. Обязан ли Форт пережевывать тушу (исходник) до состояния фарша (смеси машинных кодов и адресов) или имеет право порубить тушу на крупные куски (какое-то промежуточное представление на языке высокого уровня, асм, ну или любое другое) и на этом успокоиться?

[quote="mOleg"]А, вот, словарь - это просто список, и как он устроен по сути не слишком важно (это особенности реализации)[/quote]Ну а почему не ассоциативный массив? Да и стек вполне подходит для таких целей. :)

[quote="mOleg"]Никто, однако, не сказал о доступе (открытости) ко всему внутреннему устройству интерпретатора,
я так и не понял, важна ли возможность расширения самого языка (например добавление новых управляющих конструкций).[/quote][quote="mOleg"]Или, вот, я взял и написал транслятор Форта (в ассемблерный код, например), и в нем нет ни immediate слов, ни привычного транслятора, а есть что-то вроде привычного Си - это еще Форт, или уже нет?[/quote]Мне кажется, что если хотя бы несколько базовых управляющих конструкций есть "из коробки", то механизм добавления новых совсем не обязателен. Но при этом даже без immediate вполне можно жить, имея возможность добавлять новые управляющие конструкции. :) Да и вообще, если, например, речь о микроконтроллере с небольшим количеством ram/flash, то там в любом случае не нужны какие-то хитровыдуманные управляющие конструкции и какое-нибудь ООП, вполне хватит и базовых управляющих конструкций, а также пары предопределенных типов данных (variable/array). И вообще, зачем в конкретной реализации Форта делать то, чем пользоваться никогда не будем? Надо от потребностей плясать: сложное изделие/проект - тогда реализуем всю внутреннюю кухню (immediate create does> и т.д.), но только если без нее никак не обойтись, а если изделие/проект простое, то зачем искусственно усложнять транслятор? Произвольно взятый Форт не обязан быть безгранично и бесконечно расширяемым, он должен быть расширяемым до каких-то необходимых, но при этом разумных пределов. Мне так кажется :)

Пара примеров, там исходный код можно в браузере посмотреть, если F12 нажать, ну или html скачать:
[url]http://totalvacuum.ru/online3d.htm[/url]
[url]http://totalvacuum.ru/256x176.htm[/url]
В первом случае управляющие конструкции реализуются при помощи immediate, а constant/variable/array и т.д через create does>. А во втором случае управляющие конструкции реализованы через inline, а create does> убрано за ненадобностью. И, кстати, в том и другом случае словарь реализован через ассоциативные массивы. И подпрограммный шитый код на javascript :)

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

[quote="Total Vacuum"]Так вот словарь. Обязан ли словарь являть собой одну из разновидностей шитого кода?[/quote]
ну, все же, ШК это не к словарю, а к методу адресной интерпретации (некоторыми нелюбимое название ФВМ)

А, вот, словарь - это просто список, и как он устроен по сути не слишком важно (это особенности реализации)

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

Вопрос ведь в том, как понять, Форт перед нами, или уже нет.
Вот, к примеру, я добавляю внутрь языка новую базовую абстракцию "объект"( в дополнение к слову), соответственно, с объектами работают уже не так, как со словами, и терминология своя, и взаимодействие другое.
Это еще Форт, или уже нет?
(У объектов нет передачи данных через стек, они вроде как, сообщениями обмениваются.)
Или, вот, я взял и написал транслятор Форта (в ассемблерный код, например), и в нем нет ни immediate слов,
ни привычного транслятора, а есть что-то вроде привычного Си - это еще Форт, или уже нет?

Или, вот, я пишу так:
void BOUNDS(void) { OVER(); ADD(); SWAP(); }
это еще Форт?
Ну, передача данных через стек (данных) имеется.

?А вот такой трюк должен Форт поддерживать:
: Some ['] AAA >R BBB CCC ;
или это не обязательно для Форта?

Или, вот, типизация данных, если я ее возьму и введу в язык, например динамическую типизацию - это уже не Форт?

Если есть стек, подразумеваются и слова для оаботы с ним.

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

Стек данных, словарь, интерпретатор/компилятор. Совсем уж строгие определения формулировать непросто, это надо сначала понять, что с таким определением впоследствии делать.

Еще накину пару лопат на вентилятор :))

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

И еще. Форт пожирает текст из терминала/файла и т.д., а съеденный текст отправляет в словарь. Так вот словарь. Обязан ли словарь являть собой одну из разновидностей шитого кода? Или это может быть какое-то промежуточное представление, в т.ч. и на языке высокого уровня, которое на следующем этапе может быть (необязательно) скомпилировано/обработано каким-то сторонним инструментом для получения исполняемого файла/прошивки/html/midi/да чего угодно? :)

[quote="forther"]Два стека, польская нотация и слова разделенные пробелами.[/quote]Вот согласен на 101%. Причем даже если нет доступ к стеку возвратов через r@ r> >r. И еще нотацию убрать, т.к. она подразумевается. :)

[quote="mOleg"][quote="forther"]Два стека[/quote]
То есть, три стека уже будет не Форт?[/quote]
Это был ответ на вопрос что нельзя убирать. Без того чтоб.

[quote="forther"]Два стека[/quote]
То есть, три стека уже будет не Форт?