LINUX.ORG.RU

Возврат значения из замыкания


0

4

Как вы считаете, если противопоставить, какое _и почему_ в абстрактном ЯП поведение оператора return внутри замыкания более правильное/оправданное: когда return только возвращает управление из замыкания или когда return вызванный внутри замыкания приводит ещё и к возврату из контекста, откуда было вызвано замыкание?

p.s. В качестве примера второго поведения - return из Proc в Ruby.

★★

Последнее исправление: maxcom (всего исправлений: 1)
Ответ на: комментарий от dave

Где-то в начале 70-х, но они страдали тем, что их системы имели плохую сборку мусора

ЕМНИП, компиляторы начала 70-х не сохраняли семантику языка.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

А что ты имеешь в виду под этим?

Я уже подразумевал компилятор NCOMPLR для MacLisp. Ну, если не начало, то середина 70-х. В вычислениях был на равных с Fortran (тут не могу скопировать цитату из файла «The evolution of Lisp» в формате post-script).

dave ★★★★★
()
Ответ на: комментарий от drBatty

ну вот я mit-sheme нашёл, а интерпретатор оттуда даже стрелку влево не понимает.

Интерпретатор занимается, ВНЕЗАПНО, _интерпретацией_ кода. _уже написанного_ кода. И больше интерпретатор ничего делать не должен. Для написания кода есть редакторы/иде/етц и к языку они, естественно, не относятся (т.к. один и тот же редактор или иде можно использовать для многих ЯП)

anonymous
()
Ответ на: комментарий от drBatty

Сложная лямбда, которую заинлайнить нельзя, ИМХО профита не даст.

Какое отношение профит лямбды имеет к возможности инлайнинга?

anonymous
()
Ответ на: комментарий от dave

Собственно две вещи убили Lisp Machine: (1) эффективный компилятор и (2) эффективный софтовый сборщик мусора.

Чуваки, работавшие в Симболикс, говорят, что причиной смерти конторы было:

1. Неподъёмный кредит на новое раскошное здание, в которое контора переехала.

2. Сейлз инжиниринга и бизнес-сопровождения, как такового, не было. Т.е. кто-нибудь увидел у соседа, как он чётко на лисп-машине вещи делает, пошёл, себе купил, ему привезли и смонтировали. А что делать дальше - он не знает.

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

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

mv ★★★★★
()
Ответ на: комментарий от tailgunner

Ну, если верить «Миру Лиспа» и лично Стилу, то в 70-х.

Если верить лисперам... нутыпонел. Ты бы ещё предложил адвентистам седьмого дня верить, или саентологам.

Мне просто любопытно - вдруг я просмотрел какие-то зияющие недостатки.

Ну, и как? А мы с den73'ом ничего не проглядели, кстати?

Нет. Лисп - всего лишь еще один динамически типизированный язык, не вижу никакого смысла переходить на него.

Ой, ну ти таки меня утешили, а то я уже Б-г знает что подумал :)

Впрочем, просто так «заделаться лишпером» может только... блин, даже не знаю, кто %) Может, школьнег, уверенный в собственной исключительности.

Вот хороший пример: RusNekromant с его феерическим 1Сом на лиспе. Жаль, что после деанона он нас покинул, а мог бы ещё отжигать и отжигать.

anonymous
()
Ответ на: комментарий от mv

Чуваки, работавшие в Симболикс, говорят, что причиной смерти конторы было... Недостатков лиспа или его реализации среди этих причин не было.

Ололо, ну конечно же. Причины в чём угодно, только не в лиспе. Это всё заговор сейлзов, маркетов и кредиторов! Впрочем, чего уж останавливаться. Провал лиспа обусловлен:

  • заговором израильских спецслужб, так как лисп — секретное оружие исламистов;
  • заговором исламских террористов, так как лисп — секретное оружие Израиля;
  • заговором капиталистических производителей софта, так как лисп мог подорвать рынок;
  • заговором коммунистов, так как лисп был секретным оружием США в холодной войне;
  • деятельностью прогрессоров с Альфа Центавра, потому что код на самоуничтожение планеты зашифрован индейцами Майя в виде программы на лиспе;

