LINUX.ORG.RU

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


0

4

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

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

★★

Последнее исправление: maxcom (всего исправлений: 1)

когда return только возвращает управление из замыкания

конечно же. Иначе ад какй-то.

Bad_ptr ★★★★★
()

Если «или/или» - то первое, как более логичное поведение для замыкания.

Но вообще в Ruby, ЕМНИП, доступны оба варианта, и каждый из них имеет смысл. Первый вариант реализован в виде lambda, которая ближе к методу, поэтому и ведет себя как метод. Второй же вариант (Proc) ведет себя как блок, поэтому return из Proc приведет к возврату из окружающего метода.

theNamelessOne ★★★★★
()

return вызванный внутри замыкания приводит ещё и к возврату из контекста

нихрена себе, как с этим жить вообще?

Rastafarra ★★★★
()

Блямбды, замыкания и тому подобное уместны в языках, где вообще отсутствует понятие statement, и есть только expression. И там, соответственно, никакого return нет и быть не может.

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

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

Блямбды, замыкания и тому подобное уместны в языках, где вообще отсутствует понятие statement [...] А в приличных языках они все равно настолько чужеродны

Эталонная толщина. Или полное отсуствие мозга %)

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

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

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

И это говорит любитель питона - языка, где в лямбде может быть только expression

И? Это как-то оправдывает тот маразм, который ты сказал? И просто для протокола: замыкания в Питоне совершенно полноценные.

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

И? Это как-то оправдывает тот маразм, который ты сказал? И просто для протокола: замыкания в Питоне совершенно полноценные.

Маразм тут у кого-то другого. Я сказал, что лямбды (и, как следствие, замыкания) чужеродны в языках, которые нельзя однозначно отобразить на лямбда-исчисление. То есть, в языках с разделением между statement и expression они явно неуместны. Если ты считаешь, что это увтерждение маразматично, то тебе это и доказывать.

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

Я сказал, что лямбды (и, как следствие, замыкания) чужеродны в языках, которые нельзя однозначно отобразить на лямбда-исчисление.

И это утверждение не обосновал ничем, кроме своего веского мнения.

в языках с разделением между statement и expression они явно неуместны

И доказательством этого является... что?

Если ты считаешь, что это увтерждение маразматично, то тебе это и доказывать.

После тебя.

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

нихрена себе, как с этим жить вообще?

В Ruby живут :) Там для возврата из замыкания кроме return еще целых два ключевых слова есть.

В CL такая возможность тоже есть, но там такой возврат происходит явно.

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

для возврата из замыкания кроме return еще целых два ключевых слова есть.

жесть...

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

в языках с разделением между statement и expression они явно неуместны

да не, бывают удобны.

Кстати, после эксперимента с хаскелем я твёрдо уверен что будущее за гибридными языками.

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

Хз. Просто в питоне мне не хватает фич хаскелля, в хаскеле - питоновских. А может я просто не вкурил, я создам топик в devel по вопросам которые у меня возникли.

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

return вызванный внутри замыкания приводит ещё и к возврату из контекста

нихрена себе, как с этим жить вообще?

Стандартное поведение в Смолтоке, вообще-то. Называется early return, очень удобно.

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

замыкания в Питоне совершенно полноценные

Да-да, только области видимости убогие: либо совсем локальная переменная, либо глобальная.

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

Да-да, только области видимости убогие: либо совсем локальная переменная, либо глобальная.

В таком виде, как сформулировано - вранье или неграмотность.

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

Не полноценные: присвоение замкнутой переменной пробрасывает ее в скоп замыкания, т.о. нельзя расшарить переменную на несколько замыканий. Если конечно это не изменилось со времен 2.5, и под полноценностью понимается full lexical scoping.

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

присвоение замкнутой переменной пробрасывает ее в скоп замыкания

В локальный скоп.

т.о. нельзя расшарить переменную на несколько замыканий

Есть старый трюк, позволяющий это.

Если конечно это не изменилось со времен 2.5

В 3.0 ввели nonlocal (единственное новшество, которое безусловно нужно).

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

