Эм, неправильно выразился

Ну, само приложение, написанное на CL, которое работает в данный момент, и в который вносятся эти изменения

гораздо более интересный вопрос - при чем тут перекомпиляция

HMI на основе clg (биндинги к Gtk+, появились намного раньше cl-gtk2; вообще мне Gtk+ не очень нравится, думаю позже перейти на CommonQt)

интересно. а CommonQt не такое страшное как QtHaskell? в смысле, оно вообще юзабельное?

выложить это творчество где-нибудь на GitHub

было бы здорово

Самому сделать, не?

и переписать весь legacy-код под этот функционал?

LOR contest 2 ???

Ну давайте уже LOR contest ver. 2! А то столько переливания из пустого в порожнее! Особая жесть с примером парсинга логов апача :/

> Вы стандарт-то почитайте
Это Вы мне?

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

> и переписать весь legacy-код под этот функционал?

И юзать в подходящих условиях.

И юзать в подходящих условиях.

это-то не вопрос, но вопрос-то не в этом :)

> интересно. а CommonQt не такое страшное как QtHaskell? в смысле, оно вообще юзабельное?

Имхо страшноватое, в связи с использованием #_ reader macro, но юзабельное. Я, впрочем, пока его ещё не очень сильно использовать пытался, так, посмотрел немного некоторое время назад и отправил автору (David Lichteblau) патч для поддержки интеграции со SLIME REPL — http://repo.or.cz/w/commonqt.git/commitdiff/ca95fa435cdc0ff4afe7aa761d2de03f0...

archimag, где вас можно найти в IRC, Jabber, mumble или любом другом средстве более оперативного общения, чем на форуме?

Анонимусы не успокоились, им модераторы устроили локальный бан.

он бывает в lisp@c.j.r

naryl, моя почта (и jid) на gmail, догадаться какая очень легко ;)

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

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

#include <sys/mman.h>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int f1(int q)
{
        return q;
}

int f2(int q)
{
        int a = q+2;
        return a;
}

int f3(int q)
{
        return 4+5;
}

typedef int (* f_t)(int );

int main()
{
        void * mem = 0;
        f_t  ff;
        size_t size = f3 - f2;
        mem = mmap(0, 4096, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_SHARED | MAP_ANONYMOUS, -1, 0 );
        memcpy(mem, f2, size);
        ff = f1;
        fprintf(stderr, "do %p -> result %d\n", ff, ff(1));
        ff = mem;
        fprintf(stderr, "do %p -> result %d\n", ff, ff(1));
        return 0;
}

$ gcc f.c
$ ./a.out
do 0x400574 -> result 1
do 0x7f3613664000 -> result 3

Ясно, что в memcpy можно загрузить код откуда угодно. Теперь интересно увидеть тоже самое на лиспе.

> typedef int (* f_t)(int );

Определяется тип int, который является разыменованием указателя f_t и применением к результату int? т.е. это рекурсивный тип, если я правильно понял. Разве C их умеет?

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

И *это* вы называете *нормальным* языком?

т.е. это рекурсивный тип, если я правильно понял. Разве C их умеет?

Всё проще, здесь создаётся синоним типу - указатель на функцию, возвращающую int, принимающую в качестве параметра int.

Или это очередная зашифрованная сишная запись, дизайнер которой сделал всё возможное, чтобы её было невозможно правильно прочитать?

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

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

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

Reset, а это: size_t size = f3 - f2; корректный, переносимый способ?

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

Там красивее вышло -) нет адресной арифметики и, подозреваю, лисперы скажут точно, имеется проверка типов при вызове функции.

> Определяется тип int, который является разыменованием указателя f_t и применением к результату int? т.е. это рекурсивный тип, если я правильно понял.

Не, так определяется указатель на функцию.

Или это очередная зашифрованная сишная запись, дизайнер которой сделал всё возможное, чтобы её было невозможно правильно прочитать?

Запись вполне логичная :)

> и, подозреваю, лисперы скажут точно, имеется проверка типов при вызове функции.

нет там проверки типов - но сделать можно.

Расслабтесь, меня просто от общения с анонимусами плющит до сих пор :)

Подобные тайпдефы здорово облегчают чтение кода и понимать их легко бегло ознакомившись с языком.

Аналогичный тайпдеф в D (да, я их умею читать ;]):

//typedef int (* f_t) (int );
  alias   int function(int) f_t;

>Запись вполне логичная :)

Вот тут я думаю, что К&Р такую запись с бодуна придумали...

Логичная запись тут была бы какая-то такая:

typedef (int lambda(int))* f_t;

Лисперы такие лисперы. Зачем тут вообще функция bar?

(declaim (notinline foo)) 
 
(defun foo () (write-line "Hello, world!")) 
 
