>Ява-процессоры это и есть форт-процессоры

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

Factor и BSD

>Если он будет компилиться под BSD системы и Minix3, то было бы вообщде прекрасно!

А на сайт сходить? Поддерживаются все 3 BSD, ну а Minix, если что, сами допиливайте — сырцы вам в руки.

> Присоединяюсь, а если надо обработать исключение?

А с исключениями в форте всё в порядки с середины 90-х.

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

> получив на выходе Форт со статической типизацией
http://home.vrweb.de/stephan.becher/forth/ ← strongForth в этом деле может помочь тебе.

Видел, конечно, сам хотел ссылку кинуть, но решил что и так все в курсе. Хороший пример как можно ввести в Форт статическцю типизацию, почти ничего не сломав, и какие от этого плюшки.

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

И в StrongForth совершенно не используется одно немаловажное преимущество статической типизации (точней фиксации арности слов) — возможность оптимизирующей компиляции (это есть в Factor).

http://home.vrweb.de/stephan.becher/strongforth.f/

Здесь реализация этого дела на форте, а не 16-битном асме

Вот ещё язык Cat до кучи

http://www.cat-language.com/

Ещё стековый язык со статической типизацией.

За основу взят Joy, а не Forth, что не есть good

Компилируется в MSIL, ядро написано на C#, что на любителя (правда ещё народ потихоньку пишет на сях собственную ВМ). Есть ещё реализации на всяких скриптовых языках...

Зато с системой вывода типов...

В общем для практики не очень, а за интересный концепт сойдёт.

>Прошу доказательства в студию!

Трудоёмкость разработки в [равноусловных] цифрах не измерить.

А на пальцах - речь идёт об изначально заложенной в язык метаязычности. И которой, кстати, в отличии от потенциала того же LISP'а постоянно пользуются :) Программа на LISP'е - это почти всегда программа на LISP'е. Программа на Форте же может иметь совершенно разный вид.

>Почему-то Delphi на просторах xСССР бесконечно более популярный

Потому что http://www.linux.org.ru/jump-message.jsp?msgid=4582882&cid=4586238

Если бы для форта в 1997 году была IDE как у ObjectDelphi, то он бы стал языком СССР №1?

Пути роста популярности языков непредсказуемы.

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

Речь немного о другом. Форт-процессоры - это мультистековые процессоры, обладающие базисом операций, наиболее востребованных в Форте и эффективно выполняющих инструкции NEXT. Набор команд может быть ОЧЕНЬ примитивным, из-за этого Форт-процессоры, скажем, легко проектируются и делаются «на коленке» на тех же ПЛИС. Это, кстати, тоже одна из причин отсутствия их массовости, как и в случае Форта. Возможность быстро слепить что-то в домашних условиях порождает зоопарк несовместимых реализаций, что тормозит стандартизацию и унификацию.

>Присоединяюсь, а если надо обработать исключение?

Так исключения в Форте итак есть. В рамках стандарта. Нужно только снова ввести ограничение - после выброса исключения стек будет не в исходном состоянии, а в состоянии исключения, с конкретным типом параметра.

>По мне проще ?DUP выкинуть, чем с ним возится

Угу.

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

Cat, Joy.

> И которой, кстати, в отличии от потенциала того же LISP'а постоянно пользуются :)

А на Лиспе не пользуются?

Программа на LISP'е - это почти всегда программа на LISP'е.

Программа на Maxima хоть немного похожа на программу на Лиспе?

Программа на Форте же может иметь совершенно разный вид.

Так же и с Лиспом.

И именно по этой причине Лисп есть зло. Такое же как и Форт.

А Java всегда выглядит как Java. И это прекрасно.

> Почему-то Delphi на просторах xСССР бесконечно более популярный

Извращенная страна поклонников садо-мазо как бы малость не показательна. В остальном мире все наоборот, Java знают все, а про Delphi слышали единицы.

