Существует ли Common Lisp с полнофункциональным call/cc?

вроде бы нет, но могу ошибаться.

Нет.

Нормальные континуации потребуют переписывания половины стандарта. Начать можно с unwind-protect.

Начать можно с unwind-protect.

«unwind-protect evaluates protected-form and guarantees that cleanup-forms are executed before unwind-protect exits, whether it terminates normally or is aborted by a control transfer of some kind.».

И что? Вызов продолжения — тоже «control transfer of some kind.». Ну а если кто-то через продолжение влазит внутрь unwind-protect, то он должен осознавать что делает: (unwind-protect (return 1) (return 2)) тоже хз что возвращает.

unwind-protect

Или можно тупо запретить вызов продолжений внутрь защищённой формы. Опять же, ничему не противоречит.

Love5an писал об этом.

lovesan

Love5an писал об этом.

Это как повод подходит (вспоминается Дейкстра с его «goto considered harmful»). При этом goto есть даже в Ада и C#.

Но выглядит как религиозное убеждение.

В Недостатки Racket (комментарий) анонимус утверждает, что оверхед от реализации call/cc на уровне компилятора достаточно мал (при любом раскладе на порядок меньше, чем при использовании cl-cont).

В конце концов, можно считать, что продолжения есть в C: http://en.wikipedia.org/wiki/Setcontext .

Немного покурил исходники cl-cont и не увидел, откуда там взяться такому уж огромному оверхеду.

не увидел, откуда там взяться такому уж огромному оверхеду

Сделай макроэкспанд того, во что превращается код после обработки cl-cont. Например:

(macroexpand 
 '(cl-cont:defun/cc list10 () 
     (loop for i from 1 to 10 collect i)))

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

(cl-cont:defun/cc list-cc (n) (loop for i from 1 to n collect i))
(defun list-n (n) (loop for i from 1 to n collect i))

(time (dotimes (k 10000) (list-cc k) nil))
Evaluation took:
  26.321 seconds of real time

(time (dotimes (k 10000) (list-n k) nil))
Evaluation took:
  1.052 seconds of real time

В принципе, я согласен на отсутствие продолжений, если в примитивах языка есть средства для создания генераторов (типа питоновского yield) и сопрограмм (например, как в Ада). Но в CL нет ни того, ни другого. Теоретически можно написать на тредах, но на практике, код который на (for (in-range ...)) запускает тред, а в случае вложенных циклов — несколько тормозить будет почти как cl-cont.

Посмотри вот это.

Here is an *attempt* to simulate generators of the Python language using Arnesi CPS transformer.

И это

pygen - Python-style generators library

Здесь Ryan Davis написал реализацию сопрограмм на CL на основе chanl

сопрограмм (например, как в Ада)

Просто из любопытства - какие в Аде средства для создания сопрограмм?

pygen

Там генератор существует только внутри foreach. Ни из (iter...) ни из (loop...) его вызвать нельзя. Даже нельзя по очереди брать элементы из двух генераторов.

using Arnesi CPS transformer.

Это тот же cl-cont. Со всеми его минусами.

сопрограмм на CL на основе chanl

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

какие в Аде средства для создания сопрограмм?

Ну не совсем сопрограммы, но use-case почти тот же:

https://en.wikibooks.org/wiki/Ada_Programming/Tasking#Rendezvous

Хотя про chanl выше указано верно, почти то же самое.

У решения на call/cc есть плюс по производительности за счёт того, что не плодятся потоки ОС.

какие в Аде средства для создания сопрограмм?

Ну не совсем сопрограммы,

:) Это нити фактически, причем обычно нити ОС.

но use-case почти тот же:

Ну, продолжения на нитях тебе не подошли.

Ну, продолжения на нитях тебе не подошли.

А call/cc на нитях есть?

А call/cc на нитях есть?

Я уверен, что можно смоделировать (концептуально, call/cc - это просто приостановка/возобновление процесса вычислений), но, ИМХО, теряется весь смысл call/cc - легковесность (нить - это ядерный ресурс, переключения медиируются ядром, нужен ядерный стек).

теряется весь смысл call/cc - легковесность

На фоне cl-cont что угодно будет легковесным. А с учётом массового использования cl-cont (weblocks, cl-fibers, cl-async) то как минимум, надо бы проверить производительность.

Вот обсуждение в тему:

http://orthecreedence.github.com/cl-async/2012/11/07/missing-coroutines-in-co...

Я не знаю Лиспа, но вот это:

