Расширяемые ЯП

>Соответственно, объектный drop делает delete для объекта перед его освобождением :)

Любопытно.

Спасибо за информацию.

>Есть работы на тему "обновление Java приложения на лету", вроде

Загрузка классов на лету - это банальщина. Собственно, это один только вызов.

Вопрос в генерации классов. И вот Java (как язык) в рантайме делать это не умеет. Есть внешний command-line компилятор. Есть сторонние решения вплоть до asm. Но это - не полноценный java-eval средствами Java :)

> Думаю, на втором месте идёт LISP. В принципе, в нём тоже можно реализовать подобное, хотя, ИМХО, не так гибко и удобно (придётся напрямую работать с исходным текстом программы). Но тут не спец, т.к. о Лиспе - только общие представления :)

почему "исходный текст"? не текст, а структурные s-выражения, представляющие программу, само синтаксическое дерево (в узлах-то хранятся символы лисп-форм, а не строки исходника). Структура однородная, поэтому макрами её можно расширить в любом месте. То есть, любая макра является комбинатором http://en.wikipedia.org/wiki/Fixed_point_combinator, и поэтому любую часть выражения можно заменить на макру. С типизированными немного сложнее, http://en.wikipedia.org/wiki/Typed_lambda_calculus

> Ну а потом идут уже серией языки с развитыми pattern matching, их можно обучить чему угодно, но это будет просто реализация нового транслятора на имеющемся языке, а не расширение языка

хм, где проходит разница "новый транслятор на старом языке" и "расширение языка"? (сдаётся, что по операционной семантике)

Вот в форте, например, "новый синтаксис другого языка" -- это реализация транслятора или ещё "расширение языка"?

вот например, http://en.wikipedia.org/wiki/Rho_calculus -- это такой навороченный pattern matching -- ещё "расширение языка" или уже транслятор http://rho.loria.fr/implementations.html нового языка, например Tom http://tom.loria.fr/wiki/index.php5?title=Main_Page?

>хм, где проходит разница "новый транслятор на старом языке" и "расширение языка"?

>Вот в форте, например, "новый синтаксис другого языка" -- это реализация транслятора или ещё "расширение языка"?

Ну, пример.

Берём классический Бейсик.

Он отлично ложится на Форт-синтаксис:

10 PRINT "Hello!"

Это совершенно нормальное Форт-выражение. Слово PRINT можем описать в духе:

: PRINT ( n -- \ tail ) ... ;

Возьмёт номер строки, возьмёт хвост, отпарсит его как инфиксное выражение, скомпилирует в бейсик-кодофайл.

Это - явное расширение.

Но вот уже вариант «10 ?"Hello!"» стандартный Форт-парсер не переварит. Соответственно, парсер надо включать уже свой.

> В классическом Форте не хватает типизации переменных. В JBForth1 - типизации по их выводу и кодогенерации

в примерах к MBase (это реализация компилятора компиляторов на лиспе под .NET) есть примеры кодогенерации стекового .NET байткода (Java делается аналогично) и типизации по Хиндли-Милнеру (см. в примерах хаскелевидный DSL statal)

Можно оттуда алгоритм посмотреть.

>Поэтому тут и интересно смотреть на Форт, на котором можно сменять языковой синтаксис в рамках одной программы :)

как это реализовано? Это отрабатывает во время компиляции или запуска?
Кто делает разбор синтаксиса?

просто переключаются словари с "символами" = алфавитом нового языка?

>Ну а гораздо проще реализуются просто чужие языковые концепции в рамках Форта. Lisp-овые списки, Prolog'овые утверждения и т.п... Но это уже не так спортивно :)

любопытно, но оказывается, смысл есть.
http://zedshaw.com/essays/stackish_xml_alternative.html -- перевели XML в форт синтаксис, получили очень быстрый "парсер XML" :))

или вот про протоколы -- там stackish используется для обеспечения корректности протокола: http://savingtheinternetwithhate.com/design.html http://savingtheinternetwithhate.com/stackish.html
(что там Витус Вагнер хотел про "распределённые блоги"? это почти оно)

http://zedshaw.com/projects/earing/index.html -- баловство, но любопытное :)

> CREATE autoinc 0 , DOES> DUP @ 1+ TUCK SWAP ! ;
>Теперь у нас есть слово autoinc, создающее переменные с особым поведением - при каждом вызове они возвращают на единицу большее значение:

лямбды в форте? :)