и так далее. Самому-то не смешно?

Все провальные технологии зафейлились исключительно по причинам технологического толка. И только один лисп провалился из-за заговора тамплиеров с межпланетными ящериками!!!111

anonymous
()
Ответ на: комментарий от mv

Ололо, вот они, технологии XXI века! Куда там до них всяким линуксам, гномам и эклипсам!!!111

И пофиг, что система однопользовательская и не имеет TCP/IP-стека. Главное — ЛNСП!!1

anonymous
()
Ответ на: комментарий от anonymous

Мне просто любопытно - вдруг я просмотрел какие-то зияющие недостатки.

Ну, и как?

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Ну нет у Лиспа зияющих технических недостатков.

То есть отсутствие объектной системы — это не технический недостаток ни разу? Лол!

P.S. Попытки выдать CLOS за объектную систему — то же самое, что предлагать бензопилу, когда нужен мотоцикл. А что, двигатель есть, цепь есть, рукоятки есть. Ну, соединено всё в другом порядке, подумаешь, какая разница-то?

anonymous
()
Ответ на: комментарий от anonymous

Попытки выдать CLOS за объектную систему

...это заговор тамплиеров с прогрессорами Альфы Центавра!11 Они даже Буча зомбировали, гады.

tailgunner ★★★★★
()
Ответ на: комментарий от mv

Лох дремучий
Лох
Лох

Да у вас, батенька, баттхёрт!

всё там было.

И чо? В MS-DOS тоже было.

Ты CLOS в глаза не видел, признайся честно и иди с б-гом.

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

anonymous
()
Ответ на: комментарий от mv

Есть несколько парадигм ООП.

В Smalltalk - передача сообщений. В CLOS - мультиметоды и обобщенные функции. В нормальных языках - инкапсуляция, виртуальные функции, наследование, полиморфизм, паттерны проектирования, моделирование на UML.

Первые две оказались несостоятельными и провалились, последняя была принята индустрией и стала стандартом де-факто. Что не так?

anonymous
()
Ответ на: комментарий от tailgunner

...это заговор тамплиеров с прогрессорами Альфы Центавра!11 Они даже Буча зомбировали, гады.

Что-то я не слышал, чтобы мистер Гради Буч пел дифирамбы общелисповой лжеобъектной недосистеме. Можно пруф?

anonymous
()
Ответ на: комментарий от anonymous

Что-то я не слышал, чтобы мистер Гради Буч пел дифирамбы общелисповой лжеобъектной недосистеме

Кто говорил о дифирамбах? Буч сказал, что объектная система в Лиспе есть, и это CLOS. Пруфы в книге, книга - на работе. Не забуду - дам цитату. Хотя... вот после этого:

Есть несколько парадигм ООП.

думаю, дискуссию о наличии отсуствия объектной системы в CL можно сворачивать.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

В Smalltalk - передача сообщений. В CLOS - мультиметоды и обобщенные функции. В нормальных языках - инкапсуляция, виртуальные функции, наследование, полиморфизм, паттерны проектирования, моделирование на UML.

Я и говорю, что ты CLOS в глаза не видел.

Да у вас, батенька, баттхёрт!

Страшный, страшный баттхёрт у меня случается каждый раз, когда я вижу глупого, необразованного человека!

mv ★★★★★
()
Ответ на: комментарий от mv

А на что там смотреть? Очень похоже на набор костылей. Ну ладно хоть лисперы не делают свое ООП в каждом проекте, как сишники(чистые) любят.

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

anonymous
()
Ответ на: комментарий от anonymous

А на что там смотреть? Очень похоже на набор костылей.

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

mv ★★★★★
()
Ответ на: комментарий от anonymous

объектными системами нормальных языков.

Мне уже интересно - что это за «нормальные языки»? Можно озвучить список (полный, если возможно)?

tailgunner ★★★★★
()
Ответ на: комментарий от mv

Я и говорю, что ты CLOS в глаза не видел.

Что не так? CLOS не построена на мультиметодах и обобщенных функциях? Но ведь это так:

The basic building blocks of CLOS are classes, instances of classes, generic functions and their methods.

Следовательно, тебе просто нечего ответить и ты переводишь тему и начинаешь хамить. Я тоже могу утверждать, что ты Java в глаза не видел. И?

Страшный, страшный баттхёрт у меня случается каждый раз, когда я вижу глупого, необразованного человека!

Переход на личности (ad hominem) - свидетельство того, что у оппонента нет реальных аргументов. Слив засчитан.

anonymous
()
Ответ на: комментарий от tailgunner

думаю, дискуссию о наличии отсуствия объектной системы в CL можно сворачивать.

Специально для буквоедов: «несколько реализаций/материализаций парадигмы ООП». Что не так? Только конкретно, пожалуйста, не уподобляясь mv.

anonymous
()
Ответ на: комментарий от tailgunner

Мне уже интересно - что это за «нормальные языки»? Можно озвучить список (полный, если возможно)?

Все языки, реализующие ООП с классами, методами, полями, инкапсуляцией, наследованием и полиморфизмом.

Намекну, апологетом одного из них ты являешься.

anonymous
()
Ответ на: комментарий от tailgunner

дискуссию о наличии отсуствия объектной системы в CL

Кстати, ты опять передернул: речь не шла об отсутствии объектной системы в CL, а о том, что она не работает. Действительно, дискуссия с оппонентом, который (специально или ненамеренно) неспособен уследить за линией дискуссии, представляется сомнительной.

anonymous
()
Ответ на: комментарий от mv

Если хочешь обсудить какие-то конкретно возникшие вопросы по CLOS, то озвучивай их.

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

anonymous
()
Ответ на: комментарий от anonymous

Следовательно, тебе просто нечего ответить и ты переводишь тему и начинаешь хамить. Я тоже могу утверждать, что ты Java в глаза не видел. И?

Следовательно, я у меня реальный, боевой опыт на Лиспе есть, а у тебя нет. Соответственно, ты - банальный х..плёт, а моими устами глаголет всенепременная истина. И т.к. своего опыта и знаний ты по обсуждаемой теме не удосужился заработать (т.к. ты - х..плёт), то тебе только остаётся принять на веру моё утверждение, что «ООП с классами, методами, полями, инкапсуляцией, наследованием и полиморфизмом» в Лиспе есть.

mv ★★★★★
()
Ответ на: комментарий от anonymous

Переход на личности (ad hominem) - свидетельство того, что у оппонента нет реальных аргументов. Слив засчитан.

Если ты выглядишь, как утка, и крякаешь, как утка, то ты - утка. Если не хочешь, чтобы тебя за утку считали, то не крякай хотя бы.

mv ★★★★★
()
Ответ на: комментарий от mv

Следовательно, я у меня реальный, боевой опыт на Лиспе есть, а у тебя нет. Соответственно, ты - банальный х..плёт

Разве надо быть поваром, чтобы понять, что мясо протухло?

а моими устами глаголет всенепременная истина

Ах, вон оно што. Пациент, вам в эту палату, вас тут как раз Наполеон дожидается...

«ООП с классами, методами, полями, инкапсуляцией, наследованием и полиморфизмом» в Лиспе есть.
инкапсуляцией
инкапсуляцией

Но ведь это ложь. В CLOS методы не принадлежат классам, а ты не читал определения «инкапсуляции». Следовательно,

тебе только остаётся принять на веру моё утверждение

Как можно принимать на веру твои утверждения относительно классического ООП, если ты его в глаза не видел и не компетентен в нем?

anonymous
()
Ответ на: комментарий от anonymous

Все языки, реализующие ООП с классами, методами, полями, инкапсуляцией, наследованием и полиморфизмом.
Намекну, апологетом одного из них ты являешься.

Если ты о Python, то у меня с ним сложные отношения (и инкапсуляция в нем - откровенное говно). AFAIK, классы, методы, наследование и полиморфизм в CLOS есть; если у тебя какие-то конкретные претензии к CLOS, предъяви их. AMOP я так и не дочитал, но всё равно мне интересно.