«process tens of thousands of requests/responses at the same time»

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

Ты не понял, лисп не предназначен для этого, он работает по-другому.

Нарушает стандарт => невозможно.

нет конечно

Нарушает стандарт => невозможно

Библиотека cl-cont тоже нарушает стандарт? Или в каком смысле нарушает?

Библиотека cl-cont тоже нарушает стандарт?

в cl-cont нету полнофункционального call/cc, так тчо не нарушает

нету полнофункционального call/cc, так что не нарушает

Какой именно пункт стандарта нарушает полнофункциональный call/cc ?

Проблема даже не в нарушении стандарта, а в том, что неясно, как интерпретировать данную конструкцию в рамках модели образа. Что будет, если я вызову продолжение из макроса, например? Точнее, что вообще _должно_ быть?

Что будет, если я вызову продолжение из макроса, например? Точнее, что вообще _должно_ быть?

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

Продолжение технически ничем не отличается от замыкания. В случае undelimited вычисления из REPL оборачиваются в блок (handler-case ... (prompt (val) val)) и записываемое продолжение имеет форму (signal (make-prompt ...)).

То есть

(define cont #f)

(define (set-cont)
  (define n 1)
  (call/cc 
   (λ (k) (set! cont k)))
  (set! n (+ n 1))
  n)

Можно переписать в виде

(defvar *cont*)
(defun set-cont ()
  (let ((n 1))
    (setf *cont*
      (lambda ()
        (signal (make-prompt (setf n (+ n 1)) n))))))

ничего оно не нарушает, не обращай внимания

Лол, лисперы два года (!) дрочат тему «полнофункционального call/cc», в то время как нормальные девелоперы просто разрабатывают софт.

в то время как нормальные девелоперы просто разрабатывают софт

Ты же тоже не разрабатываешь софт, а трындишь на ЛОРе! Так и лисперы тоже люди - им тоже иногда потрындеть охота, а не разрабатывать софт круглые сутки.

А с учётом массового использования cl-cont
(weblocks, cl-fibers, cl-async)

cl-async не использует cl-cont. Автор понял, что это тупиковая идея и написал blackbird (https://github.com/orthecreedence/blackbird/).

cl-async не использует cl-cont. Автор понял, что это тупиковая идея

Вот и я про то же. Потому что нет нативного call/cc.

Продолжение технически ничем не отличается от замыкания.

Undelimited отличается - тем, что оно, собственно, undelimited.

В случае undelimited вычисления из REPL оборачиваются в блок (handler-case ... (prompt (val) val)) и записываемое продолжение имеет форму (signal (make-prompt ...)).

И если у тебя там какие-нибужь eval-when'ы внутри, то как это должно будет работать?

А что будет, если ты поток из макроса запустишь?

А в чем проблема? Будет просто выполняться что-то во втором потоке. Алсо, еще интереснее - если не вызвать продолжение из макроса, а захватить во время экспанда.

имеет форму (signal (make-prompt ...))

если у тебя там какие-нибужь eval-when'ы внутри

Продолжение будет (signal (make-prompt ... (eval-when ...) ...)). То есть всё, кроме :execute игнорируется.

Алсо, еще интереснее - если не вызвать продолжение из макроса, а захватить во время экспанда.

Экспанд — всего лишь функция macroexpand, которая вызывается из компилятора, который вызывается из REPL. Технически, при вызове такого продолжения, будет повторён процесс компиляции с этого места.

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

Вот и я про то же. Потому что нет нативного call/cc.

Нет, ты не понял, потому что они не нужны.

Продолжение будет (signal (make-prompt ... (eval-when ...) ...)). То есть всё, кроме :execute игнорируется.

А почему игнорируется, собственно?

Экспанд — всего лишь функция macroexpand, которая вызывается из компилятора, который вызывается из REPL. Технически, при вызове такого продолжения, будет повторён процесс компиляции с этого места.

А потом и исполнение, выходит?

Настолько не нужны, что приходится велосипедить вместо них кривые костыли?

Кривость в глазах смотрящего.

Кривость в глазах смотрящего.

Так в твоих глазах cl-cont не кривой?

А почему игнорируется, собственно?

Потому-что «For non-top level eval-when forms, :execute specifies that the body must be executed in the run-time environment.» (c) CLHS.

Также, как и во внутренностях замыкания.

А потом и исполнение, выходит?

Если компилятор был запущен из (load ...), а не (compile-file ...), то да.