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

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

Дословное цитирование (с поправкой на форматирование) из онлайн-сообщения ^[1], написанного лицом, руководившим работой по добавлению продолжений в JVM:

• Асимметричный: когда продолжение приостанавливается или завершается, выполнение возвращается вызывающему (из Continuation.run()). Симметричные продолжения не имеют понятия вызывающего. Когда они уступают, они должны указать другое продолжение для передачи выполнения. Ни симметричные, ни асимметричные продолжения не могут быть сильнее друг друга, и каждое из них может использоваться для моделирования другого.

• С накоплением: продолжение можно приостановить на любой глубине в стеке вызовов, а не в той же подпрограмме, где начинается разделенный контекст, когда продолжение не имеет стека (как в случае C #). Т.е. у продолжения есть свой стек, а не только один фрейм подпрограммы. Стекированные продолжения более эффективны, чем бесстековые.

• С разделителями: продолжение фиксирует контекст выполнения, который начинается с определенного вызова (в нашем случае, тело определенного запускаемого объекта), а не все состояние выполнения вплоть до main(). Разграниченные продолжения строго более эффективны, чем неограниченные (http://okmij.org/ftp/continuations/undelimited.html), последний считается практически бесполезным (http://okmij.org/ftp/continuations/against-callcc.html).

• Несколько подсказок: продолжения могут быть вложенными, и в любом месте стека вызовов любое из включающих продолжений может быть приостановлено. Это похоже на вложение блоков try / catch и выдачу исключения определенного типа, которое раскручивает стек до ближайшего улова , который его обрабатывает, а не только до ближайшего улова. Примером вложенных продолжений может быть использование Python-подобного генератора внутри виртуального потока. Код генератора может выполнять блокирующий вызов ввода-вывода, который приостанавливает продолжение включающего потока, а не только генератор: https://youtu.be/9vupFNsND6o?t=2188

• Одноразовый / без повторного входа: каждый раз, когда мы продолжаем приостановленное продолжение, его состояние изменяется, и мы не можем продолжать его из одного и того же состояния приостановки несколько раз (т. е. мы не можем вернуться во времени). . Это отличается от реентерабельных продолжений, где каждый раз, когда мы приостанавливаем их, возвращается новый неизменяемый объект продолжения, который представляет конкретную точку приостановки. Т.е. продолжение - это единичный момент времени, и каждый раз, когда мы продолжаем его, мы возвращаемся в это состояние. Реентерабельные продолжения строго более мощные, чем невозвратные; то есть они могут делать вещи, которые совершенно невозможны с помощью всего лишь однократного продолжения.

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

Продолжения Aiui не отображаются напрямую в Raku, поэтому, возможно, правильным ответом, связанным с Raku (в отличие от Rakudo), будет отсутствие продолжений. Но мне это непонятно, поэтому в дальнейшем, в котором я описываю то, что, как я надеюсь, может быть в ответе, если мне очень повезет, я сделаю вид, что имеет смысл говорить о них в контексте обоих Раку. и Ракудо как два разных мира.

Вот такой ответ, который, как я себе представляю, был бы возможен (хотя я просто несколько дико догадываюсь, что на самом деле правда):

• разработка языка на 100 лет, текущая базовая семантическая [выполнение?] Модель Raku требует, как минимум, одноразовых продолжений с разделением на несколько запросов без стека. .

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

• Rakudo реализует требуемую в настоящее время семантику продолжения.

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

• Бэкенды JVM и JS имеют подходящие прокладки, которые обеспечивают одно и то же, хотя и за счет снижения производительности. Кажется правдоподобным, что бэкэнд JVM мог бы переключиться на использование продолжений, которые являются родными для JVM, если случится так, что он их получит, при условии, конечно, что они соответствуют требованиям, но мое текущее впечатление таково, что это, вероятно, реалистично, возможно, через десятилетие. прочь или больше, прежде чем нам нужно будет подумать о том, чтобы пересечь этот мост.

(Или что-то вроде этого.)

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

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

PS. Спасибо @Larry, который понимал вещи достаточно глубоко, чтобы знать, что продолжения должны быть частью картины; Стефану О'Риру за его вклад, включая начальные реализации того, что я считаю одноразовым продолжением с разделителями и несколькими подсказками; и jnthn за воплощение мечты в реальность.

Сноски

¹ Ведется работа по внедрению продолжений в качестве первоклассной конструкции для JVM. Ключевой движущей силой этих усилий является Рон Пресслер. Вышеизложенное основано на сообщении, которое он написал в ноябре .