> Tcl - метаязык, в нём с полпинка можно реализовать любой синтаксис.

не удивительно, если всё хранится как строки, которые просто интерпретируются в разные моменты времени, сейчас или откладывается на потом. Аналогия с лисповыми макрами однако кривая: там настоящие списки из символов, тут -- строки, которые надо разбирать и интерпретировать.

>как это реализовано? Это отрабатывает во время компиляции или запуска? Кто делает разбор синтаксиса?

Просто подключается свой парсер. Вернее, в случае Бейсика - его диалект, адаптированный под Форт (потому этот «Бейсик» и выходит такой крошечный). В случае Си - фиг знает, я в сорцы не заглядывал, но не сомневаюсь, что там включается полностью свой парсер. Который просто тупо тянет входной поток и анализирует его как Си-программу.

> общем, геморрой страшный :) Представь, что надо описать объект
в два десятка полей

Аспекты.
1. Аспекты в Java реализованы (по крайней мере были, когда я туда последний раз смотрел) своей версией компилятора, со своей реализацией classloader
2. См. работы по "обновлению Ява-приложения на лету" аспектами, Сьюзан какой-то (ссылка была выше), она про это ЕМНИП ещё в 2001 писала. Ещё был диплом её или какой-то другой девушки про обновления на лету ООБД на Яве и версии объектов (методы выполняются как транзакции ООБД, после обновления и загрузки новой версии объекта данные, которых не было в старой версии заполняются автоматически)

>Аналогия с лисповыми макрами однако кривая: там настоящие списки из символов, тут -- строки, которые надо разбирать и интерпретировать

и в чём кривость? естественно, что там компиляция и метапрограммирование на уровне AST, а тут интерпретация и метапрограммирование на уровне строк

> ну подумай, когда должна выполнятся статическая проверка типов при наличии eval и возможности подмешивания произвольного кода?

man типизация Хиндли-Милнера, Maybe типы в хаскелле и Null pattern

>> Аналогия с лисповыми макрами однако кривая: там настоящие списки из символов, тут -- строки, которые надо разбирать и интерпретировать

> и в чём кривость?

"Tcl is Lisp on drugs. Using strings instead of S-expressions for closures is Evil with one of those gigantic E's you can find at the beginning of paragraphs" (c)

>лямбды в форте? :)

Не... Это другое. Настоящей лямбды в классическом Форте нет. Есть безымянные слова «:noname ... ;», возвращающие адрес, с которым потом можно что угодно делать, но они «неудаляемые». Т.е. компилируются в память и там остаются навечно :)

В JBForth я отказался от единого кодофайла, каждое слово компилируется отдельно, поэтому ненужные и освобождёные :noname потом вычищает GC. Так уже нормальная лямбда получается. Можно произвольно генерировать и освобождать когда угодно. Для удобства синтаксиса сделал в виде алиасов «[[ код слова ]]»

{ 1 2 3 } [[ 1+ type ]] do-list
234

>Аспекты.

В двух словах можно? Никогда не слышал (по крайней мере под этим именованием) :)

>2. См. работы по "обновлению Ява-приложения на лету" аспектами

Ок, погляжу.

А то я свой PHP-фреймворк понемногу на Java расширять хочу, но пока тормозит надобность в огромной ручной работе. Я ещё после работы с БД в L2J Fortress до сих пор отойти не могу ;)

>>Генерировать классы, кстати, в Java можно

> Но не средствами самой Java :) В смысле - языка. А то и на Бейсике можно машинный код генерировать :)

AspectJ, ЕМНИП на Java написан. Сгенерировали байткод, загрузили своим classloader'ом.

>AspectJ, ЕМНИП на Java написан.

Но это уже не Java :)

Повторюсь, что на любом тьюринговом языке можно написать транслятор любого другого в любой вид. В нативный код, в байткод VM...

Поэтому эта задача не так интересна.

А вот интересны (ну, лично мне в рамках этой дискуссии) языки, которые позволяют (предельный случай) в рамках одног файла описать новый язык и тут же, с какого-то момента в этом же файле исполнить его :)

А просто на Java можно написать транслятор любого другого языка. Хоть 8045-ассемблера :)

>cамый расширяемый - это Форт :)
>Думаю, на втором месте идёт LISP
>Ну а потом идут уже серией языки с развитыми pattern matching

странно, что смоллток забыли. Тоже метасистема, саморасширяемая система написанная на себе самой.

>странно, что смоллток забыли.

