Сетевые игры на основе лиспа

> Я вообще не вижу никакой _своей_ «научной базы» у распространённых лиспов - просто здоровый инженерный подход

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

Поэтому и теорию типов (общую) я не воспринимаю как нечто «хаскельное»

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

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

Именно так. Как же можно _рантайм_ изучать теми же методами, что _язык_? Очевидно - это идиотизм.

Я не видел.

Пруф? Особенно правила редукции IO интересуют.

Пример это «открой такой-то проект, посмотри такой-то макрос в таком-то файле».

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

просто я привык

Убойный аргумент.

В runtime непосредственно работают обычные методы и функции

В CL macroexpand тоже работает в рантайме. И любая ф-я вызванная макроэкспандом (то есть любой макрос) - тоже.

Чё-то не очень вяжется с CLHS.

Ну так почитайте CLHS внимательнее. Контекст всех «стадий» общий.

> (defmacro yoba () (setq *param* ...)) и (defmacro yoba () `(setq *param* ...)) это в CL _одно и то же_

Вы что-то не то делаете. При чем тут macroexpand (да еще и macroexpand-1)? Формы эквивалентны, если они одинаково редуцируются - то есть если совпадает результата EVAL для них.

Нет - если сайд эффект имеет (macroexpand-1 '(f ...)).

Ваще определение противоречит общепринятому. Вы когда проверяете на сайдэффект ф-ю, то вы делаете eval, а не eval-1. Следуя ващей логике, если f имеет сайдэффекты, то g x = f x не имеет сайдэффектов, т.к. после применения одной бетаредукци сайдэффект исполнен не будет. Не надо заниматься софистикой. Есть некая форма. Если при компиляции этой формы происходит сайдэффект - значит форма имеет сайдэффект во время компиляции. Так? Или будете спорить с тавтологией? А проверка на наличие сайдэффекта при компиляции формы - это именно (compile 'f).

Это вы начали спорить с тем, что макрос это не source to source, или не вы?

Я не спорил, я вас сразу привел _доказательства_ того факта, что вы не правы (макросы из Racket - там отмазка для CL не пройдет, так как фазы четко разделены), на чем спор и завершился. А дальше вы начали весьма толсто троллить, с неоднократными «забываниями» того, о чем вообще шла речь. Я же решил вас немного покормить - потому что скучно.

Это что за терминология такая вообще?

Я сам не знаю, тут просто некоторые утверждают, что-де в CL есть некие непонятные «стадии» компиляции, чтения, макроэкспанда, евалуации и т.п., что сие значит - лучше спросить у них.

Я запутался о чём вообще речь.

Здесь речь шла о следующем.

(defparametr *p* 100)
(defmacro yoba () (setq *p* 200))
(defun yoba2 () (setq *p* 300))
*p*
100
(yoba)
200
(yoba2)
300

(define x 100)
(begin-for-syntax x) ; error
(define-for-syntax x 200)
(begin-for-syntax x)
200
(define-for-syntax y 100)
(display y) ; error

Подвести сюда матаппарт весьма непросто. по-этому большинство занимается простыми вещами вроде теории типов и теорката.

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

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

Ну почему, в теории типов есть и про формализацию динамической типизации, там это называется латентной типизаций. Вроде тип Any, правила его сужение (вместо выведения в системах вроде типизированного LC) и т.п.

Я не видел.

Пруф? Особенно правила редукции IO интересуют.

Я _не_ видел :) Про IO я выше в этом топике писал (странный тред, да), IO ничем таким особенным не является.

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

Я помню самое начало - я сказал, что макросы это AST -> AST и все их так и используют (т.е., натурально, можно открывать код и смотреть), а кто-то начал говорить что там побочные эффекты и что макросы это что-то ещё. Понятно, что побочные эффекты, но они в языки над которым мы делаем мета вычисления.

Убойный аргумент.

А что? Говорю что вижу, пока не увижу другого, а контрпримеров пока и не было.

В CL macroexpand тоже работает в рантайме. И любая ф-я вызванная макроэкспандом (то есть любой макрос) - тоже.

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

Ну так почитайте CLHS внимательнее. Контекст всех «стадий» общий.

Просто в glossary нет `context'.

Вы что-то не то делаете.

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

Ваще определение противоречит общепринятому. Вы когда проверяете на сайдэффект ф-ю, то вы делаете eval, а не eval-1.

Я макрос проверяю (с которым связана функция раскрытия). Если открыть sbcl/src/code/eval.lisp, можно увидеть как simple-eval-in-lexenv вызывает macroexpand-1 осуществляя тем самым стадию раскрытия макросов. Стадия раскрытия (sexp -> sexp) не имеет побочных эффектов, сгенерированный код (с чем угодно) отправляется компилироваться дальше.

Или будете спорить с тавтологией?

Я тут ничего не понял, выше написал, что я про макросы, а не про тривиальные функции.

Я не спорил, я вас сразу привел _доказательства_ того факта, что вы не правы (макросы из Racket - там отмазка для CL не пройдет, так как фазы четко разделены), на чем спор и завершился.

yoba-стиль не является доказательством :)