Кстати, ты опять передернул: речь не шла об отсутствии объектной системы в CL

WAT.

anonymous> То есть отсутствие объектной системы — это не технический недостаток ни разу?

Или ты скажешь, что это другой анонимус?

tailgunner ★★★★★
()
Ответ на: комментарий от mv

Если ты выглядишь, как утка, и крякаешь, как утка, то ты - утка. Если не хочешь, чтобы тебя за утку считали, то не крякай хотя бы.

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

anonymous
()
Ответ на: комментарий от anonymous

Но ведь это ложь. В CLOS методы не принадлежат классам, а ты не читал определения «инкапсуляции». Следовательно,

Ох, лол, какое определение? «Инкапсуляции в C++»? Я тебе даже больше скажу: в Лиспе можно функции с данными инкапсулировать в замыканиях, безо всяких объектных систем.

Как можно принимать на веру твои утверждения относительно классического ООП, если ты его в глаза не видел и не компетентен в нем?

Я когда-то не только на «классическом ООП» писал, но и защищал его не менее рьяно, чем сейчас Лисп.

mv ★★★★★
()
Ответ на: комментарий от mv

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

В С++11 тоже можно. И?

Я когда-то не только на «классическом ООП» писал

И? Это не делает тебя автоматически компетентным в этой области.

anonymous
()
Ответ на: комментарий от mv

И, кстати, я тебе задал конкретный вопрос по CLOS, но ты не смог ответить. Ну, что, засчитываем очередной слив?

anonymous
()
Ответ на: комментарий от anonymous

если у тебя какие-то конкретные претензии к CLOS, предъяви их

См. выше.

«Методы не принадлежат классам»? Это не техническая претензия. Объясни, решение каких задач это усложняет?

Да и хрен с ними, в сущности. Позднее связывание в наличии, остальное неважно.

tailgunner ★★★★★
()
Ответ на: комментарий от mv

Какой такой вопрос?

Ну как же, чувак сказал «клосовское ооп кривое, там мультиметоды», ты спросил, какие конкретно претензии к клосу, он тебе ответил, что «клосовское ооп кривое, там мультиметоды» и хочет, чтобы ты ему рассказал, почему оно клёвое и с примерами. )

Reaper ★★
() автор топика
Ответ на: комментарий от anonymous

В нормальных языках - инкапсуляция, виртуальные функции, наследование, полиморфизм, паттерны проектирования, моделирование на UML.

В _нормальных языках_ (с замыканиями) все это реализуется в 100 строк. Никакой адекватный человек не будет пихать в ядро языка то, что тривиально делается в качестве библиотеки.

anonymous
()
Ответ на: комментарий от anonymous

Но ведь это ложь. В CLOS методы не принадлежат классам, а ты не читал определения «инкапсуляции».

Если ты считаешь, что инкапсуляцию имеет хоть какое-то отношение к «принадлежности методов классам», то ты определение инкапсуляции тоже не читал.

anonymous
()
Ответ на: комментарий от anonymous

под сборкой я имел в виду make, т.е. просто сборку программы. asdf - это очень плохая вещь (была). Сейчас вроде её сделали получше, но я допилил руками старую до более-менее сносного состояния.

В результате этого эффективные компиляторы начали появляться только в конце 90-ых.

Но всё же, на сегодня они существуют.

Поэтому каждый лиспер, с присущим им NIH-синдромом, лепит свою ad hoc, informally-specified, bug-ridden, slow implementation of half of std::thread.

Не каждый. Кроме того, не всем нужен код, переносимый между реализациями языка, а в конкретных реализациях треды есть. В Lispworks, например, мне всего хватает, что от них нужно.

плохо устроена модульность
класс не создаёт пространства имён, как в Java и C++.
статической типизации по сути нет, из-за этого ООП несколько тормозит (хотя я >думаю, всё ещё в разы быстрее того же питона)
ООП плохо масштабируется, поскольку функции не принадлежат классам. В С++ >можно иметь foo::add(один аргумент) и bar::add(два аргумента) (а в лиспе >сигнатура функции фиксирована и не зависит от типов)

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

