LINUX.ORG.RU

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


0

4

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

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

★★

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

Для обсуждения шутаута зарегистрируйся.

Рестарты?

restart frame - это команда отладчика.

http://www.lispworks.com/documentation/lw61/LW/html/lw-30.htm#pgfId-887349

Если на стеке есть функция f, то данная команда перезапускает эту функцию. В т.ч., если это именованая функция и я её переопределил, то запускает её с новым определением. К рестартам это не имеет отношения. К call/cc - не знаю, может быть, можно прикрутить как-то.

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

Объясни, необразованный ламеришка, причем тут лишп?

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

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

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

Ты оптимист и романтик. Реальность намного хуже твоей идеальной мечты. В этой сволочной реальности есть такая дрянь, как javascript.

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

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

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

Не надо пробовать жрать говно, вывод о его несъедобности можно сделать и чисто теоретически.

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

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

К списку можно смело добавить армию отмороженных придурков - ненавистников лиспа. Они тоже создают неблагоприятный фон.

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

К списку можно смело добавить армию отмороженных придурков - ненавистников лиспа

Это результат деятельности фанатов.

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

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

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

Это результат деятельности фанатов.

Отчасти соглашусь. Причем многие критикующие просто не знают лиспа, даже основ. И таковых много среди так называемой «образованной» части публики. Например, замечал их среди «немерлистов» и «хаскелистов».

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

Гораздо хуже наличие макросов, динамическая типизация без уток, ну и говносинтаксис.

Макросы, динамическая типизация и гомоиконный синтаксис - это достоинства, а не недостатки.

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

«немерлистов»

Немерлисты - это вообще отдельных разговор. Упоротее их я не видел, даже отпетые хаскиблядки вроде thesz'a на этом фоне блекнут.

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

Значит легко можешь привести аргументы?

anonymous
()

общебляди хотят его наебать
Пошёл на.
общеблядь обосралась и ее ткнули носом в собственное дерьмо
Эк тебе пердачелло то разнесло.

Господи ты Б-же ты мой, какой же это праздник! Общелисперы срутся со схемерами!

Это все равно как если бы Фоменко подрался с Петриком в прямом эфире НТВ.

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

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

Пожалуйста, пруф реализации Java-like ООП в виде 100-строчной библиотеки на «нормальном языке» в студию.

Нет пруфа? Значит п*здобол.

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

Макросы, динамическая типизация и гомоиконный синтаксис - это достоинства, а не недостатки.
динамическая типизация... достоинства

Возможность динамически сложить ворону со столом - это, по-твоему, достоинство? Лол.

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

К списку можно смело добавить армию отмороженных придурков - ненавистников лиспа.

Это да, можно добавить. Только не к тому списку. А к вот этому, где заговоры против лиспа.

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

Не путайте динамическую типизацию со слабой.

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

пруф

Да для любой схемы по куче пруфов. Практически каждый лиспер пишет just for lulz свою реализацию ООП (так же как и реализацию инфикса). Потом выкидывает, конечно - потому что ни ООП ни инфикс нинужно, когда есть более удобные инструменты.

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

Господи ты Б-же ты мой, какой же это праздник! Общелисперы срутся со схемерами!

Да ладно - один «рэкетфил» погоды не делает. А вот лиспофобы действительно доставляют: напиши где-угодно «две волшебных буквы» CL - и мешок лулзов обеспечен. Столько у зуда в одном месте - аж диву даёшься! lol

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

А по-моему всем просто насрать на лисп. Хотя я вижу определенную пользу от его изучения в процессе обучения программированию(ИМХО, для обучения из языков вообще достаточно С, лиспа, пролога и, возможно, ассемблера, все остальное можно познать уже на практике, выбрав область).

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

если всем насрать, то откуда столько «бугурта»? :)

Ну и потом - мне скорее насрать на зуд лиспофобов, посему и перестал лезть в подобные срачи (если только не за лулзами). Но это разве хоть как-то характеризует моё отношение к самим лиспам? ;)

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

Луговскер

Классный персонаж, вершитель судеб. То ли тролль, то ли псих.

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

Это да, можно добавить. Только не к тому списку. А к вот этому, где заговоры против лиспа.

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

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

А есть какие-то проблемы с этим?

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

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

Еще на примере препроцессора в Си

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

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

Практически каждый лиспер пишет just for lulz свою реализацию ООП

И потом еще спрашивают, почему говнокод на говнолиспе поддерживать невозможно. Смешно!

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

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

При чем тут препроцессор си? Он к лиспомакросам отношения не имеет вообще никакого.

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

Не важно, текстовые это макросы, как в Си, или работающие на уровне AST, как в лиспе - смыл одинаково говняный.

