Какая разница между зымыканием и объектом?

а где теги - лисп схема рокет?

Как будто замыканий и объектов нет ещё где-нибудь.

objects are pure man's closers

Никакой. Два синтаксических способа сделать одно и то же.

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

Замыкание — это поведение с прицепленным снизу состоянием. Объект — это состояние с навешенным сверху поведением.

У замыкания эффективно есть только один метод: вызов.

Первый пример по схеме из википедии, это таки объект?

 
(let ((secret-message "none"))
  (set! foo (lambda (msg) (set! secret-message msg)))
  (set! bar (lambda () secret-message)))

Это два разных замыкания. И одно общее для них изменяемое значение.

Это два разных замыкания.

Хорошо, но тогда они отделены, не правда ли?:

но у объектов методы принципиально отделены.

Я это к тому, что новые замыкания, оперирующие этим замкнутым значением, можно добавить только внутри той let-формы. Вне её уже никак. Единственный вариант обхода — рефлексия: или самим лезть в кишки замыкания, или попросить отдать замкнутую переменную добровольно.

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

Ах да, ещё один аспект: типизация. На объекты и методы типы как-то удобнее накладываются, чем попытки как-то отличить (lambda (n) (set! closed-n n)) от другой (lambda (n) (set! closed-n (+ closed-n n))), относящейся к другому <<объекту>>.

тогда как замыкания — это как раз экземпляры метода, прибиваемые гвоздями к конкретным данным в их замкнутом окружении

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

это такой троллинг или ты что-то хотел написать на английском?

Ждём следующего вопроса, какая разница между class и namespace в С++.

это я перепутал слова pure и poor.

впрочем, гуглится и так.

в typed racket есть типизированые лямбды.

Вот только типы замыкаемых значений в типы лямбд не входят :( Если передавать дополнительным аргументом — нет проблем.

Функция возвращающая функцию является конструктором объекта. Возвращаемая функция может называться интерфейсом объекта управляемым через параметры этой функции.

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

И как в «настоящем» ООП, не вызываешь методы, а посылаешь объекту сообщение. Например название метода объекта в первом параметре функции интерфейса.

Ах да, ещё один аспект: типизация. На объекты и методы типы как-то удобнее накладываются, чем попытки как-то отличить (lambda (n) (set! closed-n n)) от другой (lambda (n) (set! closed-n (+ closed-n n))), относящейся к другому <<объекту>>.

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

Вот только типы замыкаемых значений в типы лямбд не входят

А почему они должны туда входить? Внутренняя реализация объекта — его дело.

всё-же без указания языка это трололо, а не вопрос.

Я это к тому, что новые замыкания, оперирующие этим замкнутым значением, можно добавить только внутри той let-формы.

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

поэтому не вижу проблемы.

А я вижу: сильное неравенство методов.

А почему они должны туда входить?

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

Объекты на замыканиях как-то ближе к прототипной модели ООП. Не то, чтобы это что-то плохое, но типизации можно сказать пока.

Но объекты это всё же состояние, неплохо бы тип этого состояния тоже включать в интерфейс.

interface Cell {

    int  get();
    void set(int x);
}

Где тут состояние в интерфейсе?

неравенство методов.

Что это такое?

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

В scala, например, функция это объект с одним методом apply (только для оптимизации внутри это не всегда так, но не важно)

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

Где тут состояние в интерфейсе?

Cell — вот это отличает данную пару get() и set() от других. Это не просто функции, возвращающие int, это методы интерфейса Cell, однозначно как-то с ним связанные. Тогда как замыкания, возвращающие int — это просто замыкания, возвращающие int.

Что это такое?

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