Конечно удобно, открывает дополнительные возможности для метапрограмминга. В перле также next и break можно вызывать в функции, вызванной в цикле. Разматывается стек до ближайшего for-scope и там срабатывает. Но по-моему только когда вызвано было через &func.

anonymous
()

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

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

Средневековые алхимики и знахари интуитивно, по наитию приходили к результатам, которые потом были приняты (и проверены!) химией, медициной и биологией. Но при этом алхимия не перестает быть «тупиковой ветвью» в истории познания природы человеком.

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

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

Но это не отменяет все те многочисленные технические изъяны, которые сделали лисп нежизнеспособным и фактически обусловили его фиаско.

Перечисли Top5. Я как-то не могу вспомнить существенных технических изъянов, характерных именно для Лиспов.

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

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

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

ИМХО, всё это ни разу не критично (кроме динамической типизации, но Перлу, Питону и Руби она не помешала). Правда, непонятно насчет «сборки» - имеется в виду сборка результирующей программы для дистрибуции?

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

Если чо, это была копипаста из den73 :) Ибо никто не обосрёт расскажет о недостатках лиспа лучше, чем сами лисперы. Что он там имел в виду под сборкой — да, скорее всего, дистрибуцию. Может, сейчас придёт и пояснит.

Добавлю свои пять копеек:

  • отсутствие зрелых runtime-библиотек и инфраструктуры. Так, в стандарте отсутствует упоминание о thread'ах (а на дворе, замечу, XXI век). Поэтому каждый лиспер, с присущим им NIH-синдромом, лепит свою ad hoc, informally-specified, bug-ridden, slow implementation of half of std::thread. Я уже не говорю про более крупные вещи типа ORM, транзактной распределённой компонентной архитектуры или сервера приложений. (Стандартная отмазка лисперов — «это всё баззворды и ненужно».) Итог — разбросанные по интернетам библиотечки, последнее обновление которых было в 2003 году, и которые, разумеется, не работают ни под SBCL, ни под Clozure;
  • изначальная неприспособленность языка к существующим аппаратным архитектурам. В результате этого эффективные компиляторы начали появляться только в конце 90-ых. (Стандартная отмазка лисперов: «Да это ваша фон-неймановская архитектура говно, при чём тут лисп!!!111» — но ведь фон-неймановская архитектура и теперь живее всех живых, а лисп-мойшины догнивают в канаве.)
  • бедный синтаксис языка (ака S-выражения, гомоиконность и т.п.) порождает многоуровневый скобчатый забор там, где в более современном, мощном языке стояло бы обычное «a.b.c» (Стандартная отмазка лисперов: «только быдлокодер судит о языке по синтаксису, настоящий программист руководствуется возможностями языка». Здесь ложная альтернатива, безуспешно пытающаяся скрыть то, что у языка есть и синтаксические возможности.)
  • общая маргинализованность и неадекватность сообщества. Да, я отношу это к недостаткам лиспа, так как это прямое следствие сегодняшнего маргинального положения языка, которое, в свою очередь, вызвано техническими недостатками.
  • как Basic и PHP привлекают своей простотой стаи monkey-кодеров, срущих тоннами говнокода, так и на лисп с его пахучим метапрограммированием слетаются непризнанные сумрачные гении. Результат их трудов — неуправляемый, неподдерживаемый write-only код, так как «гении» в основном асоциальны, и мысли о командной работе, поддержке и развитии кода не приходят в их мрачные умы.

А позвольте спrосить, уважаемый, поцчему ви таки интеrесуетесь лишпом? Вас что, покусал Луговскер, и теперь уважаемый Вася решил заделаться лишпером? Ой-вей, ой гевальд, моя не переносить этого! :)

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

плохо устроена модульность

В комон лиспе плохо устроена модульность. Есть и другие лиспы.

класс не создаёт пространства имён, как в Java и C++.

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

ООП плохо масштабируется

ООП вообще плохо масштабируется.

(а в лиспе сигнатура функции фиксирована и не зависит от типов)

Это преимущество а не недостаток.

во многих конструкциях действительно есть лишние скобки

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

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

Опять проблема общелиспа, а не лиспа в целом.

вообще, со сборкой плоховато

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

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