А дальше вы начали весьма толсто троллить, с неоднократными «забываниями» того, о чем вообще шла речь. Я же решил вас немного покормить - потому что скучно.

anonymous (04.03.2011 13:57:12)

Т.е. тут, на ЛОРе, постить сообщения нельзя, т.к. это де факто троллизм?

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

Наоборот - там сперва создана научная основа, а потом под нее уже все...

Вроде тип Any, правила его сужение (вместо выведения в системах вроде типизированного LC) и т.п.

Дело в том, что это не дает никакого содержательного результата.

Я _не_ видел :)

ах, ну да :)

Про IO я выше в этом топике писал (странный тред, да), IO ничем таким особенным не является.

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

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

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

А что? Говорю что вижу, пока не увижу другого, а контрпримеров пока и не было.

(define-struct ...)/(match ...) в Racket, например. я уже на это указывал. Там, кстати, даже целая статья есть на тему их использования...

Она работает в «первичном рантайме», если так можно сказать.

А он там первичный и единственный :)

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

Опять уходите от темы. Повторяю - чтобы проверить две формы на эквивалентность надо сделать EVAL этих форм. Не macroexpand-1, а eval. Сделайте и убедитесь - результат евала одинаков.

Я макрос проверяю

Вы проверяете ФОРМУ. Вы не знаете что это, по сути - макрос, функция, может спец форма. Вопрос состоит в следующем - имеет ли вычисление этой формы сайд-эффект во время компиляции?

yoba-стиль не является доказательством :)

Какой yoba-стиль? Я вам конкретные макросы привел, реализацию которых вы можете почитать в исходниках стандартной библиотеки. И, повторяю, про использование этих макросов даже есть ряд научных статей. А в Racket встроены специальные средства для реализации подобных макросов. Но вы с потрясной упертостью продолжаете закрывать глаза на эти факты, и убеждаете, что «так макросы никто не пишет», потом что «не привыкли».

Т.е. тут, на ЛОРе, постить сообщения нельзя, т.к. это де факто троллизм?

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

>Здесь речь шла о следующем.

Супер, %лядь, рассуждать о компиляции/исполнении и использовать REPL

$ cat test.lisp
(defparametr *p* 100)
(defmacro yoba () (setq *p* 200))
(defun yoba2 () (setq *p* 300))
(yoba)

$ sbcl --noinform --eval '(compile-file «test.lisp»)'

; compiling file «d:/Work/test.lisp» (written 04 MAR 2011 01:39:42 PM):
; compiling (DEFPARAMETR *P* ...)
; compiling (DEFMACRO YOBA ...)
; compiling (DEFUN YOBA2 ...)
; compiling (YOBA)
; file: d:/Work/test.lisp
; in: DEFMACRO YOBA
; (SETQ *P* 200)
;
; caught WARNING:
; undefined variable: *P*

; in: LAMBDA NIL
; (SETQ *P* 200)
;
; caught WARNING:
; undefined variable: *P*