Код, написаный с использованием макросов, невозможно читать и невозможно отлаживать. Поэтому в приличных языках, таких, как Java, вообще любые формы препроцессора недопустимы.

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

И потом еще спрашивают, почему говнокод на говнолиспе поддерживать невозможно.

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

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

Так эта реализация пишется не за тем, чтобы ее потом использовать. Просто в качестве тренировки.

Это можно сказать вообще обо всем, что пишется лисперами. Что такое практика, они, очевидно, вообще представления не имеют.

На практике-то ООП не нужен

Даже и не знаю, что на это сказать. Ты у психиатра давно проверялся?

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

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

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

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

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

Не важно, текстовые это макросы, как в Си, или работающие на уровне AST, как в лиспе - смыл одинаково говняный.

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

Код, написаный с использованием макросов, невозможно читать и невозможно отлаживать.

«код, написанный с использованием ООП невозможно читать и поддерживать», «код с ленивой семантикой невозможно читать и поддерживать», «код с ФВП невозможно читать и поддерживать», «код на ЯП со статической типизацией невозможно читать и поддерживать».

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

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

ЯП с дженериками как в Java нельзя назвать приличными

Дженерики тоже в общем-то зло, и их использование как раз и должно ограничиваться таким, как в Java.

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

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

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

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

public void print(Set<String> strSet) { }
public void print(Set<Integer> intSet) { }

это уже несерьезно

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

Даже и не знаю, что на это сказать.

ООП само по себе (да и вообще любая фича) не имеет никакого смысла вне контекста задач, в решении которых оно помогает. Языки с ФВП и замыканиями (типа лиспа) предлагают более удобные, гибкие, простые и поддерживаемые способы решения тех задач, что традиционно решает ООП (то самое «инкапсуляция, наследование, полиморфизм»). Что делает ООП ненужным.

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

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

Система типов должна быть простой и тупой.

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

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

Так инкапсуляция и абстракция - это как раз основные способы борьбы со сложностью.

Не любая абстракция ведет к снижению сложности.

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

Макросы лиспа предоставляют возможность менять семантику языка, не меняя его внешнего вида. То есть, позволяют обманывать и путать пользователя. Что в этом хорошего-то?

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

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

Мне вообще непонятно, почему ты в качестве сравнения с макросами лиспа привел препроцессор си?

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

Почему не систему типов хаскеля, например? Или ленивый порядок вычисления? Или еще что-нибудь в этом роде?

Потому что у этого говна уже совсем другие проблемы и опасности, не имеющие ничего общего с опасностями метапрограммирования.

Все прекрасно читается и поддерживается. Собственно, увеличение читабельности кода, упрощение его семантики, упрощение поддержки - это основные функции лиспомакросов.

Утютюшечки. На говнолиспе не написали до сих пор вообще ничего полезного. Так откуда тогда вывод о том, что «читается и поддерживается»?!? Такие выводы можно делать только на основании практики. У Java такая практика есть. У говнолиспа ее нет и быть не может, потому что говнолисп в индустрии не применяется, а любого идиота, который попробует его туда протащить, немедленно уволят с волчьим билетом.

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

Простая система типов (как в жабе, плюсах или там в шарпе) не дает никакого профита, то есть такая система как раз не нужна.

Система типов в плюсах - адски сложная. Тьюринг-полная, вообще-то. И потому оно и не нужно.

А профит от простой системы типов очевиден - компилятор сможет сгенерить эффективный код, используя адекватные низкоуровневые средства.

Либо динамика, либо зависимые типы.

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

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

ООП само по себе (да и вообще любая фича) не имеет никакого смысла вне контекста задач, в решении которых оно помогает. Языки с ФВП и замыканиями (типа лиспа) предлагают более удобные, гибкие, простые и поддерживаемые способы решения тех задач, что традиционно решает ООП (то самое «инкапсуляция, наследование, полиморфизм»). Что делает ООП ненужным.

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

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

А еще я против излишнего злоупотребления полиморфизмом.

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

ООП - это единственная методология анализа и проектирования, которая вообще работает.

Гы, сына, лол. Анализ и проектирование - это, на минутку, OOA и OOD.

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

Анализ и проектирование - это, на минутку, OOA и OOD.

Ну да. А все вместе - это ООП.

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

Не любая абстракция ведет к снижению сложности.

Это верно, да. Когда средства абстрагирования бедные (как в джава-лайк ООП, например) то получившаяся абстракция может быть весьма сложна (абстрактные фабрики абстрактных фабрик, какие-нибудь).

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

Функции тоже позволяют это делать, надо запретить функции или как?

Не надо разговаривать чушью. Функция - черный ящик.