Остальные болячки можно отчасти залечить и я это сделал (кроме foo:add, bar::add, но это тоже понятно как сделать). http://code.google.com/p/def-symbol-readmacro/wiki/GeneralDescription

Если сравнить CL c Racket, то есть как минимум два преимущетва у общелиспа: - более хорошие компиляторы (см. на шутауте, кто быстрее) - шелест - это ничего, а грохот/вымогательство - отвратительно

Кроме того, у CL есть такое редкое даже среди интерпретаторов свойство, как возможность очень многое переопределять в рантайме. Не знаю, есть ли оно в Racket.

den73 ★★★★★
()
Ответ на: комментарий от den73

(см. на шутауте, кто быстрее)

Но ведь на шутауте нету идеоматического кода, там вместо кода на обще-лиспе код не пойми на чем (то есть так как на шутауте на общелиспе не пишет никто). В случае идеоматического кода Racket сравним или быстрее, и это легко проверить. В частных случаях, конечно, можно построить примеры, в которых будет быстрее общелисп - из них 99% связаны с особенностями работы GC или банальные баги джита, которые оперативно фиксят.

Кроме того, у CL есть такое редкое даже среди интерпретаторов свойство, как возможность очень многое переопределять в рантайме. Не знаю, есть ли оно в Racket.

Конечно, есть, только в Racket все это сделано более продуманно.

как минимум два

Про оптимизацию я понял, а какое второе? Ну и недостатков по сравнению с Racket значительно больше двух и они более весомы, ясное дело.

anonymous
()
Ответ на: комментарий от anonymous

Анонимус - не человек, зарегистрируйся.

то есть так как на шутауте на общелиспе не пишет никто ... в случае идеоматического кода Racket сравним или быстрее, и это легко проверить.

Неверно. Раз ты анонимус - ищи контрпример сам, он есть на шутауте. Кроме того, есть не только скорость, но и расход памяти.

Конечно, есть, только в Racket все это сделано более продуманно.

Мой стандартный сценарий отладки:

- падаю в дебаггер на каком-нибудь assert или другой ошибке

- смотрю, что не так

- правлю какую-то функцию

- ищу вглубь стека подходящий кадр

- restart frame

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

а какое второе?

название.

den73 ★★★★★
()
Ответ на: комментарий от den73

Кроме того, есть не только скорость, но и расход памяти.

Неверно.

неверно что? Что так как на шутауте нормальные люди на CL не пишут? Достаточно посомтреть на код шутаута. Что Racket при сравнимых реализациях не медленнее (или быстрее)? Ну так это любому очевидно - достаточно посомтреть на исходники и убедиться, что в проигрывающих решениях на racket сами решения более-медленные. И если выдрачить их в стиле CL то будет быстрее - что и демонстрирует пример с теми же binary trees.

Кроме того, есть не только скорость, но и расход памяти.

Расход памяти в языках с GC - весьма эфемерное понятие. И никто еще не придумал адекватного способа измерить этот расход. Я, по крайней мере, такого способа не знаю. Если ты знаешь - поделись.

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

Рестарты? Конечно, ведь есть продолжения, а рестарты на них пишутся в пару десятков строк. Чтобы это было автоматом (по дефолту протокол обработки другой, так что его, конечно, придется заменить), то легко сделать собственный debug-mode при помощи системы continuation-marks (на которой сделана и дефолтная обработка ошибок, библиотека логирования, профайлер, отладчик). В ядро рантайма лезть будет не надо офк, все можно сделать в качестве отдельной библиотеки, которая просто подключается к твоему приложению (как тот же профайлер).

Пришли ссылку на статью, где это описано.

Гм. Никто не пишет статьи о таких мелочах. Рестарт - это просто обработчик ошибки, который принимает продолжение, бросившее ошибку (ну то есть (let/cc k (throw k)) банальное). Про continuation-marks можешь погуглить. Если коротко - оно позволяет прикреплять к стекфрейму произвольную информацию и использовать/изменять ее потом из внутренних фреймов.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.