пятничный бред (кастуются специалисты по всему)

декораторы избыточны и следовательно не нужны. imho

Так и монаду изобрести недолго.

описанное в третьем абзаце (считая приветствие) называется tracing jit.

Lisp

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

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

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

Этих двух вещей достаточно для такой фундаментальной вещи, как «распрямление» вложенных вычислений. Потом, этого достаточно, чтобы встраивать в ход вычисления другие действия. Ведь продолжение вычисления - это просто функция.

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

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

Как уже сказано, это похоже на tracing из tracing JIT. Правда, непонятно, зачем это тебе - по-моему, описать «вычислительную схему» на Питоне, напустить на нее стандартный транслятор Питона, и проанализировать выданный им AST гораздо проще. И не нужен ни «очень специальный класс», ни «хитровыкрученный декоратор».

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

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

Возможно dave прав, мне и правда хочется монад - я только не понял пока что это такое;-) Но у нас есть книги про хасссскель;-)

Только предупреждаю, что монада может и не получиться. Самое сложное - это увязать текущее вычисление с его продолжением. Если текущее вычисление имеет тип «m a», вычисляющее сразу несколько значений или одного значение «а», а продолжение есть функция от «а», возвращающая новое вычисление «m b», которое вычисляет «b», то нужно уметь связывать это вычисление и продолжение, на выходе получая вычисление «m b»:

(>>=) :: m a -> (a -> m b) -> m b

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

Возможно dave прав, мне и правда хочется монад

Монада - это только обертка.

Как-то слегка адово звучит. Это вы хотите написать свой Domain-specific language? Со вставками на питоне? Я в этом питоне не очень, текст читал только там где слова знакомые. Но вообще писать DSL это нормально, так часто делают. При должной настойчивости можно здорово облегчить жизнь пользователям (да и разработчикам, наверное). Ну и заодно будет и полный контроль, и AST, и кодогенерация и все что захотите

Вот уж нет, новый ЯП (хоть и DSL) я писать категорически не хочу. Хотя бы потому, что у этого DSL должна быть функциональность конечно не как у питона, но близко к оному - зачем тогда писать DSL если уже есть питон?

Мне показалось что у вас там сплошная математика-физика, то есть наоборот нужно что-то не-императивное. Ну или смесь. Можно же не парсить все, сделать какие-то конструкции внутри маркеров, пропускать через препроцессор. Впрочем, я не очень понимаю специфику, так что это так, очень уж общие рассуждения.

Ну и писать DSL-ы - никакой не рокет-саенс, если точно представлять что нужно, несложный парсер формул за неделю можно написать, наверное.

Вы бы дали примеров что ли, что вы обычно скармливаете машине, что хотите

...скармливать. Хотя, повторюсь, я в питоне не копенгаген, но может у вас от него глаз замылился, а мы тут свежим этимсамым рассмотрим

новый ЯП (хоть и DSL) я писать категорически не хочу.

Внезапно, у Питона есть готовый компилятор в AST - для source-to-source преобразования вполне хватит.

пример (у-е диффузии)

