Спасибо, кэп. Я в курсе про регистры. Как отдельное извращение для отдельной программы они вполне годятся, но полноценное ПП на регистрах не построить - их слишком мало. И полноценный язык для ПП должен работать со стеком - иначе ему контекст будет негде сохранять.
Не надо путать конкретные процедуры, написанные для конкретной задачи - и общий подход. Общий подход ПП требует стека - ибо у процедуры есть свой собственный внутренний контекст. Можно, конечно, теоретически говорить о ПП без собственных контекстов, при наличии только глобальных данных - но мне неизвестны примеры таких ЯП, даже из ранних. А Вам?

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

так трудно эмулировать стек при наличии возможности манипулировать «адресным регистром»?

Абсолютно не трудно. Дело ж не в поддержке на уровне аппаратуры - а в самой концепции. До Тюринга, как я понял, ее просто не было.

Хм... Вот есть гарантия, что до Тьюринга ни кто не использовал (не издавая при этом книжки) подобный подход? Нет её.

Гарантии дает только страховой полис. А пока не доказано иное - считаем так.

т.е. до того, как кто-то умный не «вывел» понятия (определения) «бег» и «ходьба», люди не ходили и не бегали?

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

Наборы перфокарт для машины Беббиджа.

Общий подход ПП требует стека - ибо у процедуры есть свой собственный внутренний контекст.

Ничего подобного. Процедура - это _любая_ выделенная последовательность команд, которую можно вызвать в любом месте программы. Совершенно не требуется, чтобы процедура принимала какие-то аргументы и возвращала какое-то значение.

Можно, конечно, теоретически говорить о ПП без собственных контекстов, при наличии только глобальных данных - но мне неизвестны примеры таких ЯП, даже из ранних. А Вам?

Ассемблер x86.

Тьюринг только дал _формальное описание_ уже давным-давно де-факто существующему понятию.

Ассемблер x86.

Думаю все же svu интересуют примеры языков, появившихся до Фортрана, не?

Где там CALL/RETURN?

Покажите мне процедурный ЯП до фортрана. Где бы было понятие (в языке) процедуры.

Если нет формального понятия и осознания явления - невозможно создавать ничего на его основе. Включая ЯП.

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

вот как раз контекст в ПП и не важен. Потому и стек тоже не нужен(в общем случае). Я же говорю: «процедурой» может вполне быть стопка перфокарт.

Можно, конечно, теоретически говорить о ПП без собственных контекстов, при наличии только глобальных данных - но мне неизвестны примеры таких ЯП, даже из ранних. А Вам?

любой ассемблер. Нет там никаких контекстов в общем случае. Ну и соответственно любой древний процедурный ЯП, например C, в котором контексты на самом деле — синтаксический сахар. При желании, любой контекст в сишечке ломается магией указателей.

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

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

Покажите мне процедурный ЯП до фортрана. Где бы было понятие (в языке) процедуры.

процедуре не обязательно быть «понятием». Стопка перфокарт — просто стопка перфокарт. Вот Васе лень было считать синус, и он взял у Пети стопку перфокарт, которая считает синус. Перед этим он пробил одну перфокарту, которая прибавляет к аргументу PI/2, и потом вставил петину стопку. Получилась стопка, которая вычисляет косинус.

Если нет формального понятия и осознания явления - невозможно создавать ничего на его основе. Включая ЯП.

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

А при чем тут call/return? Оно для процедур совершенно излишне.

Английский, я уже говорил

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

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

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

++

И этого вполне достаточно чтобы писать ЯП.

а ЯП уже написан. Это язык данного вычислителя.

ЗЫЖ на самом деле IRL Тьюринг полный вычислитель невозможен, ибо IRL невозможно сделать бесконечность. Потому «полнота» ограниченная во всех _реальных_ ЯП, ну за исключением brainfuck'а разве-что. В сишечке например размер указателя задан, и равен константе. Хоть в стандарте и не определена эта константа, но то, что это константа(известная во время компиляции) — определено. Потому даже сишечка не является Тьюринг-полной в строгом смысле.

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

ну потому и не выводил :-)

тред не читай(тока 1 заметил про омонимы) своими словами отвечай.