; file: d:/Work/test.lisp
; in: DEFPARAMETR *P*
; (DEFPARAMETR *P* 100)
;
; caught WARNING:
; undefined variable: *P*

;
; caught WARNING:
; 1 more use of undefined variable *P*
;
; compilation unit finished
; Undefined variable:
; *P*
; caught 4 WARNING conditions


; d:/Work/test.fasl written
; compilation finished in 0:00:00.063
* (sb-ext:quit)

$ sbcl --noinform --load test.fasl

debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD
«initial thread» RUNNING
{23E9D6E1}>:
The variable *P* is unbound.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE] Ignore runtime option --load «test.fasl».
1: [ABORT ] Skip rest of --eval and --load options.
2: Skip to toplevel READ/EVAL/PRINT loop.
3: [QUIT ] Quit SBCL (calling #'QUIT, killing the process).

(SYMBOL-VALUE *P*)
0]

поторопился =)

вот так правильно:

$ cat test.lisp
(defparameter *p* 100)
(defmacro yoba () (setq *p* 200))
(defun yoba2 () (setq *p* 300))
(defun test ()
(print *p*)
(yoba)
(print *p*)
(yoba2)
(print *p*))
(test)


$ sbcl --noinform --eval '(compile-file «test.lisp»)'

; compiling file «d:/Work/test.lisp» (written 04 MAR 2011 02:03:09 PM):
; compiling (DEFPARAMETER *P* ...)
; compiling (DEFMACRO YOBA ...)
; compiling (DEFUN YOBA2 ...)
; compiling (DEFUN TEST ...)
; compiling (TEST)

; d:/Work/test.fasl written
; compilation finished in 0:00:00.015
* (load «test.fasl»)

100
100
300
T
*

> sbcl --noinform --eval '(compile-file «test.lisp»)'

Блин, не оскверняй лисп! не пробуй его запустить! он создан не для этого! Это разрушает всю ауру! Шутка.

Вообще, о чём дискуссия то? Я бы понял, если бы кто-нибудь что-нибудь написал и сказал - о, здесь я использовал такую фичу CL/Scheme/Haskell, из-за которой программа стала в 100 раз короче, в 100 раз надёжней, в 100 раз понятней, ну короче намного лучше, а в другом языке так сделать нельзя потому что там «динамическая типизация»/«система типов»/«неправильный рантайм» ну и т.п. Тогда бы пришли сторонники другой веры и своим кодом показали бы, что на самом деле всё наоборот. Хоть какой-то смысл имелся бы в этом.

А то ведь просто пустой трёп, который и приложить ни к чему нельзя, и распарсить затруднительно. А стадии выполнения CL это вообще дремучий лес, в который без лишней надобности лучше не лезть. Да и вообще, в Hyperspec тумана много наведено. И можно долго спорить о том, как его надо понимать.

И при чем тут COMPILE-FILE? Речь шла об обычной компиляции. То, что в CL процесс компиляции и исполнения очень непрозрачен и из-за отсутствия разделения на стадии исполнения он не умеет нормально отрабатывать захват сайд-эффектов (у вас же если сделать load скопилированного файла, то даже не будет исполнен компайл-тайм эффект, так?) - это очень значителньая проблема, но мы сейчас не об этом говорим.

> Вообще, о чём дискуссия то?

Обсуждаются три вопроса: 1. Quasimoto сказал, что в макросах не используются сайдэффекты, я сказал, что используются, привел в пример конкретные макросы Racket и некоторые макросы CL 2. по макросам CL вышла непонятка - считать ли макросом с сайдэффектом макрос, который раскрывается в eval-when. Я считаю, что да, Квази - нет. 3. и как вообще можно об этом корректно рассуждать, если четкого разделения между компиляцией/исполнением в CL нет, а значит и нельзя четко указать является ли сайдэффект эффектом компиляции/эффектом исполнения.

> И при чем тут COMPILE-FILE? Речь шла об обычной компиляции.

А что такое «обычная компиляция»?

