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

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

А вот в каноническом форте какэто всё работает? Я имею в виду шитый код. Ведь в конечном итоге интерпретатор интерпретирующий шитый код вызывает машинные подпрограммы. Вопрос такой, откуда эти подпрограммы берутся? Я так себе представляю только два пути. Во-первых подпрограммы реализованые ядром, во-вторых подпрограммы которые ты скомпилировал сам с помощью форт-ассемблера (ну или прямой записью машинных инструкций в память, но это для извращенцев). Если ты в ручную не генерируешь машинный код, то всё что генерирует компилятор это только шитый код, и дополнительному машинному коду там взяться неоткуда. Я прав?

Balancer>Шитый код бывает двух видов - прямой, когда в коде прямо указываются адреса подпрограмм в машинных кодах или адреса ячеек с этими адресами (когда идёт экономия на прологе комиплированных Форт-слов), и косвенный, когда в коде слов указываются не сами эти адреса, а адреса или индексы ячеек, где они хранятся.

Об этом я в курсе =)

Balancer>Т.о., если обеспечить фиксированные индексы слов ядра, то Форт-расширение становится переносимым.[»]

И до этого тоже догадался уже, потребовалось минут 10 =) Ты вобщем то ответил мне на тот вопрос, который я стёр, потому что сам сообразил, а не на тот, который я таки задал =) Повторю вопрос, верно ли что ":" и "DOES>" генрерируют исключительно шитый код и никакого машинного (речь идёт о косвенном шитом коде)?

Balancer>Как говорится, всю жизнь так было, до появления SPF4 [»]

И что нового нам привнёс spf4?

zespri>И что нового нам привнёс spf4?[»]

Первый популярный Forth, генерирующий машинный код

Кирилл>Кстати, ты книгу Броуди Thinking Forth читал?[»]

Я читал её 15 лет назад целиком, и последний год просматривал несколько отрывков что бы отвежить память.

zespri>>И что нового нам привнёс spf4?[»]
Balancer>Первый популярный Forth, генерирующий машинный код [»]

Ага! Глядя на него последние две недели я уж было грешным делом решил, что в фортовом мире генерация машинного кода, практически стандарт =)

Ладно, понемногу фортовская сторона проблемы в голве устаканивается, понадобится ещ несколько итераций, но после. Сегодня думал о дотнетной части. С ней вот какая проблема. Динамическая генерация кода возможна только на уровне класса. Причем в сгенерённый класс уже новых методов не добавить. Хотя существующие изменить можно. (Странно) Я представлял себе что мы будем использовать дотнетный класс как своего рода словарь для не oop слов. Так вот не выходит. Получается что на каждое слово придётся генерить по классу, иначе никак. Перегенерировать класс заново, когда добваляется новое слово катастрофически медленно и жрет много лищнего места. Так что я сейчас пытаюсь провентилировать этот вопрос в clr-ных комьюнитях, о результатах доложу.

zespri>Что плохого вы видите в этой идее?[»]

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

zespri>>Что плохого вы видите в этой идее?[»]
Balancer>Слово может снимать разное число аргументов. В первую очередь по побочным эффектам, конечно, типа глобальных переменных, но, ИМХО, лишать Форт такой возможности - над этим надо сильно думать [»]

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

Откуда ноги растут. Идеи c rtti типами и переключением словарей, конечно здоровские идеи для канонического форта. Но если мы пишем фортоподобный язык под дот нет я бы хотел видеть у него следующие свойства:

1) Возможность без извратов пользоваться любыми уже созданными дотнетными классами
2) Возможность создавать классы которыми без извратов смогут пользоваться другие дотнетные классы

Точно так же как форт накладывает ограничения на реализацию, точно так же и дот нет накладывает свои ограничения. То есть без выполнения 1) и 2) и начинать смысла не имеет.

Далее. Для того что бы вызвать любой дотнетный метод необходимо знать его сигнатуру. Без этого никак. Следовательно надо знать число его параметров. Поэтому когода выполняется слово, то количество его параметров должно быть заранее известно. Я в данном случае представляю, что слова будут реализоваться как дотнетые методы, а не как шитый код. Почему? Всё потому же, я хочу получить язык который может interoperate с другими языками дотнетной платформы, и я хочу избежать написания artificial кода единственным назначением которого является мэпить совершенно не ложащиеся в структкру дотнета фичи языка. Я хочу что бы язык ложился на .net стольже органично как скажем C# и VB.

Я представляю себе это так. На стеке живут не числа а объекты в смысле дот нета. Словарь представляет собой класс со статическими методами. Соотвественно для выполнения слов из текущего словаря не необходимости задавать объект класса, достаточно просто метода и параметров. Для того что бы положить на стек класс необходимо его инициализировать. Для этого будет предназначено слово из стандартного словаря которое будет снимать со стека параметры для конструктора и класть на стек готовый объект. Таким же образом можно будет вызывать методы на верхнем объекте стека, описывать новые объекты состоящие из полей и методов, а так же добавлять статические методы-слова в классы словари.

Это грубая идея. Но это всё не будет работать без того что бы при вызове любого слова не знать на перёд количество его параметров.