Forth - язык нового поколения :)

zespri>Как ни как дотнет без строгой типизации никуда

Интересно, как в дотнете реализован тот же Perl.NET? В Перле, ведь, никакой типизации

А, вообще, разве в MSIL обязательна строгая типизация? ИМХО, нет. Преобразование типов - это уже забота более высокого уровня. Хотя, правда, никакой приличной документации по MSIL я ещё не видел.

Кстати, мысли по Forth.NET можно посмотреть на http://wiki.forth.org.ru/ForthNetImplementationIssues

zespri>Я перла не знаю. Совсем.

Ну, там три типа данных. Переменная, массив и ассоциативный массив (хэш)

zespri>Моя догадка, что там это отсутвие типов тоже абстракция между перлом и его реализацией на дот нете, в этом случае перфоманс не так уж и важен

В принципе - да.

zespri>Кстати о каком перле идёт речь?

Сам не щупал, но имел в виду ActiveState Downloads for Perl, Python and Tcl Languages, IDE and Dev Kits

zespri>Вот цитата из ecma:

Ну что могу сказать - стандарт Форта давно пересматривать надо
Я, кстати, и в до-.NET времена подумывал о Форте со строгой типизацией.
А также с узаконенными удобными локальными переменными, нерекомендацией использования переменных глобальных, по возможности - предельно автоматизированная сборка мусора и т.д и т.п.

ИМХО, всё это в .NET реализовать можно. По стандарту это будет уже не Форт. По духу/идеологии и синтаксису - он.

zespri>С этим я могу помочь.

Спасибо, посмотрю, как будет время.

Balancer>Ну что могу сказать - стандарт Форта давно пересматривать надо
Balancer>Я, кстати, и в до-.NET времена подумывал о Форте со строгой типизацией.
Balancer>А также с узаконенными удобными локальными переменными, нерекомендацией использования переменных глобальных, по возможности - предельно автоматизированная сборка мусора и т.д и т.п.
Balancer>ИМХО, всё это в .NET реализовать можно. По стандарту это будет уже не Форт. По духу/идеологии и синтаксису - он.

Это не совсем понятно. Очень многие книжки по форту как раз хвалятся тем, что нету строгой типизаци проверок, етц, таким образом, говорят они, форт и является тем чем есть - очень гибким инструментом котрый может всё.

Я о форте знаю давно. Первый раз в мои руки он попал я думаю в 90 году ещё. Он всегда мне был инетерсен и я про него читал и думал, но вплотную никогда не занимался.

Что такое есть форт? Я имею в виду форт по духу, а не по стандарту. На мой взгляд он сводится именно к memory layout, который в каждой реализации разный но принцип один и тот же плюс организация словарей, что по сути всё тот же memory layout.

Что же будет, если реализовать строгую типизацию в форте? Что от него останется? Как при строгой типизации будет выглядеть стек? Что из себя будут представлять Cellы? Если это будут типизованые объекты, то запись 1 + будет кидать эксепшн в большинствет случаев, потому что на стеке инты будут встречаться редко....

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

Так что же такое форт по духу?

zespri>Так что же такое форт по духу?

1. Построение новых средств языка средствами языка. Т.е. метаязычность. В первую очередь - простая организация CREATE-конструкций разного уровня сложности
2. Линейность анализатора кода
3. Стековая передача данных по ходу исполнения

Про типы в моём представлении о форте ничего не сказано

Ну где в нём самоценность 1+? CELL+?

Арифметика в Форте всегда была его ахилесовой пятой и от типизации integer'ов мы ничего особо не потеряем. Для перемещений по указателям - нам этого вполне хватит. Таже можно прямо указать, что <pointer to object> <int> + - это смещение указателя на object на int позиций

Форт изначально создавался как способ ускорить разработку программ. Кстати, вот нулевой пункт в вышеприведённом списке:

0. Максимальная декомпозиция задачи и её построение снизу-вверх.

Именно от этого плясал в своё время Мур. Хотя этот подход можно реализовывать и в любых других языках, но только в Форте он ставится целью. Вот и пишу уже лет 10 на других ЯВУ в стиле Thinking Forth

Да, а методика определения, что мусор, а что нет - это краеугольный камень алгоритмизации сборщиков мусора и Форт-специфичных проблем я тут не вижу. Строки и память у меня автоматически заводились и чистились лет 8..9 назад, когда в мэнстриме о сборке мусора и не говорилось, я и книг-то по ней тогда не читал

2 zespri
Под "в Форте можно все" подразумевается и возможность введения строгой типизации

Balancer,

спасибо, пока не готов ответить подробно, потому как серьёзно задумался. А пока оставав в стороне вопрос нужен ли форту (то есть не форту, а нашему гипотетическому языку) ООП я просто спрошу нужен ли ему оверлоадинг функций (те поддержка функций с одинаковым именем и разными сигнатурами) ?

zespri>А пока оставав в стороне вопрос нужен ли форту ООП

