История изменений
Исправление monk, (текущая версия) :
на момент разработки стандарта
Ещё гигиена уже была (а значит привязки), AFAIK.
Но я не про стандарт. В стандарте и TCO нет (в SBCL и вообще почти везде он есть) и место определения при компиляции функции запоминаться не должно (а без этого не работал бы SLIME). На сегодня нет ни одной реализации CL с call/cc!
но я не думаю, что точно этими соображениями руководствовались разработчики CL
А по какой ещё причине разработчики современных компиляторов CL принципиально не хотят включать в них call/cc?
Из-за соображений компиляции, видимо, все циклы в CL раскрываются в go + tagbody.
Из-за того, что всё должно раскрываться в специальные формы. Среди которых для циклов ничего кроме go нет.
Последнее один-в-один компилируется если не учитывать продолжения
А если учитывать? В C ведь есть функция longjmp. И она ничуть не мешает всему коду компилироваться один-в-один в ассемблер.
Исходная версия monk, :
на момент разработки стандарта
Ещё гигиена уже была (а значит привязки), AFAIK.
Но я не про стандарт. В стандарте и TCO нет (в SBCL и вообще почти везде он есть) и место определения при компиляции функции запоминаться не должно (а без этого не работал бы SLIME). На сегодня нет ни одной реализации CL с call/cc!
но я не думаю, что точно этими соображениями руководствовались разработчики CL
А по какой ещё причине разработчики современных компиляторов CL принципиально не хотят включать в них call/cc?
Из-за соображений компиляции, видимо, все циклы в CL раскрываются в go + tagbody.
Из-за того, что всё должно раскрываться в специальные формы. Среди которых для циклов ничего кроме go нет.
Последнее один-в-один компилируется если не учитывать продолжения
А если учитывать? В C ведь есть функция longjmp. И она ничуть не мешает всему коду компилироваться один-в-один в ассемблер.