Ты наверное и хоккей в прямом эфире смотрел? В 5 утра не спать, это тяжело для организъма

>Ты наверное и хоккей в прямом эфире смотрел?

Не-а. Я ТВ не смотрю :)

В 5 утра не спать, это тяжело для организъма

Это я в 5 утра встал :)

Вы, похоже не видели некоторых дивных поделий на дельфях, иначе не задали бы этот вопрос... И особенность этих поделий в том, что они «работают» — и потому существуют. А на форте такое бы просто не заработало.

>А на форте такое бы просто не заработало.

Равно, как и наоборот :)

>Форт-процессоры - это мультистековые процессоры

Далеко не факт. Архитектуры разные бывают.

может быть ОЧЕНЬ примитивным

А он и есть примитивный. Но есть возможность определять сложные слова на очень низком уровне.

стандартизацию и унификацию

Последний стандарт от 93-го года. Но некоторые реализации исторически несовместимы.

и делаются «на коленке»

В свое время, когда увлекался фортом, нашел в Cети вот такую книжку: http://www.ece.cmu.edu/~koopman/stack_computers/index.html пока читал - весь изошелся слюнями. Насколько все легко, просто и правильно. Но с электроникой, я никогда не дружил.

И особенность этих поделий в том, что они «работают» — и потому существуют

+100500

>Далеко не факт. Архитектуры разные бывают.

Хм. Можно пример немультистекового _Форт_-процессора? :)

Нет, не приведу. Хотя бы потому, что в этой области не знаю и 1% разработок.

Но дело не в этом. Мультистековость не является отличительной особенностью форта и форт-машин. Например, в PDP-11 было два стека (два стековых указателя).

А вот наличие словаря и семантики времени исполнения и компиляции у слов - является.

>Например, в PDP-11 было два стека (два стековых указателя).

Здрасьте. Стек вызовов там был один (R6), но стек данных делался на любом другом регистре. Так что или один стек, или один + 5. Но два? :)

А вопрос-то стоял о другом. Не о том, что все мультистековые процессоры - Форт, а о том, что это за Форт-процессор без мультистека? :)

А вот наличие словаря и семантики времени исполнения и компиляции у слов - является.

Нет. У известных мне Форт-процессоров никаких словарей не было (да и это крайне высокоуровневая фишка для процессора). Да и семантики исполнения/компиляции - тоже. Тоже, слишком высокий уровень. Более того, такое разделение для Форта вообще не является строго обязательным. Полно чисто компилирующих реализаций.

Не может быть признаком Форт-процессора и исполнение шитого кода. Ибо Форт может быть и на прямом шитом коде, и на косвенном, и в нативных машинных кодах, и в байткоде и в чём угодно ещё. И, наоборот, NEXT для шитого кода «как родной» выполняется на PDP-процессорах.

Так что я по-прежнему придерживаюсь подхода, что Форт-процессоры - это мультистековые процессоры, с простым набором примитивов, дешёвой реализацией вызова высокоуровневых слов, арифметикой на стеке и основными операциями работы со стеком (вот тут, скажем, PDP и отпадает).

...

Вот, навскидку, из современных. 40-ядерный Форт-процессор SEAforth 40C18: http://www.intellasys.net/index.php?option=com_content&task=view&id=60&Itemid=75

Каждое ядро на 700МГц жрёт по 9мВт. Суммарных 25млрд оп/с. оно делает по предварительному анонсу в 6Вт, а по спецификации, получается, что и с 0,36Вт. Даже первая цифра очень маленькая, вторая же - совсем фантастическая выходит.

В режиме же ожидания каждое ядро потребляет <5мкВт (0,0002Вт на весь процессор).

Процессоры, вроде, по 40 EUR продаются, но с одного процессора толку мало, а вот кит, в котором идёт мать с поддержкой Midi/Audio, RS232 и USB - $499...

Cat, Joy