Вот именно. Это черный ящик, в котором может происходить все, что угодно. И ты ничего не можешь сказать об этом черном ящике до тех пор, пока не ознакомишься с его спецификацией.

я знаю, что и какого типа функция возвращает.

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

Этого достаточно для понимания локального control flow.

С чего вдруг? Внутри твоей функции может быть вызвана любая дургая функция, что делает control-flow совершенон произвольный. Ты ничего не можешь сказать о control-flow, вызывая ф-ю, спецификация которой тебе неизвестна. Вот я вызвал функцию f(); Какова ее семантика? Что там происходит? вот я вызвал макрос f(); - какова его семантика? Что там происходит? Самое смешное, что для любого макроса мы можем (при большом желании) написать ф-ю, которая будет делать все то же самое. И наоборот. Т.о. если перед тобой просто f(); то неопределенность одинакова, хоть это макрос, хоть функция.

с аргументами может случиться все, что угодно (именно с аргументами, а не только с их значениями)

В функцию тоже можно значения по ссылке передать.

Этот уровень бардака и неопределенности намного превышает допустимый.

Он совпадает с уровнем бардака и неопределенности в функции.

И, да, этот урвоень бардака и неопределенности в случае дебила, который не читает документации. Когда документация прочитана - то все вполне определено. Опять же - и в случае макроса и в случае функции. Совершенно одинаково.

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

Функция тоже может. Передаем значение по ссылке - и срем сколько угодно. А если у тебя замыкание - то даже и передавать ничего не надо, обсирание контекста может быть произведено совершенно неявным и неожиданным образом.

Утютюшечки. На говнолиспе не написали до сих пор вообще ничего полезного.

На джаве тоже не написано.

У Java такая практика есть.

Правда? В каком месте?

Перечисли используемые тобой приложения, которые написаны на java.

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

Система типов в плюсах - адски сложная. Тьюринг-полная, вообще-то.

тьюринг-полнота никак не связана со сложностью.

А профит от простой системы типов очевиден - компилятор сможет сгенерить эффективный код, используя адекватные низкоуровневые средства.

Но при чем тут джава? Эффективный низкоуровневый код - это сишка тогда. И опять ООП нинужно.

Да и система типов не нужна особо - нужны хинты компилятору.

реализацию какого либо видеокодека либо на динамически типизированном тормозном говне

Самое смешное, что на таких задачах динамическое скриптовое говно с хорошим трассирующим джитом (типа луа) вполне уделает ту же сишку.

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

Ты, вероятно, не в курсе, но ООП это намного больше, чем просто средства языка.

Ты, вероятно, не вкурсе -но это именно свойства языка.

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

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

ООП - это единственная методология анализа и проектирования, которая вообще работает.

Просто ты не понимаешь, что такое ООП. Точнее воспринимаешь его слишком широко.

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

Функции тоже позволяют это делать, надо запретить функции или как?

Ты чем болеешь? Функция не может изменить control flow там, где ее вызвали, кроме очевидного варианта с выбросом exception-а.

Это черный ящик, в котором может происходить все, что угодно.

И для понимания локального control flow это все абсолютно не важно.

И ты ничего не можешь сказать об этом черном ящике до тех пор, пока не ознакомишься с его спецификацией.

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

Внутри твоей функции может быть вызвана любая дургая функция, что делает control-flow совершенон произвольный.

Я говорю про локальный control flow. Мне плевать, что там внутри функции, до тех пор, пока я могу, как минимум, исходить из предположения о том, что она когда либо завершится. В большинстве случаев это вполне обоснованное предположение.

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

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

Самое смешное, что для любого макроса мы можем (при большом желании) написать ф-ю, которая будет делать все то же самое. И наоборот.

Какая несусветная чушь! Давай, напиши функцию LOOP. Ну или хотя бы COND.

В функцию тоже можно значения по ссылке передать.

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

И, да, этот урвоень бардака и неопределенности в случае дебила, который не читает документации. Когда документация прочитана - то все вполне определено. Опять же - и в случае макроса и в случае функции. Совершенно одинаково.

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

С макросами же это невозможно.

Функция тоже может. Передаем значение по ссылке - и срем сколько угодно.

Тупишь изрядно. Это вообще не при чем.

На джаве тоже не написано.

У-тю-тюшечки. Весь энтерпрайз на Java написан. Просто ВЕСЬ.

Перечисли используемые тобой приложения, которые написаны на java.

Весь софт, используемый тем банком, в котором лежат мои деньги, написан на Java. Было бы иначе - понес бы деньги очень быстро в другой банк.

Из того, чем я непосредственно пользуюсь - Jira, Eclipse, Tomcat, Maven, и вообще десятки других инструментов, с помощью которых я зарабатываю деньги. А много денег тебе приносит говнософт на говнолиспе?

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