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

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

Классический Форт никак не может работать с «дырявым» кодофайлом.

Когда-то, когда я был озабочен этим вопросом, я пытался делать расширения кодофайла в heap, но тогда встаёт вопрос созранения готовой Форт-системы в имполняемый бинарник. Мне тогда это было актуально. Дошёл до разработки модифицируемого при Форт-кода (перед сохранением сбрасывать heap-кодофайлы в один центральный и выправлять все адрема), но скоро сложность системы превысила мой интерес к задаче :)

...

Ну а в JBForth у меня задача сохранения монолитной бинарной Форт-системы просто не стояла :)

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

А, я думал, это какая-то реализация оригинального Java-механизма :)

> А вот если, например: function test(arg1) { var x = arg1.Run(); return x.Run(); }

> и при этом классов, у которых есть метод Run, наберётся с пару десятков - то никакого вывода типов тут не будет.

А вот нифига. Почитай статьи про extensible records. Работающие реализации мне неизвестны, но как делать вывод типов в таких случаях - понятно.

В данном случае тип функции test будет чем-то вроде (синтаксис a la Haskell):

test :: (a | Run, b | Run) => (a + {Run :: (b + {Run :: c})}) -> c

Пояснения: a и b - типы записей БЕЗ поля Run; (b + {Run :: c}) - тот же тип, что и b, но с дополнительным полем Run типа c; дальше сами.

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

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

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

вот в примерах к тому же MBase http://lambda-the-ultimate.org/node/2895
есть любопытный пример с шейдерами (tao framework и т.п.): язык notnet вроде C#, записанный s-выражениями (C# на "псевдолиспе", аналогично Objective C на "псевдолиспе" http://programming.nu/ http://github.com/timburks/cocoa-programming-with-nu/tree/master http://github.com/timburks/cocoa-programming-with-nu/tree/master/11_CoreData/...), исполняется лисп-системой.

Система сама по себе платформа для построения компиляторов, то есть, можно разобрать грамматику другого языка (например, чего-то вроде паскаля). Но можно определить и лисповые макры, которые будут синтаксическим сахаром над "notnet" языком ( там в примере с gl> идёт код на OpenGL, "макра" обеспечивает линковку с нужными .NET сборками. В gl коде создаётся код шейдера на Си, компилируется и загружается в видеокарту).

То есть в рамках MBase можно пойти 3 путями:
1. реализовать парсер другого языка в AST, интерпретация AST лисп-системой. Можно прикрутить кодогенератор в .NET/JVM/регистровый байткод (хотя регистровый проще выдавать исходник на LLVM и собирать им)
например, паскалевский синтаксис
2. язык notnet "псевдолисп", интегрированный в платформу (лисп-систему; .NET вызывается через рефлексию)
3. макры к notnet или другому языку из пункта 1 ( изменится порядок основной части, запускать макры из транслятора для обработки AST или из лиспа для обработки лиспа)
4. линковка с отдельной dll сборкой на C#

>язык notnet вроде C# [...] исполняется лисп-системой.

Поясни для Ъ - кусок этого языка может быть встроен прямо в Lisp-сорец?

Т.е., вот, у нас обычная программ на lisp'е, но внутри неё - небольшой кусок на этом notnet'е? Естественно, гармонично взаимодействующий с системой :) Вызовы, переменные и т.п.

>Насколько я представляю рафинированную логику изначального Смолтока, у него программ как таковых нет? :)

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

> Поэтому и моя оценка расширяемости (с включением чужого яыкового кода в свой) непригодна? :)

http://www.smalltalk.ru/blog/2008_07_01_smalltalk-ru_archive.html -- смоллток, компилируемый в Си

Кстати, интересное про браузеры, VM и смоллток:
http://smalltalk.ru/2008/09/smalltalk.html http://www.smalltalk.ru/2008/09/smalltalk_21.html

Seaside довольно интересный web-framework для Смоллтока, на continuations

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

легко. Пишешь свой новый класс объектов -- это и будет новая языковая конструкция. if(e) then do-t else do-nil в смоллтоке -- это посылка сообщений объекту выражение с параметрами блок (замыкание)
(e) ifTrue: [do-t] ifFalse: [do-nil]

Всё -- это объект. Блок кода -- это замыкание, объект. Выражение -- это объект. Правила динамической типизации (обработки сообщений) -- это объект (метакласса) (вообще-то одно сообщение :doesNotUnderstand, на которое можно навесить диспетчеризацию для прокси-классов, RPC, и тп.). Можно расширить конкретный экземпляр объекта на лету новым методом, не трогая остальные этого класса и т.п.

>в каком смысле нет?

Так изначально Смолток, насколько я понимаю, задумывался как интегрированная система. IDE+среда исполнения+готовый продукт.

Т.е. написание программы шло чисто интерактивное с сохранением результата.