> Вообще, о чём дискуссия то? Я бы понял, если бы кто-нибудь что-нибудь написал и сказал - о, здесь я использовал такую фичу CL/Scheme/Haskell, из-за которой программа стала в 100 раз короче, в 100 раз надёжней, в 100 раз понятней

Переписать loop на Racket в 5-10 раз (100 это уж лишку) короче, понятнее, надежнее - как нефиг делать. Но луп - говно, да :)

> Переписать loop на Racket в 5-10 раз (100 это уж лишку) короче,

понятнее, надежнее - как нефиг делать.

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

> А что такое «обычная компиляция»?

Очевидно, это когда вызывается ф-я (compile ...) ну или мы просто пишем в репле (по крайней мере в SBCL как я понимаю выражения в репле компилируются).

А можно линк на спеки и реализацию iterate? Вам просто это быстрее будет, чем мне искать.

http://common-lisp.net/project/iterate/ - там есть дока и исходники.

> Очевидно, это когда вызывается ф-я (compile ...)

Просто при работе в SLIME компиляция (C-c C-c) связана с созданием временного файла, для которого вызывается compile-file. А вот выполнениt C-M-x уже работает по другому. Так что, эффект от C-c C-c и C-M-x может быть разный, хотя обычно это и не так. У меня в RESTAS внутри define-route стоит вызов

(eval-when (:execute)
(reconnect-all-routes))

Так что выполнение формы, вместо её компиляции, имеет дополнительный эффект, но при этом теряется информация о расположении кода в исходниках . Т.е. дело не только в том, как написан макрос, но и в том, как он выполняется.

> по крайней мере в SBCL как я понимаю выражения в репле компилируются

Зависит от sb-ext:*evaluator-mode*, может и интерпретироваться, при этом, один и тот же код может приводить к разным результатам, в зависимости от режима )

Я верно понял, что iterate экспандит внутренние формы перед тем как раскрыться самому? Он их полностью экспандит?

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

> Там кодевалкер, что хочет, то и делает )

Вашу ж мать. По описанию там достаточно частичного экспанда до driver-форм и перепараметризации всяких collect/summarize. Единственно что ввело в ступор - это (let (...) (finally ...)), а если там (if pred ... (finally ...))? А если там (let (...) (yoba)), а (yoba) - раскрывается в finally (или collect)? Где-нибудь там можно прочесть конкретные правила что и вслед за чем экспандится, а то не зная их при альтернативной реализации семантика может быть УЖЕ НЕ ТА.

не может обработать нестандартные специальные конструкции и случается ошибка.

Можно пример из интереса.

> А если там (let (...) (yoba)), а (yoba) - раскрывается в finally

(или collect)?

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

Можно пример из интереса.

Я сталкивался с этим при попытке использовать sb-ext:compare-and-swap внутри iter. Но кода не сохранил. А создать такое искусственным образом не так просто. Всё таки такое случается на практике очень редко.

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

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

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

> Собственно, вместо них юзается либо macrolet

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

либо кодевалкер

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

> Я считаю, что кодеволкер - это самое плохое, что может быть,

при использовании макросов

Может и так, но только кодеволкер это фактически единственная возможность в CL делать в макросах что-то действительно впечатляющее.

> в CL

Ну да, на безрыбье :) Завтра покажу iterate без кодеволкеров.

(define-struct ...)/(match ...)

Вот это я не видел.

«A macro is a syntactic form with an associated transformer that expands the original form into existing forms.» (смотрю racket.docs). Т.е. original form -> existing forms, в CL это sexp -> sexp, о чём я и говорил.

А что, define-struct или match _изменяют_ контекст/окружение (или что там) непосредственно на этапе _экспанда_ (в CL я бы сказал - до обратной кавычки)? Зачем они так делают? В CL ведь тоже можно сделать такие макросы, но необходимости в присваивании чему-то чего-то при раскрытии не возникает.

Повторяю - чтобы проверить две формы на эквивалентность надо сделать EVAL этих форм. Не macroexpand-1, а eval.