ИМХО - нужен
Обязательно

Ставить сегодня вопрос "нужен ли языку ООП" сродни вопросу "нужны ли языку циклы"

>я просто спрошу нужен ли форту оверлоадинг функций?

Конечно. Тем более - Форту. Чтобы для проблемно ориентированной надстройки не придумывать свои уникальные имена.

2 zespri
И оверлоадинг тоже реализуется на Форте: на пару с ООП. Причем вполне профессиональная реализация - студенческая курсовая (а курс 2-3 ), если не лабораторная

Balancer>ИМХО - нужен

Очень быстрый ответ =) Я даже отредактировать вопрос не успел =)

Опять таки, товарищ вот по тому линку, в wiki, жалуется на то что оверлоадинг на концепцию форта ложится плохо. И я вот тоже в уме и так и этак прикидываю и не вижу как. Я правда не знаком с существуюшими oop имплементациями форта, но я вскорости взгляну на них. А с обще-разумной точки зрения, имя функции - это слово форта, сигнвтура, это то что написано в стековой нотации. И я ума не приложу как без неестественностей сказать форту что должно использоваться слово с таким именем которое берет со стека 3 параметра и возвращает 1 а не то которое берёт 5 параметров и возвращает два.

zespri>А с обще-разумной точки зрения, имя функции - это слово форта, сигнвтура, это то что написано в стековой нотации. И я ума не приложу как без неестественностей сказать форту что должно использоваться слово с таким именем которое берет со стека 3 параметра и возвращает 1 а не то которое берёт 5 параметров и возвращает два.

Вариантов два.

Можно переключать контекст словаря. Но это годится только для типов, вычисляемых при компиляции. Подав слову объект неизвестного типа так легко не отделаешься.

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

2 zerspi
На стадии компиляции - контекстные словари рулят (как правильно сказал камрад Balancer). На стадии исполнения - RTTI в Форте легко реализуется штатными средствами.

Balancer>А слева - в моём понимании смотреть надо только верхний элемент стека. Если будет внутри слова работа со следующими элементами - так и там будет RTTI и тоже каждая функция свой тип знать будет.

Это интересно. Это сужает немного привычное (для меня) понимание оверлоадинга, но это будет работать. Хочу поблагодарить за очень дельные ответы. Ответ на вопрос "в чём суть форта" особенно понравился - был очень в точку.

Теперь про контекстные словари. Я к сожалению не знаком с концепцией использования различных словарей для реализации оверлоадов, поэтому очень хотелось бы представить себе общую идею. Каждый из таких словарей, он содержит (грубо говоря) все слова с данным набором аргументов? И когда появляется новый слово с набором аргументов для которого словаря пока нет, этот словарь создаётся и оно туда заносится, так?

Если же смотреть тип только верхнего элемента стека, то всё проще, по словарю на тип.

А что происходит во время исполения? Кто переключает контекст словаря? Сам форт?

То есть во время компиляции мы знаем тип значения. Когда и как мы переключаем словарь?

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

Если задача высокой производительности позволяет сменить идеологию языка, то я бы лучше рекомендовал O'Caml. По производительности это сейчас рекордсмен, но при этом жесточайшая типизация, функциональность (хотя и с приличной императивностью, объектами и т.п.), мощный синтаксис, многие вещи через который в нём реализуются намного проще, чем даже в Форте

Правда, сам я на него не только не перелезаю, но даже и не изучал (кроме общей идеи, написания тестов и т.п.). Мне в последние годы и Форт-то не нужен, Perl да PHP - выше крыши хватает

zespri>Это интересно. Это сужает немного привычное (для меня) понимание оверлоадинга, но это будет работать. Хочу поблагодарить за очень дельные ответы. Ответ на вопрос "в чём суть форта" особенно понравился - был очень в точку.

Просто этой проблемой я занимался когда пытался Форт на Win95 реализовать. И для упрощения написания программ, естественно, реализовывал и всякие автоматические строки, и объекты писать Годы прошли, но мысли-то остались.

zespri>Теперь про контекстные словари. Я к сожалению не знаком с концепцией использования различных словарей для реализации оверлоадов

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

Работу сильно облегчает то, что компилятор в Форте не занимается забеганием вперёд. Слова разбираются последовательно, одно за другим. Т.е. можно реализовать такую систему, когда каждый конструктор класса (он всё равно будет IMMEDIATE) автоматически переключает контекст словаря и идущие за ним слова будут браться уже для работы с этим типом. Каждое слово, если возвращает объект фиксированного типа, тоже переключает словарь на этот тип. Если тип неизвестен - то общий словарь, где слова уже занимаются RTTI. При чём это скорее не полные слова (зачем нам иметь два набора кода - RTTI-шный и обычный?), а заглушки на вызов слов уже конкретного типа.

zespri>Каждый из таких словарей, он содержит (грубо говоря) все слова с данным набором аргументов?