У меня о нём очень-очень общие представления. И вживую никогда не видел.

>Тоже метасистема, саморасширяемая система написанная на себе самой.

Насколько я представляю рафинированную логику изначального Смолтока, у него программ как таковых нет? :) Поэтому и моя оценка расширяемости (с включением чужого яыкового кода в свой) непригодна? :)

>> Определение класса - first-class object? >Для большинства использований - да? Объекты класса java.lang.Class...

ну то есть, метаклассы есть?

>При чем тут рефлексия?

Хотя бы при том, что вот в смоллтоке с метаклассами рефлексия реализуется средствами самого языка, методами метаклассов, базового объекта типа "Класс"

>странно, что смоллток забыли. Тоже метасистема, саморасширяемая система написанная на себе самой

написанная на себе самой - ещё не аргумент. новые языковые конструкции с помощью самого языка вводить позволяет?

>man типизация Хиндли-Милнера, Maybe типы в хаскелле и Null pattern

и? все эти вещи я и без того знаю, каким местом они сюда сгодились? как реализовать тиклевскую подстановку со статической типизацией?

>"Tcl is Lisp on drugs. Using strings instead of S-expressions for closures is Evil with one of those gigantic E's you can find at the beginning of paragraphs" (c)

изучение Tcl занимает неделю. изучение CL так или иначе занимает всю жизнь и делает человека безнадёжно красноглазым. так что кто тут on drugs - это ещё хороший вопрос ;)

> кодогенерации стекового .NET байткода (Java делается аналогично)

Есть небольшая разница (не очень существенная, но обидная) - в .net из коробки идет System.Reflection.Emit, а для Java нужна сторонняя библиотека, например BCEL.

Обратно, в пользу Java идет ее Class GC, тогда как в .NET весь когда либо сгенеренный код будет висеть в памяти вечно, что не очень хорошо для динамических языков.

>тогда как в .NET весь когда либо сгенеренный код будет висеть в памяти вечно

Опаньки. Серьёзно??? Тогда моя идея сделать JBForth2 двухплатформенным (.NET/JVM) идёт лесом :)

> изучение Tcl занимает неделю. изучение CL так или иначе занимает всю жизнь

Ну почему сразу CL? Схема тоже лисп, и как язык гораздо приятнее Тикля.

> и делает человека безнадёжно красноглазым

ой да ладно :)

Ёлы-палы, самый главный то пример я и забыл, рядом с которым Лиспы и Форты нервно курят: Prolog! Вот там действительно интересный и полезный на практике подход к метапрограммированию.

> Опаньки. Серьёзно???

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

>рядом с которым Лиспы и Форты нервно курят: Prolog!

Я уже писал, что видел реализации пролог-деклараций в Форт-синтаксисе ещё лет 15 назад :) Даже книжка такая была, что-то типа «Систем ИИ на Форте». Давались примеры (для классического Форта) работы со списками в духе Лиспа, на них - реализация Пролого-подобных предикатов и потом на этом зоопарке уже решения простых примеров экспертных систем и т.п.

>Ну почему сразу CL? Схема тоже лисп, и как язык гораздо приятнее Тикля.

в схеме нет полноценных макр (а значит и метапрограммирования), при этом по уровню "приятности" я бы их поставил на один уровень - где-то одинаковая сложность изучения

>ой да ладно :)

а что, есть сомнения? :)

>рядом с которым Лиспы и Форты нервно курят: Prolog!

Ы :) http://portal.acm.org/citation.cfm?id=37380.37383&coll=GUIDE&dl=GUIDE...

(Use of a Forth-based Prolog for real-time expert systems. II. A full Prolog interpreter embedded in Forth)

Сам не смотрел, просто вторая ссылка в Гугле.

> Я уже писал, что видел реализации пролог-деклараций в Форт-синтаксисе ещё лет 15 назад :)

Я такое сам делал, не проблема. Просто, как бы, Прологи - они разные бывают. Самый тупейший интерпретируемый вариант на любом вменяемом языке в несколько строчек написать можно, и совсем другое дело - полноценный WAM (или более современную машину) реализовать. И уж когда backend у такого Пролога мощный, то и метапрограммирование во время компиляции там будет уместным (а для интерпретатора - какая на фиг разница?).

> Давались примеры (для классического Форта) работы со списками в духе Лиспа,

