JBForth2

Кирилл — 2007-09-04T09:34:42+01:00

Не покатит. Это модификаторы Java-методов

Почему же? Если главное, чтобы для JVM генерились корректные методы и классы, то это возможно при любом синтаксисе, необязательно Явовском. Т.е. при помещении слова в словарь final - оно может быть точно так же скомпилировано в байт-код как final-метод, как и при указании java-модификатора.

Опять же, это принципиальный для Java вопрос.
Мы же собираемся генерировать нативные Java-классы.

Собственно генерировать ничто не мешает А static или нет - видно по первому же параметру слова.

Он форт как форт, совершенно типичный, хотя и не очень стандартный.

А хочется Форт быстрый и на JVM

Дальше »»»

JBForth2

Balancer — 2007-09-04T08:31:21+01:00

Кирилл> С точки зрения отделения интерфейса от реализации а также Форт-идеологии лучше будут словари public, static, final.
Не покатит. Это модификаторы Java-методов
Кирилл> Кстати, static можно выкинуть - в Форте между явным и неявным self особой разницы нет.
Опять же, это принципиальный для Java вопрос.
Мы же собираемся генерировать нативные Java-классы.
Кирилл> А не надо из Форта Яву делать
А тогда у нас уже есть JBForth-1 Он форт как форт, совершенно типичный, хотя и не очень стандартный.

Дальше »»»

JBForth2

Кирилл — 2007-09-04T07:58:05+01:00

Вкратце распиши, а то гуглить некогда

Вкратце - типы переменных выводятся из выражения, а значит "стековая нотация" в большинстве случаев необязательна! В ОСАML, Haskell и т.д. именно так
Например : AVERAGE + 2 / ; автоматически протипируется как ( int int — int)
просто исходя из типов + и /
Если не баловаться с полиморфизмом на нижнем уровне (а Форт-идеология как раз такая!) - то все просто.
Потом можно и побаловаться - будет куда сложнее (или эквивалент шаблонов или передача неявного аргумента с указателем таблицы операций), зато получится выразительность типизированных функциональных языков реализованная в компактном императивном.
"Стековая нотация" однако полезна - для самодокументирования, усиления контроля компиляции, а также определения локальных переменных.
А ведь мы так даже Хаскель кое в чем уделаем - необязательным ок…

Дальше »»»

JBForth2

Balancer — 2007-09-04T07:01:00+01:00

Кирилл> с системой типов Хиндли-Милнера
Вкратце распиши, а то гуглить некогда
...
А на счёт исключений - их реализовывать придётся, полагаю, в любом случае.
И надо думать над красивым синтаксисом аргументов слов. Первое, что в голову приходит - это использовать комментарий с параметрам, заданный де факто, но теперь сделать его обязательным по стандарту:

code forth

public static : str_repeat ( String:arg1 Integer:arg2 - String )

\ ...

;

Нужен набор модификаторов - public, private, static, final. По умолчанию, полагаю, нужно делать просто private.
Непонятно, что делать с режимом исполнения. Ибо д…

Дальше »»»

JBForth2

Кирилл — 2007-09-04T03:57:28+01:00

Еще один довод в пользу Форта со статической типизацией: большинство слов с переменным числом аргументов на стеке (тот же ?DUP) делают двойную работу по принятию решения и ухудшают читабельность текстов программ.
Слова же, возвращающие флаг - бледное подобие исключений... костыль неполной реализации конструкций структурного программирования.
А если замечтаться, в воображении появляется Форт с системой типов Хиндли-Милнера

JBForth2

Balancer — 2007-08-27T06:25:23+01:00

Кирилл> А как насчет решения проблемы дороговизны вызовов через макрооптимизацию, как в SPF?

Это уже на практике можно будет подумать. Ибо там это не так гладко будет, как в SPF. У JVM свои ограничения.

Кирилл> Еще в Ява-форте можно ввести модули, эквивалентные Ява-классам. Тогда вызовы внутри модуля будут быстрыми, а "наружу" - гибкими.

Да, где-то так и задумывается.

JBForth2

Кирилл — 2007-08-26T13:05:22+01:00

А как насчет решения проблемы дороговизны вызовов через макрооптимизацию, как в SPF?
Заодно и специальных INLINE-слов не понадобится...

Еще в Ява-форте можно ввести модули, эквивалентные Ява-классам. Тогда вызовы внутри модуля будут быстрыми, а "наружу" - гибкими.

JBForth2

Balancer — 2007-08-17T06:21:34+01:00

Кирилл> Кстати, с точки зрения дисциплинирующих ограничений такой Форт будет ближе к массам, чем классический.
Да, массам нужна жёсткость
...
Кстати, ещё мысль. Нормальную работу со стеком внутри определений можно реализовать в CODE-словах, которые будут просто инлайниться в компилируемое слово. Вернее, CODE-слова надо оставить как есть, а реализовать, скажем, INLINE.

code forth

: word1 ( arg1:type1 arg2:type - result:type3 )

\ код высокоуровневого слова

;

CODE word2 ( arg:type - result:type )

\ низкоуровневый код JVM

…

Дальше »»»

JBForth2

Кирилл — 2007-08-17T05:37:59+01:00

- Делать 100% "Java-форт" со всеми ограничениями JVM. Т.е. для каждого слова будет определён фиксированный тип аргументов. Теряем капитально совместимость с классическим Фортом (скажем, слова, типа ?dup будут принципиально невозможны), но приобретаем скорость и "нативный" байткод.