1. операция (в матане) замкнута если её результат от аргументов в том же множестве , что и аргументы.

например + чисел натуральных от нуля и дальше - замкнуто.

а вот - натуральных нет ( так мы расширяем до целых)

теперь на целых вычитание замкнуто.

таким же образом умножение на целых замкнуто

а деление на целых нет.

а вот деление на рациональных без нулю замкнуто ибо (a/b)/(c/d)==(a*d)/(b*c)

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

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

- в языках где есть сборка мусора замыкания достаточно удобны.

отличие от вложенных процедур/функций в том что в обычных алгол-языках(паскаль тот же) записи активации были в порядке FILO поэтому достаточно стека , в замыканиях же получается «дерево» вместо линии .

ээээ в классическом C замыкания ваяют путём явного дополнительного аргумента - указателя на структуру ( короче эдакий самопальных this) - закат солнца в ручную.

ну блин кури историю как в второй половине 50ых эволюционировал IPL ( и откуда в алголе логический IF ( из лиспа ))

1. операция (в матане) замкнута если её результат от аргументов в том же множестве , что и аргументы.

мы вроде не про матан.

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

угу. ИМХО замыкание — такой объект, который содержит функцию(в т.ч. её локальные переменные) + какие-то ещё переменные (нелокальные).

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

ИМХО передача ссылки/указателя тоже является замыканием, причём так оно потому, что пространство указателей в сишечке является глобальным, т.е. указатель указывает на объект независимо от того, в каком контексте находится данный указатель. По этой причине сделать в сишечке сборщик мусора(который работает с простыми «глупыми» указателями) невозможно(хотя и возможно, если указатели «умные» (smart pointers), они потому и называются «умными», ибо учитывают контекст)

ээээ в классическом C замыкания ваяют путём явного дополнительного аргумента - указателя на структуру ( короче эдакий самопальных this) - закат солнца в ручную.

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

ну блин кури историю как в второй половине 50ых эволюционировал IPL ( и откуда в алголе логический IF ( из лиспа ))

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

Вам же сказали, что бегать и ходить можно просто так, без всякой рефлексии.

Аналогии такие аналогии. Мы говорим о достаточно конкретном технологическом понятии - ПП. Технология не существует до того, как ее придумали и осознали (и назвали). Даже если какие-то ее элементы использовали раньше.

Возвращаю вопрос: а кто сказал, что было?

процедуре не обязательно быть «понятием».

Чтобы ЯП назывался процедурным ЯП - обязательно. Язык без понятия процедуры не может быть процедурным. Язык без понятия объекта не может быть ОО.

porkrind.org/missives/closures-in-straight-c/

с мусорщиков всё таки удобней.

а вот чё не пойму почему в обероне замыканий в явном виде(т.е функции не первого класса, а какие-то нелегалы-иммигранты ) нет - при живом то мусорщике.

Чтобы ЯП назывался процедурным ЯП - обязательно. Язык без понятия процедуры не может быть процедурным. Язык без понятия объекта не может быть ОО.

Да нет же, нужно не понятие, а соответствующее выразительное средство. Если язык позволяет выделить кусок кода и потом его выполнять в произвольном месте - то значит процедуры есть, и не важно, как будет _называться_ это средство в данном конкретном ЯП. Главное, чем оно является по определению.

не важно, как будет _называться_ это средство в данном конкретном ЯП

Важно. Язык С не является ОО языком, хотя в нем и возможно ООП. Можно называть «колоду перфокарт» процедурой, если угодно. Но пока в языке нет понятия процедуры - он не может называться процедурным.

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

Вот! Тем более!

собственно

3 пункт http://paulgraham.com/diff.html

Важно.

Нет, не важно. От названия ничего не зависит, главное сущность и семантика объекта.

. Язык С не является ОО языком, хотя в нем и возможно ООП.

В нем не возможно ООП. В нем можно писать в процедурном стиле, который _будет похож_ на ООП. Вот если бы в сишке были макросы (настоящие), то было бы возможно ООП.

Но пока в языке нет понятия процедуры - он не может называться процедурным.