Опять же, тупой и медленный интерпретатор Лиспа сделать на Форте не проблема (как и вообще на чем угодно, делов-то, eval и apply). А вот высокопроизводительную реализацию, хороший компилятор написать - уже весьма непросто, и средства метапрограммирования Форта тут помогут весьма слабо.

> и в чём кривость? естественно, что там компиляция и метапрограммирование на уровне AST,

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

> в схеме нет полноценных макр

В стандарте нет, а почти в каждой внятной реализации - есть (правда, везде по разному сделано).

>Prolog! Вот там действительно интересный и полезный на практике подход к метапрограммированию

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

>Просто, как бы, Прологи - они разные бывают.

Но к метапрограммированию-то это уже не относится :)

>ну вот в этом самом, что строки ещё и разбирать предже чем интерпретировать надо

это деталь реализации. с точки зрения применения схожесть налицо, не?

> Есть безымянные слова «:noname ... ;», возвращающие адрес, с которым потом можно что угодно делать, но они «неудаляемые». Т.е. компилируются в память и там остаются навечно :)

FENCE FORGET SAVE

MARKER

>неожиданно. можно примеры использования в контексте обсуждения?

Кстати, да. Как в контексте обсуждения встроить кусочек на Бейсике в Пролог-программу? :)

>В стандарте нет, а почти в каждой внятной реализации - есть (правда, везде по разному сделано)

что значительно уменьшает "приятность" языка :) я имею в виду разнобой с реализациями

>FENCE FORGET

Не покатит. Скажем, мне нужно изнутри :noname определять новые обычные слова. И всё, forget в пролёте, старый :noname он уже удалить не сможет.

...

Кстати, первая реализация JBForth у меня работала с классическим монолитным кодофайлом и поэтому была в несколько раз быстрее. Увы, гибкость работы с динамикой заставила переписать ядро. Скорость упала, зато определять/удалять слова можно в динамике в любое время, в любом порядке :)

> Настоящей лямбды в классическом Форте нет.

а если стеки переключать? ну типа есть у каждого замыкания свой отдельный стек и есть глобальный стек стеков, в который эти хвосты octopus tree торчат. То есть, что-то вроде продолжений, возврат из стека одной лямбды в стек другой охватывающей.

>что значительно уменьшает "приятность" языка :) я имею в виду разнобой с реализациями

Кстати, абсолютно та же беда - в Форте :)

Каждый Фортер по мере своего развития, перед тем, как написать собственную Форт-систему, пишет свою реализацию динамических строк, свой объектный механизм... :D

Когда-то и я через это всё проходил :) - http://airbase.ru/misc/forth/

> Теоретически на нём можно реализовать любой синтаксис и использовать разные синтаксические реализации в рамках одного и того же исходного файла.

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

При всём моём уважении к этому языку.

>а если стеки переключать?

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

Хотя если речь о статическом коде - то всё нормально. И с инкапсуляцией извращаться не надо.

> реквестирую учебник Форта :)

Мне помогла официальная дока по gforth. Там хороший учебник, не то что Броди всякие...

> Скажем, мне нужно изнутри :noname определять новые обычные слова. И всё, forget в пролёте, старый :noname он уже удалить не сможет.

MARKER (см.dpans`94, делает возможным для системы помнить "ориентирующую информацию" заранее, которая корректно отмечает места, где словарь может быть перестроен в некотором будущем)

VOCABULARY CONTEXT CURRENT

Поток может быть любым.

>Реально всё, что достаточно далеко уходит от стековой модели, на Форте не делается.

Ну, есть же у нас PostScript :)

...

На практике просто к тому моменту, когда программист на Форте окончательно вызревает и способен писать эффективные бесстековые решения (а также - объекты, строки, сборку мусора и т.п.), ему это всё перестаёт быть нужным :)

> Каждый Фортер по мере своего развития, перед тем, как написать собственную Форт-систему, пишет свою реализацию динамических строк, свой объектный механизм... :D

+1 :D

>Мне помогла официальная дока по gforth

спасибо, посмотрю и её

>>Аспекты.

>В двух словах можно? Никогда не слышал (по крайней мере под этим именованием) :)

AOP, аспектно-ориентированное программирование

http://en.wikipedia.org/wiki/AspectJ http://en.wikipedia.org/wiki/Aspect-oriented_software_development www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.htm (про реализацию)

см. также http://www.garret.ru/abstract.ps.gz http://www.garret.ru/dissertation.ps.gz -- про реализацию аспектами рефлексии для задач ООБД (MOP на С++, реализованный аспектами)