>ну наподобие форта

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

И только уже со второй половины 1990-х (!) годов в Форт массово входят обычные файлы исходников.

Я помню ещё, как писал парсер простых файлов для того же Фортиуса и как меня одно время бесила принципиальная ограниченность работы с plain/text :)

...

Хотя, вполне допускаю, что нынешние Смолток-реализации тоже имеют очень мало общего с изначальными :)

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

>Всё -- это объект. Блок кода -- это замыкание, объект.

Тогда smalltalk-like реализации других языков столь же возможны, что и forth-like.

А что с подменой парсера для «чистой» реализации?

Т.е. наша гипотетическая предельная задача - вставка в середину исходника куска кода на чужом языке? :)

http://www.smalltalk.ru/articles.html

Вообще, Черезов часто при реализации тех или иных механизмов в SP-Forth ссылался на влияние Smalltalk'а.

>А что с подменой парсера для «чистой» реализации?
>Т.е. наша гипотетическая предельная задача - вставка в середину исходника куска кода на чужом языке? :)

http://ru.smalltalk.wikia.com/wiki/%D0%9F%D1%83%D1%82%D0%B5%D0%B2%D0%BE%D0%B4...

(не надо мне предлагать ставить FF3, стоит уже. Копипастил из Seamonkey )

> все эти вещи я и без того знаю, каким местом они сюда сгодились?

ну вот в лиспе макра "применима" к любому элементу списка, s-выражения. Потому что является комбинатором в смысле http://en.wikipedia.org/wiki/Fixed_point_combinator , и форма записи в списках обеспечивает однородность.

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

> как реализовать тиклевскую подстановку

тиклевская из простых строк как раз не очень интересна, давай я туда засуну инъекцию какую-нибудь, и всё накроется тазом? Значит, понадобится парсер. Значит, его лучше запускать во время компиляции. Значит, ему нужен какой-то стандартизированный интерфейс между компилятором и "макрами". Значит, нужен какой-то паттерн, как его применять.

> так что кто тут on drugs - это ещё хороший вопрос ;)

забегает лось в бар. Мне, говорит, водки 30 грамм, а дури и своей хватает. :))

>http://www.smalltalk.ru/articles.html

Прикольно, но первый же пример не особо удачный :)
Не смог удержаться:

<?php

function mama_sort($s)
{
    usort($a = explode(' ', $s), create_function('$a, $b', 'return preg_replace("/[^a-z]/","",$a) > preg_replace("/[^a-z]/","",$b);'));
    return join(' ', $a);
}


echo mama_sort('ma79ma 9n8e7 mila r1a2m3u');


==> ma79ma mila 9n8e7 r1a2m3u

:)

Две строки против 7 на Смолтоке :)

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

а то я думаю, зачем вручную gacutil запускался

>не надо мне предлагать ставить FF3

А он и не поможет. Он адресную строку рисует правильно, а если копировать оттуда, то копирует url-encoded :)

> А, я думал, это какая-то реализация оригинального Java-механизма :)

не, это как раз пример, когда не получилось обойтись чистой pure Java и пришлось писать свой classloader, компилятор для рефлексии и кодогенерации и т.п.

Еще Io, не? Самое что ни на есть определение языковой конструкции "чтоп по типу как в питоне" http://github.com/stevedekorte/io/tree/master/samples/misc/Brackets.io

>Еще Io, не?

Интересно, но, как я понимаю, все эти squareBrackets, curlyBrackets - предопределённые конструкции языка?

Могу ли я, скажем, ввести синтаксис:

<?php echo 2*2; ?>

определив конструкции "<?php" и "?>" ? :)

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

начиная с Tcl Core 8.0 именно так

>тиклевская из простых строк как раз не очень интересна, давай я туда засуну инъекцию какую-нибудь, и всё накроется тазом? Значит, понадобится парсер. Значит, его лучше запускать во время компиляции. Значит, ему нужен какой-то стандартизированный интерфейс между компилятором и "макрами". Значит, нужен какой-то паттерн, как его применять.

вообще не понял хода мысли. парсер там естественно стоит, интерпретатор гоняет eval поверх так или иначе генерируемых строк; почему "лучше во время компиляции" - непонятно, Tcl в принципе не может быть компилируемым, ему необходим полноценный интерпретатор в рантайме для работы; чтобы всё не накрылось тазом любой вызов eval (т.е. по сути любой фрагмент кода) можно обернуть в catch

>Значит, ему нужен какой-то стандартизированный интерфейс между компилятором и "макрами"

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

>Поясни для Ъ - кусок этого языка может быть встроен прямо в Lisp-сорец?
>Т.е., вот, у нас обычная программ на lisp'е, но внутри неё - небольшой кусок на этом notnet'е? Естественно, гармонично взаимодействующий с системой :) Вызовы, переменные и т.п.