Да не нужно никому понятий. Понятие - это лишь то, как люди договорились называть некоторый объект. Это субъективное качество, которое зависит от человека. Важно, чтобы в языке был объект, который соответсовал определнию процедуры. При этом называться он может подругшому. Вот в сишке нету объектов, которые бы соответствовали определению класса. И сделать нельзя. По-этому сишка - не ООП. А набор перфокарт соответствует определению процедуры.

Еще раз - для процедурной декомпозиции никакого стека не нужно. С чего вообще вам пришло в голову, что между процедурами и стеком есть какая-то связь?

для индукции (процедурной) придётся в ручную организовывать вложенности возвратов вот и всё.

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

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

для складывания дерева - стек не нужен потому что дерево можно линейным путём обойти .

а вот если решение содержит в себе «разделяй и властвуй» с сылкой на себя(прямую или косвенную) то в каком либо виде FIFO список кем либо будет менеджится.

Сноски не читаешь? Зря, там есть ответ на твой вопрос.

а вот если решение содержит в себе «разделяй и властвуй» с сылкой на себя(прямую или косвенную) то в каком либо виде FIFO список кем либо будет менеджится.

Это тут при чем?

От названия ничего не зависит

Зависит. Одну ту же сущность можно рассматривать под разными углами.

В нем не возможно ООП

gobject- это ООП. winapi - это ООП. Уровень vfs/vnode в линухе - это ООП.

Понятие - это лишь то, как люди договорились называть некоторый объект

Это то, как люди ДУМАЮТ о нем. И из этого вытекает то, как они могут это применять. Есть такое слово ПАРАДИГМА, вот оно как раз об этом. И именно о парадигмах ПП и ФП я говорю.

По-этому сишка - не ООП

Сишка - не ООЯ. Но в нем возможно ООП. Если в каком-то языке нет концепции АБВГД, может оказаться, что можно его закрутить так, чтобы программировать в стиле АБВГД. Но сам язык не будет языком АБВГДистым.

А набор перфокарт соответствует определению процедуры.

Есть предложение забыть про перфокарты, ибо они вообще не язык, а носитель. На них можно много чего наклепать. Тот же Фортран.

не точен.

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

но со стеком как то частные задачи решались проще.

правда ограничили себя , что функции не первого класса.

Если у нас есть _объекты_ типа X, то (элементарными) _операциями_ над такими объектами будут, например, тотальные функции X -> X (унарные) и X * X -> X (бинарные), такие объекты и операции образуют какую-то алгебраическую структуру, например моноид в случае X = List и конкатенации (вообще — какая-то универсальная алгебра). Если применить операцию к объекту(ам) — получится снова объект.

Теперь пусть эти операции будут новыми «объектами», а новыми «операциями» будут их _композиции_, например для унарных есть compose/fmap — (X -> X) * (X -> X) -> (X -> X) и apply/id — (X -> X) -> (X -> X) ~ (X -> X) * X -> X, для унарных и бинарных есть bind/ap — (X -> X) * (X * X -> X) -> (X -> X), join — (X * X -> X) -> (X -> X), для бинарных есть kleisli — (X * X -> X) * (X * X -> X) -> (X * X -> X) и т.п. Если применить композицию к операции(ям) — получится новая (сложная) операция.

Вот я спрашивал какую математическую структуру образуют операции-над-объектами и композиции-операции (просто сами объекты и замкнутые операции — какую-то универсальную алгебру) — как минимум apply и compose образуют категорию стрелок-функций над данным объектом-типом с обычным применением и композицией функций (+ есть функтор (->) _ : * -> * на категории типов и функций вообще который превращает стрелки (a -> b) в стрелки (_ -> a) -> (_ -> b) частичной композицией функции), а bind/ap/join — части некой монадической структуры над стрелками-функциями из данного-объекта типа (с соответствующей Kleisli категорией).

З.Ы. compose f g = \x -> f (g x), apply f = \x -> f x, join f = \x -> f x x, bind f g = \x -> f (g x) x = join (compose f g), ap f g = \x -> f x (g x) = join (compose (flip f) g), kleisli f g = \x y -> f y (g x y) = compose (ap f) g.