Я так не считаю (ну по крайней мере приминительно к CL), генерацию sexp -> sexp осуществляет макроэкспанд (есть хэш табличка в которой имена макросов связаны с обычными функциями - макроэкспанд не вычисляет sexp-ы и значения, а передаёт их тем функциям, которые и возвращают sexp-ы / значения), всё остальное к этому макросам не имеет отношения - сгенерированный код может там чего-то менять. Но чистое sexp -> sexp - то ту причём.

Вы проверяете ФОРМУ.

Зачем, если мы говорим о макросах - их и нужно проверять.

Какой yoba-стиль?

Ну я не увидел define-struct сразу. А про СL вы реальных примеров не привели - только самодельные yoba-макросы.

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

Я не знаю ничего про Racket, поэтому могу смотреть только с точки зрения CL.

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

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

и некоторые макросы CL

defpackage что ли? Этот макрос парсит определение пакета и генерирует код (в sbcl - функцию %defpackage которой отданы нормальные распарсенные аргументы). Всё - больше он ничего не делает, т.е. побочных эффектов нет.

Аналогично in-package - ничего не делает при генерации, *package* присваивается уже потом, когда работает сгенерированный код.

> «A macro is a syntactic form with an associated transformer that expands the original form into existing forms.»

Это в данном случае не более чем аннотация типов на естественном языке, которая утверждает, что ожидаемо трансформер - функция, которая принимает syntax-object и возвращает syntax-object, хотя на самом деле макрос можно забиндить к чему угодно, можно так написать: (define-syntax yoba 5), правда если вы потом в коде напишите yoba, то во время экспанда будет ошибка (мол возвращаемый из трансформера объект - не syntax).

А что, define-struct или match _изменяют_ контекст/окружение (или что там) непосредственно на этапе _экспанда_ (в CL я бы сказал - до обратной кавычки)?

Да. Вообще там несколько хитрее - так как подобный паттерн (сохранение метаинформации и ее использование) часто встречается, то есть, скажем так, спец. средства для его удобной и надежной реализации. Это applicable-structure и syntax-local-value. Когда мы делаем структуру, то можно добавить prop:procedure, тогда объекты такой структуры можно использовать в качестве ф-й. Syntax-local-value же принимает некоторый идентификатор #`id и возвращает transformer binding (если id - макрос, то вернет функцию-трансформер, например). Так вот когда мы пишем (struct name ...), то создается макрос name, но в этом макросе лежит не функция, а объект некоей структуры, у которой prop:procedure - функция-трансформер, которая раскрывается в конструктор (то есть пишем потом (name init-args ...) и получаем объект структуры name), ну а поля структуры содержат нужную метаинформацию. Потому когда match в своем паттерне видит (struct name args ...) то он делает (syntax-local-value #`name), проверяет забиндена ли к name такая applicable-structure или это просто трансформер и в первом случае берет метаинформацию и генерит на ее основе код для деструктуринга. У syntax-local-value еще ряд фишек, как то работа с контекстом экспанда, но это в данном случае неважно уже.

Зачем они так делают?

Для работы с метаинформацией на этапе экспанда :)

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

Ну так я повторю вопрос - зачем писать `(begin-for-syntax `f), если можно просто f?

Я так не считаю (ну по крайней мере приминительно к CL), генерацию sexp -> sexp осуществляет макроэкспанд

Речь там шла не о том, что формы одинаково экспандятся, а о том, что результат их исполнения в топ-левеле эквивалентен.

Зачем, если мы говорим о макросах - их и нужно проверять.

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

Ну я не увидел define-struct сразу. А про СL вы реальных примеров не привели - только самодельные yoba-макросы.

привел, просто по вашему дикому мнению наличие в экспанде eval-when - не сайд-эффект.

> Аналогично in-package - ничего не делает при генерации, *package* присваивается уже потом, когда работает сгенерированный код.

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

> на основе лиспа

Коряво звучит.

И надо понимать, что на практике важно знать именно имеет ли сайдэффекты полный экспанд. Так же как с функцией важно знать имеет ли сайдэффекты полная редукция, а не частичная. Другая информация (о единичном экспанде или о единичной редукции) бесполезна.

> Завтра покажу iterate без кодеволкеров.

И Где?