Сall/cc — императивная или функциональная конструкция?

У тебя новый ник?

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

Не противоречит. Если считаешь иначе приводи ссылки на описание ФП парадигмы с чем происходит противоречие. При чем тут стековач модель тоже не ясно.

Продолжение, захватываемое call/cc часто сохраняется посредством деструктивного присваивания для последующего использования.

Нет.

Два ложных устверждения и основанный на них вопрос, неплохо.

Первое что на глаза попалось

Фу́нкция в программировании — поименованный фрагмент программного кода (подпрограмма), к которому можно обратиться из другого места программы. С именем функции неразрывно связан адрес первой инструкции (оператора), входящей в функцию, которой передаётся управление при обращении к функции. После выполнения функции, управление возвращается обратно в адрес возврата — точку программы, где данная функция была вызвана.
Нет.

Да

При чем тут стековач модель тоже не ясно.

Она тут притом, что стек вызовов можно попросту сбросить.

Как стековая модель связана с ФП?

Советую при вопросах о ФП читать соответствующую литературу и брать определения оттуда :)

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

И какое отношение определение подпрограммы, не являющееся точным при наличии setjmp/longjmp, имеет к функциональной парадигме?

Ладно, я дал пруф, теперь твоя осередь, давай пруф из «правильного» источника, где утверждается обратное.

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

Ну и? Продолжение возвращает другую функцию, в чем проблема?

функция, которую она получает в качестве аргумента, не возвращает управление в место вызова

Возвращает. Функцию, которую нужно вычислить следующей. Опять, в чем проблема? Тебе стали давать другие таблетки?

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

Так она и возвращает - функцию, которую нужно вызвать дальше. Это и есть значение.

Ты лучше кодом покажи.

Ну и? Продолжение возвращает другую функцию, в чем проблема?

Какую другую? Я говорю, что функция, которая получает продолжение, не возвращает управление в место своего вызова.

Возвращает. Функцию, которую нужно вычислить следующей. Опять, в чем проблема? Тебе стали давать другие таблетки?

Ты опять о чем то своем

(define search (lambda (wanted? lst)
   (call/cc (lambda(c) (for-each (lambda(element)
       (if (wanted? element) (c element))) lst)))))

(write (search (lambda(element) (= element 2)) '(1 2 3)))

И то и другое это детали реализации и зависят от call convention и не являются обязательными условиями, напр. в Haskell нету С-like стека.

Ты клоун, да? Давай начнём хотя бы с википедии

In computer science, functional programming is a programming paradigm, a style of building the structure and elements of computer programs, that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data

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

Ещё раз: понятие процедуры к функциональной парадигме отношения не имеет.

В случае call/cc она может вообще ничего не возвратить. Она возвратит что-то, но только не туда, откуда вызвана.

В ФП под функцией имеется ввиду функция в математическом смысле, подпрограмма, в которую передаются значения из множества A и она возвращает значение из множества B. Никаких предположений о связи с архитектурой вычислителя, соглашениях о вызове и т.п. не делается. Книжное определение может и позже дам, это не важно тут.

Еще раз, если ты утверждаешь, что в ФП функция не обязана возвращать результат в место вызова (в том же LC, lol), то давай пруф, а философия твоя не нужна.

один из рекурсивных вызовов for-each

Что? Где ты увидел «рекурсивные вызовы for-each»? Кто тебе вообще сказал что for-each реализован рекурсивно? А даже если код реализован рекурсивно, то кто тебе сказал, что на стеке вызовов есть что-то кроме одного вызова for-each? (man оптимизация хвостового вызова)

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

Ещё раз: ты вместо пруфа по теме ФП используешь неполное определение процедуры из императивных языков прошлого века.

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

list n = (n):list (n+1)
myList = list 1

main =
  print (myList !! 5)

И вот у тебя ломается вся твоя стековая логика: ведь функция list 1 должна рекурсивно вызывать себя и умирать из-за переполнения стека!!11

Чистая функция всегда возвращает один и тот же результат. Куда она его возвращает - не так уж важно.

Более того, не так важно даже, когда она его возвращает. Мог бы придумать вброс и получше, например 'ленивость против жадности' или 'монады против уникальных типов'

не так важно даже, когда она его возвращает

Ага, тогда и монады не нужны.

А то, что мы прыгаем в СОХРАНЕННОЕ состояние, еще раз: СОСТОЯНИЕ, это тоже для фп-фанбоя не проблема, да? Немного демагогии, и все нормально.

Куда она его возвращает - не так уж важно.

Пруфец хотелось бы увидеть.

не можешь утверждать даже последовательной работы программы

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

ломается вся твоя стековая логика

Ничего там не ломается, там сахара слишком много, не более того.

А они и не нужны.

Здесь, вместо того, чтобы возвратить управление в место вызова — один из рекурсивных вызовов for-each, управление возвращается в место вызова call/cc. Стек вызовов for-each, не схлопывается, а просто сбрасывается, насколько я понимаю.

Нет, здесь вместо возврата «процедуры-предыдущего шага рекурсии» возвращается «процедура-следующая после вызова call/cc» и она и выполняется. Если тебе это поможет: все вызовы процедур в Схеме являются хвостовыми и неявно передают продолжение. call/cc просто позволяет сделать это явно со связыванием продолжения с некоторым символом.

(define search (lambda (wanted? lst)

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

(define (search wanted? lst)

Ну так тебе об этом и говорят, с чем ты споришь? for-each вычисляется, но не один из вызовов внутри него, в данном случае, не возвращает ничего в точку вызова. Вызовы есть, возвратов — нет.

все вызовы процедур в Схеме являются хвостовыми

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

СОСТОЯНИЕ

Ты путаешь состояние и окружение.

Пруфец хотелось бы увидеть

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

Нет, это ты путаешь окружение (которое тут вообще не при чем), с состоянием вычисления. Ты можешь заморозить вычисление, сохранить его, а затем продолжить вычисление с сохраненной точки. В этом суть call/cc.

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

Если у нас все функции чистые, то связи там будут такими же.

стековая дисциплина достаточно позднее изобретение в программировании.

вообще стековость это наследие Алгола60.

помань J-оператор Ландина.

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

вообще же вот это полистай :

https://archive.org/stream/programsforelect00wilk#page/n9/mode/2up

Programs for an Electrical Computer (1951)

удивись и есть общий потомок алголки и скобкоты

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

если ты этому не удивлён , то твой вопрос про call|cc которая вроде из ултиматума лямбды лжив.

Я не понял о чем ты. call|cc — это оператор из scheme. В некоторых других языках есть его кастрированная версия. И да, он похож на оператор J(jump). call/cc тоже прыгает. А вопроса никакого и не было, был сарказм. Это не ФП конструкция, хотя бы потому, что она позволяет функциям не возвращать значения.

Это вопрос точки зрения. call/cc вполне естественно вписывается в ФП-мир после CPS-преобразования. Чтобы никто не ушёл обиженным, там все вызовы функций не возвращают значений до самого конца вычислений.

Сама по себе — нет. Пруф — монада Cont в хаскеле.

императивная или функциональная

мультипарадигменная!!!

Ну так тебе об этом и говорят, с чем ты споришь? for-each вычисляется, но не один из вызовов внутри него, в данном случае, не возвращает ничего в точку вызова. Вызовы есть, возвратов — нет.

Ты точно прочитал мое сообщение? Возврат есть всегда. Всегда возвращается продолжение.

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

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

А какая разница? Тебе религия ее использовать не позволит если она императивная?

Сначала define что такое функциональная парадигма, потом можно начинать обсуждение.

anonimous залогинься и не неси чушь, а то тебя снова забанят.