как Basic и PHP привлекают своей простотой стаи monkey-кодеров, срущих тоннами говнокода, так и на лисп с его пахучим метапрограммированием слетаются непризнанные сумрачные гении. Результат их трудов — неуправляемый, неподдерживаемый write-only код

Опять общелисп.

общая маргинализованность и неадекватность сообщества.

И снова общелисп.

бедный синтаксис языка

Преимущество, а не недостаток.

То есть как мы выяснили практически все перечисленные проблемы либо уе давным-давно исправлены, либо не являются проблемами.

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

Какой только анальной акробатикой люди не занимаются, лишь бы продолжения не делать.

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

Блямбды, замыкания и тому подобное уместны в языках, где вообще отсутствует понятие statement, и есть только expression. И там, соответственно, никакого return нет и быть не может.

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

Geoffrey J. Gordon смотрит на тебя как на говно, не знающее из за своей серости, что The simplest iteration construct in LISP is loop: a loop construct repeatedly executes its body until it hits a return special form.

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

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

Опять проблема общелиспа, а не лиспа в целом.

хорошо. Общелисп == говно. А рулит Sheme. Ну хорошо, взял http://www.gnu.org/software/mit-scheme/, дальше что? там нет автокомплита, нет подсветки парных скобок, вообще ничего нет! «лисп в целом» это такой «Linux в целом» 90х годов прошлого века - Over9000 дистрибутивов, и каждый - неюзабельное говно, которое хуже даже 95й венды. Вот только Linux допилили, а Lisp - ещё нет. Ибо никому твой лисп не нужен, кроме 3.5 задротов.

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

что ты порекомендуешь неофиту? Мне так кажется, что ситуация в этих ваших лиспах ничуть не изменилась со времён 90х, в которых я с ними и познакомился...

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

там нет автокомплита, нет подсветки парных скобок, вообще ничего нет!

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

что ты порекомендуешь неофиту?

Racket ofc.

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

В императивных языках «лямбда» - это тупо анонимная routine и не более того.

Так что вполне ложится и на statement'ы.

Другое дело, что в том же императивном с ног до головы питоне решили lambda ограничить одним выражением. Вот это странно, да.

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

Ну так идеи-то в лиспе хорошие были. Умные люди над ним работали когда-то. Но как язык - он говно.

И да, по поводу синтаксиса. Создатели Лиспа, вообще-то планировали синтаксис(M-выражения), просто временная реализация только на S-выражениях(которые должны были использоваться для внутреннего представления) как-то прижилась среди программистов.

Маккарти

The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred internal notation to any FORTRAN-like or ALGOL-like notation that could be devised.

anonymous
()

В современном языке нужно и так и так уметь. Как в Ruby.

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

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

вот что написано в вашем Священном Писании (SICP)

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

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

Racket ofc.

спасибо, пошукаю...

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

Другое дело, что в том же императивном с ног до головы питоне решили lambda ограничить одним выражением. Вот это странно, да.

проблема в том, что в императивном ЯП профит может дать только очень маленькая лямбда, которую можно безболезненно заинлайнить. Например x++ или x+y, или ещё что-то подобное. Сложная лямбда, которую заинлайнить нельзя, ИМХО профита не даст.

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

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

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

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

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

А позвольте спrосить, уважаемый, поцчему ви таки интеrесуетесь лишпом?

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

Вас что, покусал Луговскер, и теперь уважаемый Вася решил заделаться лишпером?

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

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

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

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

Где-то в начале 70-х, но они страдали тем, что их системы имели плохую сборку мусора. Эффективная сборка мусора появилась в середине 80-х. Сначала для Smalltalk, потом почти сразу же для Lisp-Machine Lisp, а затем через некоторое время уже для Common Lisp. Собственно две вещи убили Lisp Machine: (1) эффективный компилятор и (2) эффективный софтовый сборщик мусора.

Что любопытно, в некоторых первых лисп-машинах даже намеренно отключали сборщик мусора, ибо (1) тогда он был еще неэффективен; (2) код писался так, что почти не выделял новую память; (3) могли себе позволить перезагрузить лисп-машину где-то раз в сутки.

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