[Oberon7] "Man or Boy test" by Donald Knuth

[vlad]

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

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

[Geniepro]

Про синтаксис я не понял -- у замыканий синтаксис такой же как у обычной процедуры. Может быть maliya имел в виду лямбды?

При чем тут синтаксис? Имелась ввиду естественно семантика замыкания контекста. Лямбды тут вообще не в тему.

Я, конечно, знаю, что в английском пишется "Манчестер", читается "Ливерпуль", но не настолько же.
maliya чётко написал:

for my little knownledge of closure reason,I dont known what syntax should be add to cp if we want it.

Вот я и удивился, не понял, что он имел в виду...

[qp]

Промелькнуло в одной из рассылок http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html, "Достижение сатори с помощью замыканий":

* * *

  The venerable master Qc Na was walking with his student, Anton.  Hoping to
prompt the master into a discussion, Anton said "Master, I have heard that
objects are a very good thing - is this true?"  Qc Na looked pityingly at
his student and replied, "Foolish pupil - objects are merely a poor man's
closures."

  Chastised, Anton took his leave from his master and returned to his cell,
intent on studying closures.  He carefully read the entire "Lambda: The
Ultimate..." series of papers and its cousins, and implemented a small
Scheme interpreter with a closure-based object system.  He learned much, and
looked forward to informing his master of his progress.

  On his next walk with Qc Na, Anton attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that objects are truly a poor man's closures."  Qc Na responded by hitting
Anton with his stick, saying "When will you learn? Closures are a poor man's
object."  At that moment, Anton became enlightened.

[DddIzer]

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

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

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

[maliya]

More trouble than benefit! keep language and compiler as simple as possible,though any problem can be solved by reference to other language's compiler,I think there is no need to continue to do: we are not good
at function programming just now, isn't it?

[vlad]

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

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

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

[vlad]

More trouble than benefit! keep language and compiler as simple as possible,though any problem can be solved by reference to other language's compiler,I think there is no need to continue to do: we are not good
at function programming just now, isn't it?

Yeah, adding closures to original CP/Oberon requires a big piece of work from compiler/runtime implementation stand point. Although closures do not open something new comparing to classical "objects" (qp's quote has a good reflection on this) they can make source code much more clearer. So eventually I'd like to see them in some oberon implementation.

[DddIzer]

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

можно то можно, но не всегда удобно. Ладно, а ради чего все это делается в Обероне - с одной стороны, есть возможности создания обьектов с почти такими же свойствами (временем существования, степенью изолированности), с другой стороны, семантика Оберона ограничена...- более точно формулирую вопрос следующим образом: имеет ли смысл вводить замыкания не расширяя Оберон (по крайней мере его семантику)?

[Geniepro]

Ладно, а ради чего все это делается в Обероне - с одной стороны, есть возможности создания обьектов с почти такими же свойствами (временем существования, степенью изолированности), с другой стороны, семантика Оберона ограничена...- более точно формулирую вопрос следующим образом: имеет ли смысл вводить замыкания не расширяя Оберон (по крайней мере его семантику)?

Да, именно поэтому и бродила раньше такая шутка: "Объекты -- это замыкания для бедных. Замыкания -- это объекты для бедных".

Не знаю, честно говоря, есть ли смысл вводить замыкания в Оберон -- там куда полезнее были бы шаблоны. Но просто это выглядит как-то искусственно -- есть все возможности что бы ввести замыкания, которые могут быть кому-то полезными, но для упрощения транслятора от этой возможности отказываются.
Впрочем, после отказа Вирта от перечислимого типа и от "forward declarations" я уже ничему не удивляюсь... 

[vlad]

Ладно, а ради чего все это делается в Обероне - с одной стороны, есть возможности создания обьектов с почти такими же свойствами (временем существования, степенью изолированности), с другой стороны, семантика Оберона ограничена...- более точно формулирую вопрос следующим образом: имеет ли смысл вводить замыкания не расширяя Оберон (по крайней мере его семантику)?

Э... Не расширив семантику ввести не получится - там явно прописано, что с локальными процедурами нельзя ничего делать По поводу смысла я там писал выше для maliya - меньше городить на ровном месте. Представь простейший, классический и часто употребимый случай - фабрика. Ты спускаешь фабрику какой-то компоненте, чтоб она могла создавать другие компоненты ничего не зная о них. В текущем состоянии языка (ББ) это делается через абстрактную запись с методом Create. Запись надо описать, потом расширить, создать... Горка кода. Если бы были полноценные замыкания, то потребовалось бы только процедурная переменная.

P.S. Это на ББ горка кода. На обероне-07 - вообще ужос-ужос. Запись с процедурным полем + последующие касты... В общем переборщил Вирт с простотой, переборщил...

[Geniepro]

Although closures do not open something new comparing to classical "objects" (qp's quote has a good reflection on this) they can make source code much more clearer.

Что за "qp's quote"?

[vlad]

Что за "qp's quote"?

http://oberspace.dyndns.org/index.php/topic,518.msg17552.html#msg17552

[Geniepro]

P.S. Это на ББ горка кода. На обероне-07 - вообще ужос-ужос. Запись с процедурным полем + последующие касты... В общем переборщил Вирт с простотой, переборщил...

"Язык, который был проще, чем нужно"

Давным-давно кто-то из людей, делавший компилятор из Оберона в байт-код.

[vlad]

P.S. Это на ББ горка кода. На обероне-07 - вообще ужос-ужос. Запись с процедурным полем + последующие касты... В общем переборщил Вирт с простотой, переборщил...

Поэтому если пилить О7 в сторону большей человечности, то добавление замыканий залечит вот такие вот проблемы с недо-ООП (можно будет хотя бы писать "object.method()"). При этом описание языка практически не пострадает. Правда эффективность с точки зрения машины ухудшится, да.

[vlad]

"Язык, который был проще, чем нужно"

Угу - это хороший эпиграф к O7