LINUX.ORG.RU

[FFI] CL крут

 


1

3

В каком высокоуровневом языке еще есть такой FFI, или хотя бы возможность его создания?

http://github.com/Lovesan/virgil

//gcc -std=c99 -shared -o virgil_examples[.dll/.so] virgil_examples.c
#include <stdio.h>

typedef void (*matrix_callback)(float* matrix, int m, int n, void* param);

void print_matrix(float* matrix, int m, int n)
{
    for(int i = 0; i<m; ++i)
    {
        for(int j = 0; j<n; ++j)
            printf("%g ", matrix[i*n+j]);
        printf("\n");
    }
}

void foo (float* matrix, int m, int n, matrix_callback f, void* param)
{
    print_matrix(matrix, m, n);
    f(matrix, m, n, param);
}
(deftype matrix () '(simple-array single-float (* *)))

(define-foreign-library virgil-examples
  (t (:default "virgil_examples")))

(use-foreign-library virgil-examples)

(define-external-function "foo"
    (:cdecl virgil-examples)
  (void)
  (matrix (& (simple-array single-float) :inout))
  (m int :aux (array-dimension matrix 0))
  (n int :aux (array-dimension matrix 1))
  (callback pointer)
  (param (& float :in t) :optional void))

(define-callback add-number
    void ((data pointer) (m int) (n int) (param (& float :in t)))
  (with-value (matrix data `(simple-array single-float (,m ,n)) :inout)
    (let ((param (if (voidp param) 0.0 param)))
      (dotimes (i m)
        (dotimes (j n)
          (incf (aref matrix i j) param))))))

(defun main (matrix)
  (declare (type matrix matrix))
  (format t "~&Matrix:~%~a~%" matrix)
  (force-output *standard-output*)
  (foo matrix (get-callback 'add-number) 1.0)
  (format t "~&After processing:~%~a" matrix))
* (defparameter *matrix* (make-array '(4 4) :element-type 'single-float
                           :initial-contents '((1.0  2.0  3.0  4.0)
                                               (5.0  6.0  7.0  8.0)
                                               (9.0  10.0 11.0 12.0)
                                               (13.0 14.0 15.0 16.0))))
;;==> *MATRIX*

* (main *matrix*)
;;на stdout ==>
Matrix:
#2A((1.0 2.0 3.0 4.0)
    (5.0 6.0 7.0 8.0)
    (9.0 10.0 11.0 12.0)
    (13.0 14.0 15.0 16.0))
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
After processing:
#2A((2.0 3.0 4.0 5.0)
    (6.0 7.0 8.0 9.0)
    (10.0 11.0 12.0 13.0)
    (14.0 15.0 16.0 17.0))
Даже питоновский ctypes и рядом не валялся, особенно в плане производительности.

Ответ на: комментарий от Love5an

> В крайнем случае всегда можно через FFI что-нибудь сишное подергать

Для этого реально надо уметь читать код на C, что могу не все. Кроме того, если человек не пишет на C постоянно, то поиск подходящей библиотеки не на самую горячую тему тоже может оказаться ещё той задачей.

Вообще, ситуация с библиотеками выправляется, но фактически она вынуждает всегда быть «на острие» (в терминологии RoR). Но быть «на острие» далеко не всем по душе, а в том же Python по многим задачам вполне можно полагаться на старые стабильные решения, пусть они и «одной ногой в могиле».

archimag ★★★
()
Ответ на: комментарий от Love5an

> Или в каких библиотеках не хватило возможностей(«коцаные»)?

Я выше написал CommonQt - не умеет грузить .ui файлы.

Если Qt, то Qt - чисто плюсовое поделие, и для CL не нужно.

«Не товорите мне что делать, и я не скажу куда вам надо идти» Нужно было Qt.

С Gtk я в своё время навозился по самое «нехочу» и меня эта библиотека не устраивает. lambda-gtk и cl-gtk2 cлишком низкоуровневые, а cells-gtk имела кучу проблем на x86-64.

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

«Отучаемся говорить за всех» (C)

trivial-socket никто, конечно, не отменял. А вот покажите ка мне нормальный ORM. cl-perec только в Git - т.е. релиза пока йок.

Да и про cliki.net со товарищи я в курсе.

В результате предыдущий проэкт был сделан на Scala + QtJambi. Сейчас внимательно смотрю на Ruby, благо мне uber-производительность не требуется. Великолепная вещь Visual Works Smalltalk но его Gui чужеродно выглядит везде кроме WinXP.

Darkman ★★★
()
Ответ на: комментарий от psv1967

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

это может даже быть на уровне eDSL имитирующего операторы распространённого тянутого языка.

Пока на такой «педагогический эксперимент» сил (коварности) не у кого не хватило.



навалом таких вариантов, на самом деле. Во-первых, схемы всякие, racket (require algol60/algol60),
или Gambit SIX http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Scheme-infix-syntax-ext... , guile http://www.gnuvola.org/software/guile/doc/Reading-Infix.html

во-вторых, в сторону питона: sweet expressions http://www.dwheeler.com/readable/ или I-expressions http://srfi.schemers.org/srfi-49/srfi-49.html
или CLPython http://common-lisp.net/project/clpython/ + Python on lisp http://common-lisp.net/project/python-on-lisp/

в-третьих, алгольный синтаксис: тот же Rlisp из REDUCE или более отдельные языки, см.Special syntax for various constructs http://www.dwheeler.com/readable/readable-s-expressions.html — тысячи их, на самом деле.
Из них более-менее самостоятельных языков (не использующих рантайм и модель компиляции/выполнения CL/Scheme) мало.
Немного выделяется из всего зоопарка Dylan: в нём чётче разделены компайл и рантайм поведение — разный набор модулей для компилятора и выполнения (в отличие от CL, но немного примитивнее, чем в Scheme). Scheme имеет нормальные модули с чётко разделённой фазой компиляции/выполнения, описанными в стандарте. Поэтому макросы на схеме «более модульны» в отличие от макросов на CL, которые могут выполнится и при eval и при load (или нужны костыли eval-when). В целом Scheme ближе находится к multi-stage programming вроде MetaOcaml, чем к CL и backquote syntax.



anonymous
()
Ответ на: комментарий от Darkman

>trivial-socket
Вот твое упоминание trivial-socket как раз и выдает, что на CL ты ничего особо не пробовал писать.
Потому что: 1) usocket 2) iolib

cl-perec только в Git - т.е. релиза пока йок.

Вам шашечки или ехать?
Это же касается «Нужно было Qt». Потому что нужно обычно как бы задачу решать, а не определенные библиотеки.

cl-gtk2 cлишком низкоуровневые

cl-gtk2 достаточно высокоуровневая. Там даже управление памятью автоматическое. Да, пованивает самим GTK, но это все-таки биндинг к GTK.

Love5an
() автор топика
Ответ на: комментарий от archimag

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

основной вопрос — зачем им выбирать другой язык, если старый устраивает. Чтобы выбор в сознании выбирающего воспринимался как полезный, он должен потыкаться, попробовать, но это «настолько сложнее». Проблема в том, что он не видит настолько существенной разницы, чтобы менять шило на мыло.
Если профит от смены языка будет подсознательно восприниматься как КАЧЕСТВЕННО лучший на порядок (в тех местах, где старый не устраивает), выбор будет сделан. Проблема в том, что такой качественной разницы не видят — для этого надо самому потыкаться, попробовать.

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


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

anonymous
()
Ответ на: комментарий от paranonymous

У меня вот в ходе именно этой беседы возникла следующая идея, как сделать подобно Паскалю (надо сказать, уже далеко не первая попытка)

Нужно сделать пакет Z, комфортабельно импортирующий всё, что можно, из пакетов A,B,C. Делаем макрос

(def-comfortable-package Z (:use* &rest ABC) &rest other-defpackage-options) ...)
который: берёт пакеты A,B,C, вычисляет все clashes между ними. Каждое имя из clashes он интёрнит в спец. пакет :clashed-symbols. И генерирует форму
`(defpackage Z (:use ,@ABC) 
  (:shadowing-import-from :clashed-symbols ,@clashed-symbols) ,@other-defpackage-options
Перешибаем (read) так, чтобы при попытке считать символ из пакета :clashed-symbols выдавалась ошибка (наиболее осторожная политика, хотя можно, например, брать самый первый подходящий символ по порядку пакетов ABC). Read у меня уже давно перешиблен и сделать такую проверку для меня как два байта.

Сейчас я пользуюсь точно таким же методом, только вместо use он использует :import-from с явным перечислением импортируемых символов, а это значит, что при добавлении новых символов они не попадут в зависимые пакеты до того, как их определения будут перекомпилированы. С другой стороны, мой теперешний метод работает и без перешибания (read). Видимо, нужно просто добавить второй метод в мой нынешний макрос.

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

Интересно, а это разве не из-за ООП?

(Я прошу прощения у LoveSan за офтопик и если мне сказано будет убраться, то я заведу другую тему. Просто тема была обычной закваской для очередного лиспосрача, а я попытался вместо этого обсудить интересное и полезное).

den73 ★★★★★
()
Ответ на: комментарий от psv1967

> загрузил модуль «пролог» --- имеешь операторы пролога, загрузил питон --- «питон».

в той же схеме Racket с define-syntax так и обстоит : #lang: prolog, #lang: algol68, и т.п. Питона вот только на схеме не видно, но можно clpython портировать.

anonymous
()
Ответ на: комментарий от Darkman

> lambda-gtk и cl-gtk2 cлишком низкоуровневые

Вы, конечно, сравнили lambda-gtk и cl-gtk2. Как минимум, первое из них уже много лет как не запускается.

По моим представлениям, уровень абстракции в cl-gtk2 чуть выше, чем в других биндингах к Gtk+ (например, pygtk или Gtk#). Если это не так, то буду рад услышать ваши конкретные комментарии на этот счет и те моменты, которые вам показались низкоуровневыми.

Например, в cl-gtk2 вы не увидите ни одного указателя, а лишь объекты и структуры. Можно создавать свои классы виджетов, и для них доступен весь функционал CLOS.

dmitry_vk ★★★
()
Ответ на: комментарий от Darkman

> Даже врапперы как правило коцанные и не поддерживают всех возможностей нижележащей библиотеки - как пример можно сравнить CommonQt и QtRuby/Korundum.

сравни, мне интересно. В CommonQt врапперы генерируются с помощью KDE-шного smoke. В QtRuby, насколько я вижу по korundum-3.5.5/qtruby/rubylib/qtruby/Makefile.am, тот же smoke.

В чём отличаются по возможностям CommonQt и QtRuby?
Насколько эти отличия критичны для тебя?

anonymous
()
Ответ на: комментарий от den73

> как сделать подобно Паскалю (надо сказать, уже далеко не первая

попытка)


Еретик.

Интересно, а это разве не из-за ООП?


С ООП в CL таких проблем не возникает.

archimag ★★★
()
Ответ на: комментарий от anonymous

Делать «что-то поверх чего-то» - это всегда потери. Половину своих страданий от синтаксиса лиспа я устранил макросом proga:

(proga 
  (let a 1)
  (flet f (x) (+ x 1))
  (with-my-construct); расширяемо
  (do-something) 
  )
=> 
(let ((a 1))
  (flet ((f (x) (+ x 1)))
     (with-my-construct 
        (do-something))))
Вторая половина связана с рекордами и её устранить сложнее, я сделал лишь вот так:
(let-with-conc-type ; название рабочее,потом поменяю.
  x my-rec (make-my-rec :a 1 :b 2)
  (+ x.a x.b))
=>
(let ((x (make-my-rec :a 1 :b 2)))
  (declare (type my-rec x))
  (+ (my-rec-a x) (my-rec-b x)))
И это снимает примерно половину второй половины проблемы.

Третья проблема связана с генерацией кодов на других языках. Идею решения (пришедшее далеко не сразу) я выкладывал: просто пишется лексер целевого языка, а в него лишь подставляются кусочки, сгенерённые лиспом. Практика показала, что этот метод - самый правильный. Однако, для отдельных случаев, сохранился и другой метод, который более «лисповый» и чем-то подобный format. Сейчас некогда его описывать, приведу пример:

(pds `(",(" a ("" q r 45) b (concatenate string "v" "eee")))
=>
"(A,QR45,B,veee)"
Думаю, более менее понятно.

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

den73 ★★★★★
()
Ответ на: комментарий от archimag

> С ООП в CL таких проблем не возникает
Ну канешна. И ещё молочные реки с кисельными берегами.

den73 ★★★★★
()
Ответ на: комментарий от den73

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

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

Есть люди типа Дмитрия Иванова, респект им и уважуха, конечно.


А вот с ним у меня отношения как-то уж совсем не сложились, так что подписываться под этим не будут.

archimag ★★★
()
Ответ на: комментарий от archimag

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

А вот с ним у меня отношения как-то уж совсем не сложились

Я говорю не про личность (лично только парой писем обменялся), а про достижения.

Завязывай с паскалём, до хорошего он не доведёт ;)

Тогда и с зарплатой придётся завязать, видимо. Паскаль - хороший язык. Уж точно лучше, чем С++. Т.е., на нём действительно можно программировать. Я сейчас подумываю, как бы встроить компилятор в runtime. Во всяком случае, есть интерпретаторы паскаля, в которые прекрасно биндятся все компоненты. Я даже поигрался с этим немного, выглядит перспективно. Однако, похоже, что с некоторыми ограничениями можно и нормальный компилятор встроить (по образу gcl/ecl, через разделяемые библиотеки). Для меня это было бы избавлением от основной боли Паскаля - невозможности итеративной разработки уже запущенной программы. Как в Лиспе, конечно, всё равно никогда не будет, но можно добиться неплохого приближения. Зато на Паскале можно писать программы реального времени без оговорок и он пролезает даже на самые мелкие платформы без большого урона.

den73 ★★★★★
()
Ответ на: комментарий от den73

> а про достижения.

А что за достижения такие особые?

Уж точно лучше, чем С++.


Спасибо, тема C++ vs Pascal была для меня актуальна лет 7 назад, я был (и остаюсь) не на стороне Pascal, но затевать разговор на эту тему больше не хочу. Хотя и честно думал, что паскаль уже окончательно похоронили.

archimag ★★★
()
Ответ на: комментарий от Love5an

Кстати, давным-давно, первый вариант LDX примерно таким и был.
То есть, тупо ковыряем поинтеры, и вообще, все как в C++, только на лиспе.

Love5an
() автор топика
Ответ на: комментарий от Love5an

>> Вот твое упоминание trivial-socket как раз и выдает, что на CL ты ничего особо не пробовал писать.

Потому что: 1) usocket 2) iolib

1) dev-lisp/trivial-sockets 2) Я не работаю с сокетами из лиспа - для этого есть C и Ada

Вам шашечки или ехать?

Git это заранее unstable, со всеми вытекающими. Я вон взялся писать генератор CL кода из .ui QtDesigner'a для CommonQt, так при очередном обновлении часть функций уехала из :export, а часть - переименовалась. Плюнул и написал проект на Scala. У меня есть сроки, и тратить время на бодание с нестабильностью и велипедоквадратоколёсостроительство я не могу и не хочу.

Где _стабильный_ ORM ? У Franz ? Угу, с их ценами и лицензией. :/

Это же касается «Нужно было Qt». Потому что нужно обычно как бы задачу решать, а не определенные библиотеки.

Как в Gtk с аналогом 'QString QTextEdit::toHTML()' ?

Darkman ★★★
()
Ответ на: комментарий от den73

я конечно понимаю, что у тебя много кода уже написано на CL.
Но интересно, а может быть схема подошла бы больше ?
тут вроде бы нормальные модули http://www.jazzscheme.org/tutorials.htm и какой-то жуткий ынтырпрайс http://www.jazzscheme.org/screenshots.htm  — эклиспа на схеме (Gambit, но переделанный)
вообще, было бы интересно от тебя услышать про scheme vs. cl для твоих задач.

anonymous
()
Ответ на: комментарий от archimag

> А что за достижения такие особые?
http://www.ystok.ru/
Человек сделал (видимо, стабильный) бизнес на CL, вот и достижения. С моей точки зрения, немало. Я мог в своё время сделать примерно так же, как он (я занимаюсь автоматизацией предприятий), но обосрался, а теперь, наверное, уже стал староват. И главное, я теперь не вижу в CL решающих преимуществ, чтобы идти этим путём.

Но интересно, а может быть схема подошла бы больше ?

Схема - она какая-то игрушечная, что ли. Я пробовал её не раз, но всё время утыкался в игрушечность и бросал. Например, важнейшая вещь - это keyword arguments. Её в Схеме отроду нет (не было на время смотрения), а прикрученное всегда хуже родного. Также важны continuable errors, а в схеме вроде такого понятия нет? Важны исключения, а в схеме вместо них call/cc, которое вообще позволяет всё вывернуть наизнанку и нарушить вложенность стека. Если там кто-то рекламирует что-то Ынтырпрайзное, то это пока что - только реклама. В реальных возможностях лиспа я уже на практике убедился и они меня устраивают для тех задач, которые я на него возлагаю (поддержка жизненного цикла СУБД, генерация различного кода, скрипты и конверторы).

den73 ★★★★★
()
Ответ на: комментарий от dmitry_vk

Вы, конечно, сравнили lambda-gtk и cl-gtk2.

В своё время (-rw-r--r-- 1 darkman ssmtp 7681 Сен 9 2008 gtke.lisp) только lambda-gtk и работала. Ох я тогда с gtk_tree_model намучался. Сейчас, да - проще.

По моим представлениям, уровень абстракции в cl-gtk2 чуть выше, чем в других биндингах к Gtk+ (например, pygtk или Gtk#). Если это не так, то буду рад услышать ваши конкретные комментарии на этот счет и те моменты, которые вам показались низкоуровневыми.

cl-gtk2 - Сишный код 1:1

(button (make-instance 'gtk:button :label "Hello, world!"))
(gobject:g-signal-connect button "clicked"
    (lambda (b) .....)

RubyGtk

quittb = Gtk::ToolButton.new(Gtk::Stock::QUIT) do 
	signal_connect "clicked" do ..... end
end

Надеюсь разница в стиле видна сразу ?

Вот тоже на QtRuby:

button = Qt::PushButton.new('Quit') do
	connect(SIGNAL :clicked) do ... end
end

Darkman ★★★
()
Ответ на: комментарий от anonymous

> В чём отличаются по возможностям CommonQt и QtRuby? Насколько эти отличия критичны для тебя?

CommonQt не умеет грузить .ui файлы - это очень критично. Про написание генератора я отписался выше.

Darkman ★★★
()
Ответ на: комментарий от den73

> Однако, для отдельных случаев, сохранился и другой метод, который более «лисповый» и чем-то подобный format.

чем-то похоже на META (lisp) http://portal.acm.org/citation.cfm?id=1093417 http://www.cliki.net/meta и OMeta http://tinlizzie.org/ometa/ (Smalltalk,js,C#,scheme/lisp,etc).
Оно (Ometa, Meta, PEG etc) — не очень быстрый парсер, но более гибкий. То есть больше подходит для редкой генерации и частого исполнения сгенерированного.
А для OMeta есть такое: http://www.vpri.org/pdf/m2008001_parseback.pdf
Профит в том, что унифицированно можно переводить с одного языка на другой, описав только их грамматики (правда, языки должны быть семантически близкие, всё должно быть в дереве).
И что для добавления нового генератора достаточно добавить только грамматику нового парсера.
ещё интересная статья
http://www.vpri.org/pdf/tr2010003_PEG.pdf
довольно старая http://www.merl.com/papers/TR93-17/
«As an example, it shows how the pretty printer can be used to print a subset of Lisp as Pascal»

anonymous
()
Ответ на: комментарий от anonymous

> интересно. Вот cl-smoke вроде бы должен это уметь: http://tobias.rautenkranz.ch/darcsweb/darcsweb.cgi?r=cl-smoke/qt.examples;a=h... http://tobias.rautenkranz.ch/darcsweb/darcsweb.cgi?r=cl-smoke/qt.examples;a=h...

«Ownership transfer to / from C++ of non QObject objects is seldom known to cl-smoke. E.g.: cl-smoke might delete an instance even though it is still needed by C++.»

«Method calling is near 3000 times slower than native C++.»

Darkman ★★★
()
Ответ на: комментарий от anonymous

>только lambda-gtk и работала

cl-gtk2 появилась позднее.

Ох я тогда с gtk_tree_model намучался.

Могу только заметить, что в cl-gtk2 с tree model все проще.

Надеюсь разница в стиле видна сразу ?

Ну ни разу не видна. Есть разница в синтаксисе: do вместо lambda, new вместо make-instance, Gtk::ToolButton вместо gtk:tool-button. А так - одно и то же - создается объект, устанавливаются свойства, привязываются обработчики.

dmitry_vk ★★★
()
Ответ на: комментарий от den73

Её в Схеме отроду нет (не было на время смотрения), а прикрученное всегда хуже родного.

Странно это читать, учитывая твои костыли вокруг отсутствия человеческих модулей.

anonymous
()
Ответ на: комментарий от dmitry_vk

> gtk_text_buffer_serialize

Эээ... А сериализатор самому писать или он готовый есть ?

Darkman ★★★
()
Ответ на: комментарий от Love5an

Каким местом?

Прямым:

(gtk:container-add window v-box)
(gtk:box-pack-start v-box search-box :expand nil)
(gtk:box-pack-start search-box search-entry)
(gtk:box-pack-start search-box search-button :expand nil)
(gtk:box-pack-start v-box scroll)
(gtk:container-add scroll slots-list))

Darkman ★★★
()
Ответ на: комментарий от Love5an

Ты вроде когда-то с PEG занимался. Хочешь свой личный питонолисп? Нагугли/напиши PEG грамматику питона и воткни её в http://www.vpri.org/pdf/tr2010003_PEG.pdf , примеры к статье http://piumarta.com/S3-2010/.
Прикрути это в какой-нибудь лисповый PEG, cl-peg http://www.cliki.net/cl-peg или pegc через SXEmacs http://blog.s11n.net/?p=70  — вот тебе и будет питон в лиспе/или standalone, если по первой ссылке.
Батареек сразу не будет, конечно, но тут можно каким-то python on lisp выкрутиться, и взять питоновые.

anonymous
()
Ответ на: комментарий от dmitry_vk

> А так - одно и то же - создается объект, устанавливаются свойства, привязываются обработчики.

Тогда почему gtk:box-pack-start, gtk:container-add вместо методов соответствующих обьектов ?

Darkman ★★★
()
Ответ на: комментарий от den73

> Я не еретик, а скорее печенег,

язычнег!! вечно тебя готовые языки не устраивают :)

anonymous
()
Ответ на: комментарий от den73

> Я сейчас подумываю, как бы встроить компилятор в runtime. Во всяком случае, есть интерпретаторы паскаля, в которые прекрасно биндятся все компоненты.

у Луговского в MBase http://www.meta-alternative.net/mbase1.0beta6.zip есть паскалевский синтаксис в дотнете — это *.rl файлы в примерах.
Вообще судя по доке
http://www.meta-alternative.net/pfdoc.pdf http://www.meta-alternative.net/mbase1.0beta6.pdf  — MBase это компилятор DSL под .NET с PEG парсером + несколько встроенных синтаксисов (паскаль, .Net), генерирующий standalone .exe под .NET без лишних зависимостей.
Правда, ЕМНИП, не было манифестов под какую версию дотнета его конпелятор, поэтому что-то может не работать под конкретной версией, надо смотреть более свежие беты.
Я не знаю где раздают свежие беты MBase, наверно где-то в раёне оффсайта.

Ну а так, можно в принципе прикрутить ту же лисп/схему + PEG парсер паскаля и генерировать через C компилятор или LLVM+C, вопрос в том, как наиболее компактно это сделать

anonymous
()
Ответ на: комментарий от Darkman

мда, я так понимаю наиболее здравая идея с Qt — это взять EQL http://password-taxi.at/EQL и ecls, и что не помещается в лисп, перенести в С++ код.

anonymous
()
Ответ на: комментарий от archimag

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

anonymous
()
Ответ на: комментарий от Darkman

>Тогда почему gtk:box-pack-start, gtk:container-add вместо методов соответствующих обьектов ?

А это и есть методы объектов. Я же говорю, то же самое тут происходит.

dmitry_vk ★★★
()
Ответ на: комментарий от anonymous

А для OMeta есть такое: http://www.vpri.org/pdf/m2008001_parseback.pdf Профит в том, что унифицированно можно переводить с одного языка на другой, описав только их грамматики (правда, языки должны быть семантически близкие, всё должно быть в дереве).

Да, это прикольная концепция, только я скорее буду писать для этого свой велосипед, скорее, чем брать что-то чужое. «Своё г не пахнет». И нужно чётко понимать границы применимости этого метода. Во-первых, часть макросов (например, генерирующие код с использованием метаданных БД) необратимы по определению и без них жить очень скучно. Дальше, я занимался переводами с языка на язык, и имхо при объёмах кода меньше мегабайта это нужно делать полувручную, и с помощью контекстных замен. И конкретно сейчас я занят переводом системы с 1С на Delphi/Firebird, хорошо видно, что эта задача трудно поддаётся автоматизации ввиду очень больших отличий в рантайме. Например, в 1С код на клиенте, а мне нужно его распределить между клиентской и серверной стороной, которые имеют разный функционал. Кроме того, в подобных системах код - это далеко не вся спецификация программы. В 1С есть язык запросов, он мощнее, чем SQL и я не возьмусь написать автоматический транслятор с него на SQL (тем более, что и структура базы отличается). Имеются ещё экранные формы и формы отчётов, в неописанном формате. И например, есть проблема такого рода: в 1С идентификаторы в кириллице, произвольной длины, в Firebird - в кириллице, небольшой и ограниченной длины, в Delphi - только латиница. Т.е., основные проблемы в переводе с языка на язык - вовсе не в грамматике.

Кстати, ещё один примерчик моего старого генератора

BUDDEN 17 > pds `(progn (cond (("=" 5 5) (setf x 4)) (t (setf y 5))))
"
  BEGIN
  IF(5=5)THEN 
      BEGIN
      X=4;
      
      END
     ELSE 
    BEGIN
    Y=5;
    
    END
   
  END
"
Но я пользуюсь этим довольно редко. Отступы, ессно, было лень проставлять. Основная неприятность тут - это неосуществимость прыжка от ошибки компилятора целевого языка к месту исходника в лиспе. Новый генератор (который fbody, постил выше), даёт такую возможность в 80% случаев. Причём, если код порождён макросом, то по замыслу, можно попасть и в тело макроса, и в точку его вызова. Хотя иногда поглючивает.

anonymous
()
Ответ на: комментарий от anonymous

den73

А, кстати, meta-parse я пользуюсь для лексера. Он меня устраивает. Но недостаток есть: в некоторых случаях всё же нужно смотреть вперёд по потоку чтения дальше, чем он может. fbody основан как раз на meta. Консы не парсил им.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.