Минусы первого класса продолжений - PullRequest
4 голосов
/ 22 сентября 2009

Какую критику вынуждают выставлять продолжения как первоклассные объекты?

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

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

Ответы [ 7 ]

7 голосов
/ 03 декабря 2009

Реальность такова, что многие полезные ситуации, в которых вы можете использовать продолжения, уже покрыты специальными языковыми конструкциями: throw / catch, return, C # / Python yield. Таким образом, у языковых разработчиков на самом деле нет такого большого стимула предоставлять их в обобщенной форме, которую можно использовать для решений по принципу «накатить».

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

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

Функциональные языки с большей вероятностью реализуют продолжения по нескольким причинам:

  1. Они часто реализуются в стиле передачи продолжения, что означает, что «стек вызовов», вероятно, является связанным списком, размещенным в куче. Это упрощает передачу указателя на стек в качестве продолжения, поскольку вам не нужно перезаписывать контекст стека, когда вы извлекаете текущий кадр и вставляете новый. (Я никогда не использовал CPS, но это мое понимание).
  2. Они предпочитают неизменные привязки данных, которые делают ваше старое продолжение намного более полезным, потому что вы не изменили содержимое переменных, на которые указывал стек при создании.

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

4 голосов
/ 03 декабря 2009

Существенным возражением является стоимость внедрения. Если среда выполнения использует стек, то для продолжения первого класса в какой-то момент требуется копия стека. Стоимость копирования может контролироваться (см. Представление управления в присутствии первоклассных продолжений для хорошей стратегии), но это также означает, что изменяемые переменные не могут быть размещены в стеке. Это не проблема для функциональных или в основном функциональных (например, схем) языков, но это добавляет значительные издержки для языков ОО.

4 голосов
/ 23 сентября 2009

Во-первых, существует больше, чем просто вызов / cc, когда дело доходит до продолжения. Я предлагаю начать с статьи Марка Филиса: Лучший API для продолжений первого класса

Далее я предлагаю прочитать о операторах управления смещением и сбросом, которые представляют собой другой способ представления контуляций.

2 голосов
/ 22 сентября 2009
  1. Большинство программистов их не понимают. Если у вас есть код, который их использует, труднее найти программистов, которые смогут работать с ним.
  2. Продолжения трудно реализовать на некоторых платформах. Например, JRuby не поддерживает продолжения.
1 голос
/ 03 декабря 2009

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

Cf. жалоба Кента Питмана на продолжение , на хитрый способ, которым раскрутка-защита взаимодействует с call / cc

0 голосов
/ 22 сентября 2009

в ruby ​​1.8 реализация была крайне медленной. лучше в 1.9, и, конечно, в большинстве схем они были встроены и работали хорошо с самого начала.

0 голосов
/ 22 сентября 2009

Call / cc - это «goto» для расширенного функционального программирования (например, здесь ).

...