посмотри примеры, они вкусные :)
конкретно, MBase/examples/notnet/{sdl.al,sdl.rl,tao_ogl_shaders.al}

sdl.al -- "основная программа", грузит из лиспа sdl.rl в паскалевском синтаксисе.
tao_ogl_shaders.al -- основной модуль, написан на notnet плюс макрос (lltnet-macro gl> lst ..), который берёт хвост в s-выражениях, преобразовывает его назад в строку, её разбирает pattern matchin'ом и преобразовывает назад в лисповое s-выражение (чтобы слинковалось с нужной сборкой)

Итого:
1. программа на лиспе
2. notnet -- язык на лиспе, c семантикой C# и .NET объектами (вызываются лисп-системой через рефлексию)
3. программа на паскале или другом синтаксисе преобразуется в лисп лексером и парсером (на этом лиспе лисп-системы).
4. Ещё см. в MBase/examples/csharp/cstest.{al,cs} пример как это линкуется вместе из отдельных dll

>интерпретатор гоняет eval поверх так или иначе генерируемых строк;
>любой вызов eval (т.е. по сути любой фрагмент кода)

во! именно что любой. А если я в строке, которая скармливается eval'у засуну инъекцию вроде как в SQL [anything' OR 'x'='x], например [x' AND 1=(SELECT COUNT(*) FROM tabname); --] ?

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

> откуда такой вывод - непонятно.

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

>обработка кода на уровне строчного представления - это и есть Tcl. если это убрать, это будет уже совсем другой язык

ну то есть, если буквально на уровне строк, то типов и чётких интерфейсов расширения нет

>А если я в строке, которая скармливается eval'у засуну инъекцию вроде как в SQL

неудачная аналогия. подстановку описывает сам программист, т.е. он полностью контролирует данный этап, ошибки синтаксические/семантические отлавливаются eval'ом и ловятся catch'ем - а для случая работы интерпретатора как сервера для произвольного кода есть Safe Tcl, в котором отсутствуют потенциально опасные в смысле злокозненности вызовы

>потому что если интерфейса нет (хотя бы примитивного, как шаблоны C++ -- там проверяются типы заодно) -- то подставить можно всё что угодно

именно. в этом и есть мощь языка - ограничений на подстановку нет, язык в смысле строк является гомоиконным (код и данные одного типа), а стало быть никак не ограничивает возможности по расширению. как пример - чтобы реализовать в умеренно типизированном C++ механизм, аналогичный передаче сообщений Tcl (bind, -command), надо этой типизированности так или иначе лишитсья (без boost.any, boost.variant, или препроцессорных механизмов а-ля Qt не обойтись)

> подстановку описывает сам программист, т.е. он полностью контролирует данный этап

тут соседняя тема про хранение переменных в конфигах. А вот автор tkLOR'а ЕМНИП так конфиги и грузил, eval'ом

> ошибки синтаксические/семантические отлавливаются eval'ом и ловятся catch'ем

каким "catch'ем для SQL" поймать инъекцию в SQL ? не пойдёт, нужно писать или свой парсер или SQL statement prepare с placeholder'ами

> стало быть никак не ограничивает возможности по расширению

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

> как пример - чтобы реализовать в умеренно типизированном C++ механизм, аналогичный передаче сообщений Tcl (bind, -command), надо этой типизированности так или иначе лишитсья

это беды недостаточно гибкой модели С++, где простой делегат - функтор обрастает большим сахаром в виде указателя на метод класса. Вот в смоллтоке например и сообщения есть и строки уже проинтерпретированы, не надо разбирать вручную каждый раз; или CLOS. Один раз уже разобрано в универсальную модель данных (списки или объекты или стек), а потом различия только в семантике.

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