Тех, работа которых зависит от конкретных типов - да.

Если же нет (само слово от типов не зависит, а вызывает только другие) - то достаточно "общего" слова.

zespri>И когда появляется новый слово с набором аргументов для которого словаря пока нет, этот словарь создаётся и оно туда заносится, так?

Нет, словари делаются по типам. Создаём новый тип - создаётся и новый словарь для его слов.

zespri>Если же смотреть тип только верхнего элемента стека, то всё проще, по словарю на тип.

Да, именно так. А следующие аргументы будут аналдизировать уже слова, находящиеся внутри нашего слова.

zespri>А что происходит во время исполения? Кто переключает контекст словаря? Сам форт?

Нет, это всё выполняется на этапе компиляции. При исполнении Форт словарями никак не рулит.

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

Вообще, базу "табличного RTTI" можно посмотреть на примерах в Язык программирования Forth
Только учти, что библиотека пятилетней давности и я ей с того времени так и не занимался. И ни одного практического решения на ней не сделал Как раз в то время ушёл на Perl.

zespri>То есть во время компиляции мы знаем тип значения. Когда и как мы переключаем словарь?

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

Balancer>Только учти, что библиотека пятилетней давности и я ей с того времени так и не занимался. И ни одного практического решения на ней не сделал Как раз в то время ушёл на Perl.

Ага, cпасибо, обязательно посмотрю, есть вопросы по тексту, но это уже завтра с утра, сейчас спать пора. Я вообще то постоянно возвращаюсь к этой идее, подружить форт с дот нетом. Или хотя бы нарисовать у себя в голове картинку, как это могло бы быть. Как ты знаешь реально на неоплачиваемый проект редко хватает энтузиазма довести до конца. Так вот около года назад я уже игрался с этой идей и в конце концов отлжил её как совсем бесперспективную. Но сейчас эта мысль вернулась ко мне снова. К сожалению знаний форта не хватает для того что бы отшлифовать всё хотя бы в голове. В твоём лице нашел большую помощь!

zespri>Как ты знаешь реально на неоплачиваемый проект редко хватает энтузиазма довести до конца.

Ну, вот этот сервер штука целиком не оплачиваемая

zespri>В твоём лице нашел большую помощь!

Всегда рад помочь, т.к. Forth.NET мне тоже интересен.

Кстати, хочешь ещё идею, которую я продумываю?

Пишем ядро Форта на C# или C++

Реализуем косвенный шитый код с фиксированными словами ядра.

Делаем компиляцию программ в виде подшивки этого кода к бинарнику (или в лоб или в виде ресурса).

Получаем переносимую на уровне кода систему (а в случае C# - так и на уровне конечного бинарника) для реализации которой не требуется даже знать, как устроены бинарники на нужной платформе

Да, насчёт идей. Было бы очень здорово реализовать SQL на Форте да ещё TCP/IP, и чтоб вся эта связка (собственно Форт+SQL+TCP/IP) работала на голом железе... Интересно, за год такое можно написать одному человеку?
::)))

2 zespri
> Мне вполне хватает интеллекта, что бы понять, что невозможных вещей в современном мире программирования практически нет.
> Посему просьба, очень хотелось бы побольше конкретики, так как в сообщениях Balancer'а. Например, я бы был очень рад услышать (либо получить толковую ссылку) как именно на стади исполнения RTTI в форте реализуется штатными средствами.
В том-то все и дело, что конкретную реализацию каждый может сделать сам под свои нужды. Я в своем движке сделал "смолтолковский" механизм отправки сообщений. Каждому сообщению соответствовал уникальный целочисленный код (генерируется автоматически при определении сообщения), тело слова-класса содержит DMT (массив кодов сообщений, на которые откликается объект данного класса) и VMT (массив cfa слов-методов). Слово-сообщение при исполнениии получает адрес объекта, извлекает оттуда адрес класса (хранится по смещению 0), находит в теле класса свой код и вызывает соответствующий метод. Реализация занимает меньше места, чем этот текст.
К чему такой длинный пассаж? Да к тому, что Форт очень хорошо приспособлен для описания каких-либо абстракций путем создания расширения языка. Дело не в том, что какую-либо задачу можно решить вообще, дело в том, что если задача решается путем известного расширения (изменения) языка, то реализация на Форте больших трудностей не представляет (в отличие от большинства ЯВУ, где модификация языка требует специальных знаний и коллективноой работы). Это связано с примитивностью Фортовых компилятора и интерпретатора и абсолютной расширяемостью - заменить и дополнить можно абсолютно все.
> Ещё раз напоминаю, что я не имел целью обидеть. Заранее спасибо.
Даже мысли такой не возникло. И Вы совершенно правильно начали решение задачи - определили то, чего в языке не хватает. Теперь можно определить конструкции, которые надо внедрить в язык. Вот Форт с таким дополнением (и, возможно, исключением ряда слов для прямого доступа к машине) и будет Вашей версией Foth .NET