Я их чуть выше упомянул. Только в Joy же, вроде, статической типизации нет, только динамика. А так, основной недостаток Joy ветки, недостаточная гибкость языка. После Лисп-макросов и аналогичных средств в Форте Joy и Cat не привлекателен ни для лисперов, ни для фортеров. Простые учебно-академические языки.

>А так, основной недостаток Joy ветки, недостаточная гибкость языка.

Поэтому Форт так туго и развивается. Любые дополнительные механизмы снижают гибкость. А это не нравится FIG.

> А Java всегда выглядит как Java. И это прекрасно.

На вкус и цвет, как говорится.

Хотя да Java хороша для «промышленной разработки» крупными коллективами.

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

С++ — посередине.

Впрочем то, что Java всегда выглядит как Java, можно легко скомпенсировать наличием Scala, Groovy, Clojure, Jython и т. д.

> Поэтому Форт так туго и развивается. Любые дополнительные механизмы снижают гибкость. А это не нравится FIG.

Не в SirongForth гибкость не тау уж сильно и снижена, ИМХО. Я так понимаю ты свой JBForth именно в этом направлении двигать планируешь?

И в Factor с гибкостью всё в порядке (другое дело, что он местами больше похож на Lisp, чем на Forth).

Я так понимаю ты свой JBForth именно в этом направлении двигать планируешь?

Там всё не так однозначно. Да и не продумано до конца всё даже на уровне идеологии, не говоря уже про синтаксис. (Сейчас под JBForth задач нету актуальных, а Форт ради Форта мне сейчас уже не интересен :)).

Скорее всего будет двоякий подход: - Однозначно будет сильное сужение функционала на чистых Java-методах. Т.е. что-то типа (пример достаточно отфонарен):

class complex
  var x
  var y
  : add (( c1 c2 -- c3 ))
    c1 x c2 x +
    c1 y c2 y +
    2 complex new \ 2 - число аргументов конструктора, тут много думать надо...
  ;
end-class

Идеологически определённые «мапинг» на классический Форт будет. Например, классы - словари. Методы классов - слова. Но из-за JVM автоматически вылезают ограничения. Ибо методы ожидаются «честные», с компиляцией в нативный байткод.

При этом безусловно хочется и классического подхода, чтобы и обычная интерпретация работала, и определения слов «без классов»... Соответственно, тут нужно или делать второй транслятор, аналог нынешнего JBForth (тем более, что он будет сильно проще при наличии «нативного» JVM-транслятора), и тогда иметь гибкость классики, пониженную производительность, невозможность выведения типов, или просто делать неявную трансляцию методов в класс [словарь] forth, но тогда иметь ограниченное JVM число слов, отсутствие гибкости...

Короче, пока проблема имеет чисто умозрительный характер. Но понемногу зреет необходимость в таком инструменте сразу с двух сторон и, если дойдёт, то, возможно, JBForth2 состоится. А, может, я к тому времени проникнусь какой-нибудь Scala или Groovy и мне их хватит :)

Я просто не в курсе, а в чём ценность S-выражений?

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

S-выражения, фактически, это ровно такое же представление кода/ланных, как XML, но более компактное (правда за счёт повторения открывающего тега закрывающим XML устойчивее к ошибкам).

> или просто делать неявную трансляцию методов в класс [словарь] forth, но тогда иметь ограниченное JVM число слов, отсутствие гибкости...

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

>Ну с гибкостью не знаю, а ограничение на число слов, наверное, можно преодолеть, просто искусственно разбив слова словаря forth на несколько классов...

Это будет нарушением принципа Форта, выдвинутых во времена 83-го стандарта :) Как можно меньше «умных» слов, поведение которых зависит от контекста.

> Это будет нарушением принципа Форта, выдвинутых во времена 83-го стандарта :) Как можно меньше «умных» слов, поведение которых зависит от контекста.

Это да, но если плясать не от «умных слов» (которые, как правило — суть заплатки), а от «умных словарей», может что то толковое и выйти.

Ну это так, мысли вслух...