[philosophy] В чем заключается революционность перехода от функциональщины к ООП?

> ни один из анализаторов не догадается, что речь про положительные натуральные числа до 48 включительно. Ибо в коде этого намерения программист не выразил. /me догадался что имеется ввиду только после прочтения названия функции.

а это намерение должно быть выражено именно в коде? а может в типе?

int is_prime(Int<2,48> i) { return (i%2) && (i%3) && (i%5); }

кстати, тут есть еще один прикол — 1 часто не считают простым числом, т.к. иначе выйдет, что оно таки единственное простое

Я говорил за то, что в данном случае не совсем корректно говорить «большинство статических анализаторов не догадаются», правильно говорить, что ни один не догадается. Потому что по телу функции вообще никто не догадается со 100% уверенностью.

> а это намерение должно быть выражено именно в коде? а может в типе?

Хм, а выражение типа — не часть кода? Речь была про код вообще. Можно в типе, можно ассертами, да как угодно.

Хоть две:

время в LC это возможность установить то, что одна редукция предшествует другой. Короче, в LC *есть* категория времени => есть возможность моделировать состояния.

время в LC это возможность установить то, что одна редукция предшествует другой.

Я имел ввиду классическое:

-- пусть есть числа как LF:

define-form n
  \ f x . f^n x

-- и операция прибавления 1:

define-function (+1 n)
  \ n f x . n f (f x)

-- Как eval осуществляет редукцию формы (+1 n) ?
-- вот так:

t0 = n = \ n f x . n f (f x)

+1 n = (\ n f x . n f (f x)) t0         -- r1
     = \ f x . (\ f x. fn x) f (f x)    -- r2
     = \ f x . (\ x. fn x) (f x)        -- r3
     = \ f x . f^n (f x)                -- r4
     = \ f x . f^n+1 x                  -- r5
     = n + 1                            -- r6

-- Ряд редукций {r1, r2, r3, r4, r5, r6} это комбинаторное множество -
-- т.е. порядок имеет значение, для eval это и есть
-- "последовательность редукций во времени"

-- это "внутреннее время" в LC

-- далее (уже не сточки зрения редукций в eval, а с точки зрения последовательного вычисления):
 
+1 n = ... = n + 1
(1+ (+1 n)) = ... = 1+ /n + 1/ = ... = n + 2
...

define-form ("let" (x s) t)
  (\ x . t) s

(let (z (+1 1)) /z + z/) = (\ z . /z + z/) (+1 1) = /(+1 1) + (+1 1)/ = 2 + 2 = 4 -- где тут крокодил?

-- тут как раз нет времени (внешнего времени).

Внешнее время это замыкания, но мне про их связь с LC тут не рассказывают :(

Короче, в LC *есть* категория времени => есть возможность моделировать состояния.

Ну да:

* порядок при редукции в eval

* замыкания - моделирование состояний, то самое «ООП на замыканиях».

А если (2) пункт не замыкания (не?) то state который ты описал.

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

 — Как eval осуществляет редукцию формы (+1 n) ?
 — вот так:

Э... вообще-то, как угодно.

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

замыкания - моделирование состояний

Э... тоже непонятно. Совершенно.

Состояние, если я правильно понимаю, это когда что-то меняется. Замыкание, в котором есть только немутабельные переменные - это уже не замыкание?

Теорема есть такая

эта?

http://en.wikipedia.org/wiki/Church-Rosser_theorem

Э... вообще-то, как угодно.

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

замыкания - моделирование состояний

Э... тоже непонятно. Совершенно.

Состояние, если я правильно понимаю, это когда что-то меняется.

Касательно замыканий, вот пример из SICP:

(define (make-withdraw balance)
  (lambda (amount)
          (if (>= balance amount)
              (begin (set! balance (- balance amount))
                     balance)
              "Недостаточно денег на счете")))

;; При помощи make-withdraw можно следующим образом создать два объекта W1 и W2:

(define W1 (make-withdraw 100))
(define W2 (make-withdraw 100))

(W1 50)
50

(W2 70)
30

Такой стиль требует:

* локальных environment

* возможности изменения этих локальных окружений (set!)

Судя по http://www.cs.yale.edu/~fischer/pubs/lambda.pdf окружения/замыкания это не first-class in LC. Т.е. это «внешнее время» (и соответствующие состояния) не следуют из того «внутреннего времени» в LC.

Ну тогда следующий кандидат на роль естественной модели состояний (и «внешнего времени») это описанный выше State. Что читать? Куда смотреть?

В данном примере я выбрал конкретную стратегию вычисления

А кого волнует, что ТЫ там выбрал?

Т.е. это «внешнее время» (и соответствующие состояния) не следуют из того «внутреннего времени» в LC.

Да нет лямбда-калькулюсе никакого «времени».

Где пруф-оф-концепт, «грамотей»? ))

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

Ну, выбрал, и что? Тут как раз нет точного подрядка редукции
Главное ответ получить, в этом-то и цель

Касательно замыканий, вот пример из SICP:

Ну да, он только на мутабельности работает. Только я не понял, как он связан с состояниями

Ну, выбрал, и что?
Тут как раз нет точного подрядка редукции
Главное ответ получить, в этом-то и цель

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

Касательно замыканий, вот пример из SICP:

Ну да, он только на мутабельности работает. Только я не понял, как он связан с состояниями.

Конечно. Окружения (и их мутабельность, путём set!) + замыкания. Название соответсвующей главы включает слово «состояние». И о них там только и речь...

Да нет лямбда-калькулюсе никакого «времени».

Начнём ещё раз. Ты не понимаешь - почему я использую термин «время» в отношении LC, а я не понимаю почему я не могу этого делать. Ок, в конце концов LC это математическая модель, поэтому говорить слова имеет смысл только если эти слова чётко определены. Как работает eval в LC? Для начала выбирают стратегию редукции (не я выбираю, а вообще :)) и эвалютор работает согласно этой стратегии. Причём (если мы не будем лезть в индетерминизм) работает итеративно. Ну и - что не понятного во введении категории времени в рамках которого осуществляется итерация.

Более того - eval в LC не существует в вакууме и на практике чаще всего реализуется на какой-либо SM (вот - http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.67.6808, ftp://www.eecs.umich.edu/groups/gasm/whnf.pdf, если поработать гуглом или та же graph reduction на протяжении всей IFPL). А уж эта SM всяко работает итеративно во времени переходя из одного состояния в другое, ну и соответствующий eval имеет «внутреннее время» (если не нравится слово «время» - то «состояние», но это «состояние» невозможно без категории «времени» в ЯП, так что sorry).

SM может быть стековой, тогда host-язык это разновидность Forth (target-язык везде LC, естественно). Если SM регистровая, то у нас будет какой-либо ассемблер. Ну и есть вариант SM на связных списках - тогда лисп.

Да вообще - LC это ЯП, в любом ТП языке есть категория времени :)

В этой дискусси я сразу высказался об ООП - объединение ряда независимых выразительных средств в некоторых языках. Тут понятно. Интереснее (ну мне, в смысле) как выводить эти выразительные средства в минимальных языках.

Как я понял, в LC объекты/их состояние (во времени :)) вводятся с помощью:

1) environment/closures

2) Монада state.

По прежденему интересно:

* Связанно это состояние с (внутренним) состоянием эвалютора, или это вещи независимые?

* Окружения/замыкания вводятся в LC ad-hoc (а как же свободные и связанные переменные)?

Для начала выбирают стратегию редукции

Да ну? А я думал, что можно обойтись без этого. И что если я хочу показать, например, что два выражения сводятся к одному ответу, мне не нужно «выбирать стратегию редукции», а достаточно любыми удобными мне способами свести оба выражения к одному промежуточному результату. Или наоборот - произвести их оба от одного более сложного выражения. Или ещё как-то.

Ну и - что не понятного во введении категории времени в рамках которого осуществляется итерация.

То, что это - искусственное понятие, нужное, вероятно, одному тебе.

eval в LC не существует в вакууме

Давай ты определишься, что ты называешь «eval» - алгоритм или функцию? Если функцию - то учти, что математические функции не «работают». Они просто есть.

Связанно это состояние с (внутренним) состоянием эвалютора, или это вещи независимые?

Нет, конечно. Будь здесь при чём-то «внутреннее состояние», абстакция текла бы по всем швам.

Окружения/замыкания вводятся в LC ad-hoc

Чего?

пошла лютая наркомания ;)

Скорее всего я ошибаюсь в том, что рассуждаю с точки зрения реализации (алгоритмы, стате-машины, внутренне состояние, етц), а не просто в терминах LC, которого, в принципе, не знаю :) Ладно, будет ещё интерес - почитаю об этом ещё. А пока разговор перестал быть конструктивным, а автор уже отметил тему как решённую.

//

То, что это - искусственное понятие, нужное, вероятно, одному тебе.

evil_or_just_mad!

Нет, конечно. Будь здесь при чём-то «внутреннее состояние», абстакция текла бы по всем швам.

Ага, это понятно. И это, скорее всего, есть хорошо :)

Окружения/замыкания вводятся в LC ad-hoc

Чего?

ad-hoc это такое выражение (оно может употребляться с чем угодно). В данном контексте это значит - есть LC, а мы «сбоку» определяем ещё окружения, как в этой работе - http://www.cs.yale.edu/~fischer/pubs/lambda.pdf

//

@oh

да ладно, это ещё цветочки ;)

ааа!!!

КОРЧЕВАТЕЛЬ В ТРЕДЕ!!11

> Нет, класс - это рид-онли таблица, заполняемая только статически.

Нет.

Cовременные микросхемы нигде не уступают лампочкам, а тем более транзисторам.

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

Не взлетит.

http://rainman-rocks.livejournal.com/122876.html

тоже в своё время пришёл к примерно таким же выводам: полезен не ООП как таковой (строить длинные иерархии классов, и вообще оперировать сущностями «класс» и «объект»), а возможность заворачивать код в «коробки» с явно описанными «окошечками» в них.

>>Cовременные микросхемы нигде не уступают лампочкам, а тем более транзисторам.

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

Бред! Причем активно культивируемый. Еще про бескислородную монокристаллическую медь скажи. Чем «полноразмерный качественный транзистор» отличается от транзистора, как элемента микросхемы? Смех, да и только! А ламповые шумы можно с абсолютной точностью повторить на современной цифровой аппаратуре.