ИМХО самый интересный вариант.
Ибо не противоречит Форт-идеологии с одной стороны (меньше "умных" слов) и позволяет контроль стека при компиляции ("стековые комментарии" в середине слова помогут отловить ошибку ДО выполнения). И лаконичности не мешает - типы и количество аргументов высокоуровневого слова однозначно вычисляются по его определению.
Кстати, с точки зрения дисциплинирующих ограничений такой Форт будет ближе к массам, чем классический.

Дальше »»»

JBForth2

Balancer — 2007-06-17T08:01:04+01:00

fixed

JBForth2

Murkt — 2007-06-16T15:55:25+01:00

статус

JBForth2

Murkt — 2007-06-15T15:40:04+01:00

Насчёт входных параметров:

code python

def myfunc(a, b, c=5, *args, **kwargs):

print (a, b, c, args, kwargs)

*<название кортежа> - это неименованные параметры, **<название словаря> - именованные.

code python

# с - значение по умолчанию, "лишних" нет

…

Дальше »»»

JBForth2

Murkt — 2007-06-15T15:24:16+01:00

Я имел в виду, что ты в метод передаёшь вроде как ограниченное и чёткое количество аргументов, но на самом деле столько, сколько тебе надо. То есть, положить на стек вызываемой функции массив (это ведь не полноценный объект, по идее должно быть быстро) со стопкой параметров, а на выходе отдавать тоже массив, и его ты тоже можешь варьировать так как тебе надо - хочешь, без элементов вообще, хочешь - десяток.
Я себе слегка так представил - в принципе, сделать можно, и работать должно быстрее, чем с действително внешним стеком. Хоть это и будет небольшой rocket science.
Я бы посоветовал сначала сделать с полноценным внешним стеком, а потом попробовать сделать с фейковым (как я вот сказал), так как преждевременная оптимизация
В Питоне все входящие параметры сворачиваются в кортеж и словарь. По мере надобности, я думаю - если я не передаю именованных параметров, то словарь по идее не должен создаваться (во внутренних механиз…

Дальше »»»

JBForth2

Balancer — 2007-06-15T08:42:01+01:00

Расскажи вкратце, но... Вариант с "внешним" стеком будет не сильно быстрее нынешнего, увы :-/ Разве что только бонус будет в написании именно полноценных .class и генерации .jar
...
В принципе, возможно, это будет самый компактный JDK Форт-система размером под несколько сот килобайт сможет генерировать полноценные .jar
...
А так - конечно, можно будет сделать дуальную систему. Когда можно будет определять два вида Форт-слов. С фиксированным числом аргументов в нативном коде и с внешним стеком.

Дальше »»»

JBForth2

Murkt — 2007-06-15T08:24:56+01:00

ИМХО, лучше медленнее, но с полными возможностями.

Насчёт входящих-выходящих параметров (точно заданное количество, один на выходе) - может есть смысл их просто заворачивать во что-то, как это в Питоне делается? Если хочешь, расскажу как заворачивается.

JBForth2

Balancer — 2007-06-15T07:35:01+01:00

Murkt> Или сам расскажи
В двух словах там, действительно, всё просто. Есть байткод (типично Фортовский, кстати, стековый - DUP/SWAP/ADD и т.д.). Каждому методу при вызове формируется отдельный стек и область локальных переменных. И то и другое - заказанного размера. Аргументы метода - тоже локальные переменные. Соответственно, в байткоде есть операции чтения такой переменной. Или field'а какого-либо класса. Или вызова статического или виртуального метода. И т.п.
Проблемы в том, что нет общего стека на всю систему. JVM сама снимает для вызываемого метода со стека аргументы. Соответственно, и число аргументов всегда фиксированное. Возвращаться может только одно значение. Хотя прописаться может с любого места.
Сейчас вижу три (выше писал - два) выхода:
- Делать глобальный стек в виде отдельного класса, как сейчас в JBForth. Но тогда, во-первых, сильно снизится скорость (грубо говоря вм…

Дальше »»»

JBForth2

Balancer — 2007-06-15T07:23:06+01:00

Буду базироваться на ASM - Home Page

Но проблем ожидается масса. Как технологических, так и идеологических.

JBForth2

Murkt — 2007-06-15T07:21:57+01:00

Или сам расскажи

JBForth2

Murkt — 2007-06-15T07:21:32+01:00

Меня это давно интересует - генерация кода на лету, или же трансляция (форт -> джава). Дай ссылок, пожалуйста

JBForth2

Balancer — 2007-06-11T20:14:17+01:00

Ковырялся сегодня, наконец, на тему Java-байткода. Т.е. по поводу возможности компиляции JBForth в байткод JVM.
Пробные примеры получатся.
Огорчение - у каждого метода свой стек. Ограничиться им теоретически можно, но это не оставит от Форта ничего, кроме синтаксиса А оно нам нафиг не надо...
Похоже, придётся делать таки отдельный глобальный стек.
Таким образом от нативной производительности остаются опять рожки да ножки.
Хотя, естественно, будет возможность генерации нативных для JVM классов и методов. Так что критические куски кода можно будет писать на JVM-функционале.
...
В общем, перспективы интересные, но работы предстоит чудовищное количество

Дальше »»»