g(0)[.5] = f(0)[0] + D*(Delta_t//Delta_x**2)*( f(-1)[0]+ f(1)[0] - 2*f(0)[0] )
f(0)[1] = g(0)[.5]

А подробней?

http://docs.python.org/2/library/ast.html

Или что именно подробнее? Как из AST сделать снова Python?

Прикольно... спасибо, я о ней не знал.

Кстати, в доке написано, что в Python 2.6 можно компилировать AST прямо в код, так что AST в Python можно и не преобразовывать.

Но тем не менее, речь не идет о source-to-source. Речь идет о генерации source, c участками которые требуют просто source-to-source в общем уже разобрались.

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

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

Как я понял питон тут при том, что можно получить AST ничего не делая, правильно? Ежели так, то вопрос что делать потом. Если я правильно понимаю задачу, то рекомендую ознакомиться с FFTW, например это http://www.fftw.org/fftw-paper-ieee.pdf

Там ребята сделали на OCaml'e оптимизатор быстрого преобразования Фурье.

кто работал во всяких маплах/маткадах/матлабах и проч.

За все маплы не скажу, но у вольфрамовой математики многое очень достойно. Я обычно там делаю все что связанно нетривиальным символьным матаном. Потом генерю сишный код и пользую его из МАТЛАБа, поскольку многие вещи удобнее делать в нем.

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

Я предлагаю как раз второе, а не первое.

Анализ AST это не анализ с-но AST, а получение какой то необходимой информации при его создании.

Эта мысль слишком глубока для меня.

Я предлагаю как раз второе, а не первое.

Тогда я это не уловил.

Эта мысль слишком глубока для меня.

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

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

Как я понял питон тут при том, что можно получить AST ничего не делая, правильно? Ежели так, то вопрос что делать потом.

Именно так. За ссылку спасибо, прикольно.

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

Я бы попробовал в математике. Там работать с символьными выражениями одно удовольствие. Мне кажется, что питоновский подход в итоге окончится переписыванием части математики на коленке. Ведь разбор кода и построение AST, это только начало.

Математика (кроме того что она сцуко платная) и пр CAS решают вообще то совсем другие задачи. Если мне захочется че нить упростить, я просто дерну какую нить maxima. А вот всякие LRnLA-шные фиговины пока CAS вроде как не умеют...

Математика (кроме того что она сцуко платная)

Она не только платная, а хорошо так сцуко платная. А что делать?

CAS решают вообще то совсем другие задачи.

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

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

всякие LRnLA-шные фиговины пока CAS вроде как не умеют

Тут я не копенгаген. Можно несложный пример?

Это наверное Ъ, но у меня наверное руки не из того места растут

Да все нормально, если есть возможность избежать AST то его и избегают. То что вы делаете называется «синтаксически управляемая трансляция» (syntax-directed translation). Ну если я правильно понял. На синтаксические правила навешивают «действия», а в них уже что-то делают. Не уверен что перегрузкой операторов это как-то особенно красиво выглядит, но работает же?

Так что вас не устраивает?

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

Вариант второй - настраиваем все хозяйство так, что необходимая информация накапливается сама при генерации AST

Тогда вариант с пакетом ast отпадает - там выдается уже сгенерированный AST, который нужно обрабатывать visitor-ом.

Она не только платная, а хорошо так сцуко платная. А что делать?

Ну мы вот не пользуемся;-) Хотя Ваш пример впечатляет, но у нас немного другие задачи. Схемы относительно простые, а вот вопрос оптимальной реализации стоит остро.

Тут я не копенгаген. Можно несложный пример?

www.linux.org.ru/wiki/en/User:AIv/LRnLA

Я этим троллю C++-ненавистников;-)

Вам какой-то внутренней красоты нужно? Или не зватает какого-то функционала?

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

Насчет syntax-directed translation Вы меня обрадовали, значит у нас годный лисапед. Насчет перегрузки операторов - ну там все довольно изящно в итоге сделано, питон такое позволяет... все ядро занимало меньше 100 строк.

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

Сейчас в нашей тулзе есть три уровня - пользовательский (файл на питоне со схемой и какими то командами), внутреннее представление данных, и с-но кодогенерация (несколько вариантов как генерить С++ код). Не говоря про дефицит всякой внутренней красоты, кодогенерация выглядит жутко запутанно. Участки числ. схемы втыкаются в нужные места заранее написанных (для каждого варианта кодогенерации) С++ файлов. Хочется упростить до предела кодогенерацию и внутр. представление данных. Соответственно хочется ввести еще один уровень (между первым и вторым) - некоторые конструкции которые будут раскручиваться в С++ циклы, функции, и проч., и на их основе уже описывать код, в который будут втыкаться участки числ. схемы. Т.е. варианты кодогенерации будут описываться в терминах самой же тулзы.

Это несколько успокаивает, но за наводку все равно спасибо.