(defun main () 
  (foo) 
  (setf (symbol-function 'foo) (lambda () (write-line "FOO"))) 
  (foo)) 
 
(main)

И вообще я не понял всего этого финта ушами. Ни на Си, ни на лиспе.

Подменили указатель (ссылку, etc.) на новую функцию. В чём прикол?

using System;

class Program
{
    private delegate void F();
    private static F _func;

    static void Main()
    {
        _func = () => { Console.WriteLine("Hello"); };
        _func();
        _func = () => { Console.WriteLine("World"); };
        _func();
    }
}

Потому что в Common Lisp есть не только мощь абстрагирования и можно обрабатываться текст по крайней мере хуже чем на Perl, а XML чем на C# (попутно выяснив, что программисты на C# ничего не смыслят в xml).

Лисп сломал тебе моск. Ты обобщаешь моё незнание XML на всех C# программеров. Это по-твоему логично, да?

>Ты обобщаешь моё незнание XML на всех C# программеров. Это по-твоему логично, да?

Да тут каждый второй «неасиливший лисп» проецирует своё отношение к лиспу на всё человечество. Хотя, требовать от них «логичности» аллогично ;)

alias    int function(int)   f_t;
typedef (int lambda  (int))* f_t;

Не правда ли похоже? Особенно если предположить что typedef (lambda)* function;

Некошерно...

Надо так:

 
(defparameter *foo* #'(lambda () (print "hello")))

(defun bar () (funcall *foo*))

(defun main () 
  (bar) 
  (let ((*foo* #'(lambda () (print "hello dynamic")))) 
    (bar)) 
  (bar))

(main)

;"hello" 
;"hello dynamic" 
;"hello"

)))

Спасибо, интересный топик. Да и поржать есть где :)

На Си мы исполнили бинарный код из области памяти в которую сами же этот бинарный код поместили. На лиспе сделали нечто другое.

Я не вижу тут самомодификации, в терминах Си тут банальная подмена указателя на функцию.

Один лишь маленький вопрос: кошерно ли использовать CLOS так, как описано в PCL? С момента написания книги кардинальных изменений не произошло?

> Reset, а это: size_t size = f3 - f2; корректный, переносимый способ?

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

Там красивее вышло -)

там была решена другая задача

>Ясно, что в memcpy можно загрузить код откуда угодно.

Совсем не ясно. Такой ход сработает только для простейших функций. А если функция использует относительную адресацию (PC-relative), что используется в position-independent-коде, то будет плохо.

Пример же Love5an'а будет работать в любом лиспе.

>> Один лишь маленький вопрос: кошерно ли использовать CLOS так, как описано в PCL?

Кошерно. Изменений не происходило с момента принятия стандарта.

>там была решена другая задача

А вам какая нужна была?

Загрузить и исполнить новый бинарный код в процессе работы программы. Мы по-моему уже страниц 5 об этом говорим.

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

* (setq form1 '(+ 1 2 3 4))
* (eval form1)
10
* (eval (cons '* (cdr form1)))
24

> Я не вижу тут самомодификации, в терминах Си тут банальная подмена указателя на функцию.

Я не вижу самомодификации в C. В терминах Lisp тут банальное выполнение функции по имени (адресу в C). Где генерация в рантайме маш. кода, заменяющего имеющийся?

Загрузить и исполнить новый бинарный код в процессе работы программы.

Так прокатит?

(defun f1 (x) (+ 1 x))
(defvar *f*)
(setf (symbol-function '*f*) (symbol-function 'f1))
(*f* 1)
(defun f1 (x) (+ 2 x)) 
(*f* 1)
(setf (symbol-function '*f*) (compile nil '(lambda (x) (+ 2 x))))
(*f* 1)
; 2
; 2
; 3

>> Там красивее вышло -)

там была решена другая задача

А на C♯ третья.

нет, я не вижу тут загрузки и исполнения нового бинарного кода

>Один лишь маленький вопрос: кошерно ли использовать CLOS так, как описано в PCL? С момента написания книги кардинальных изменений не произошло?

Использовать однозначно кошерно.

С момента написания книги некоторые вещи поменялись. Например, использование MOP'а стало гораздо более переносимым и поддерживается практически всеми лиспами. Недавно совсем вышел filtered-dispatch, добавляющий интересный способ диспетчеризации методов.

> Где генерация в рантайме маш. кода, заменяющего имеющийся?

Можно вызвать отдельным процессом gcc && objcopy, а потом засосать это в буфер mem.

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

P.S. есть еще gnu lightning & LLVM, но они тоже отдельные библиотеки, и гемороя на порядок больше чем при использовании лиспа...

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

Его в С не видно. А тут compile как бы намекает на то, что берется код, компилируется в бинарник и исполняется на лету.

берется код, взятый откуда угодно -
из базы, из файл или из командной строки
(в данном случае это (lambda (x) (+ 2 x)))
потом компилится и линкуется к символу *f*
(грубо говоря теперь этот код принадлежит функции
с таким именем)