Не уж то, как всегда, спивается? :(

> А если я в строке, которая скармливается eval'у засуну инъекцию вроде как в SQL

Ты считаешь, что ЯП не должен давать программисту прострелить себе ногу?

> Ты считаешь, что ЯП не должен давать программисту прострелить себе ногу?

Должен давать, но программа от этого не должна вылетать с ошибкой. По крайней мере, пока программист не ПОСМОТРИТ на свою простреленную ногу.

Это я про Хаскель с его ленивыми вычислениями.

>А вот автор tkLOR'а ЕМНИП так конфиги и грузил, eval'ом

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

>каким "catch'ем для SQL" поймать инъекцию в SQL ?

обсуждается Tcl, а не SQL. я к тому, что аналогия с SQL здесь несколько неуместна

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

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

>где простой делегат - функтор обрастает большим сахаром в виде указателя на метод класса

по-твоему дело в этом? ну сделай реализацию на свободных функциях, будет интересно посмотреть. упаковывать разнотипные данные при вызове всё равно придётся, независимо от объектной ориентированности решения

>Вот в смоллтоке...или CLOS

я ошибаюсь, или оба (Smalltalk и CL) - динамически типизированы?

>По крайней мере, пока программист не ПОСМОТРИТ на свою простреленную ногу

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

>Не уж то, как всегда, спивается? :(

ну или убивает жену, да

>> По крайней мере, пока программист не ПОСМОТРИТ на свою простреленную ногу

> а если он сделает это слишком поздно, когда иного выбора кроме ампутации уже не останется

А можно меньше метафор и больше конкретных примеров? А то вроде говорите о чем-то интересном, но ни хрена не понятно.

> а если он сделает это слишком поздно, когда иного выбора кроме ампутации уже не останется - хотя сразу после выстрела достаточно было бы бинта и антибиотиков? :)

Ъ-языки ТАК не промахиваются.

>А можно меньше метафор и больше конкретных примеров? А то вроде говорите о чем-то интересном, но ни хрена не понятно

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

>Ъ-языки ТАК не промахиваются

а КАК они промахиваются? ошибкой времени выполнения в случае если при паттерн-матчинге пропущен один из конструкторов АТД? :)

> ну а когда он нам таки понадобился

Не "когда", а "если".

> а КАК они промахиваются?

Во всяком случае, если Ъ-язык стреляет тебе в ногу, ты одним аспиринчиком не отделаешься.

>Не "когда", а "если"

да, это я не упомянул, каюсь; однако кроме этого сценарий остаётся прежним

>Во всяком случае, если Ъ-язык стреляет тебе в ногу, ты одним аспиринчиком не отделаешься

страшно спрашивать, чем же в таком случае стоит запасаться :)

> страшно спрашивать, чем же в таком случае стоит запасаться :)

(загробным голосом) Поздно.

>(загробным голосом) Поздно.

*накрылся плащ-палаткой и пополз на кладбище*

>Ты считаешь, что ЯП не должен давать программисту прострелить себе ногу?

Слишком радикальное сравнение. Но, в общем случае, перила на балконе быть обязаны :)

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

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

В .NET это сделано немного через одно... место. Хотя есть своя концепция. Ключевая фраза - Application Domain. В общем, сгенеренный код нужно загружать в отдельный домен, а в конце этот домен полностью выгружать вручную. Неприятность состоит в том, что домены изолированы, и при пересылке данных между ними есть заметный оверхед. Видимо, в Java с этим проще.

> Ты считаешь, что ЯП не должен давать программисту прострелить себе ногу?

если мы при этом не целимся в ногу, то нет :)

> обсуждается Tcl, а не SQL. я к тому, что аналогия с SQL здесь несколько неуместна

аналогия в том, что модель "подставлять переменные как строки в общее выражение (SQL или Tcl, не важно)" -- неудачная.
Почему вообще возникает инъекция? Потому что есть один слой с переменными и есть другой слой с текстовыми запросами. Если при этом подставлять переменные просто как текст, то нарушается семантика исходной модели где не надо (расширяется семантика такой текстовой переменной -- она была просто значением, а стала любым текстом), что позволяет протащить любой запрос, или сорвать стек если строка -- не в буфере с заданным размером.

> по-твоему дело в этом?

не в этом, а в том, что расширение модели через текст+интерпретатор излишне гибкое, что позволяет нарушить семантику модели

> ну а когда он нам таки понадобился, мы выполняем действия, обнаруживаем их ошибочными - а времени на то, чтобы эту ошибку корректно исправить, уже нет

стоп. А откуда ошибочные действия взялись? Если "вместо выполнения каких-то действий, откладываем их до тех пор, пока их результат нам не понадобится" -- то эти действия должны быть подобраны безошибочно :)

>> ошибки синтаксические/семантические отлавливаются eval'ом и ловятся catch'ем

>каким "catch'ем для SQL" поймать инъекцию в SQL ? не пойдёт, нужно писать или свой парсер или SQL statement prepare с placeholder'ами

то есть, catch не пройдёт, потому что при расширении модели нужно контролировать целостность семантики выражения, а он не умеет -- вызовется только если синтаксическая ошибка, семантические ошибки с корректным синтаксисом оно пропустит

> 2. язык notnet "псевдолисп", интегрированный в платформу (лисп-систему; .NET вызывается через рефлексию)

Там не рефлексия, там более хачный вариант: этот лисп, по аналогии с древним MuLisp-ом, позволяет вставлять ассемблерные конструкции в код (.net ассемблер, конечно же). Соответственно, низкоуровневые языки (макры) можно разворачивать сразу в низкоуровневый код. Макра (n.asm (переменные) код), внутри кода (expr переменная) вставляет значение переменной внешнего окружения. Код должен или возвращать значение, или оставлять на стеке ровно один элемент, приводимый к System.Object.