Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, VladD2, Вы писали:
VD>>>>В свою очередь могу тоже докапатсья до слов и сказаь, что есть языки в которых i++ не отличается от ++i потому как ни то ни другое не возвращает значение.
А>>>Какие?
VD>>http://nemerle.org/
А>Т.е. всего один, и тот экспериментальный?
Одного достаточно чтобы придраться к славам. И уверен, что он не один. Просто я не "пылиглот" .
А> И почему в документации по нему говорится только о префиксных формах ++ и --? Где искать постфиксные?
В нем унарный оператор "бай дизайн" можно применять в любой форме. Где-то об этом говориться. Искать лень, так что поверь на слово.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, lomeo, Вы писали:
L>>Вопрос — где исходная конструкция, которую подслащивают ФВП?
VD>Для особо упертых повторяю последний раз. ФВП есть в любом языке.
forth, fortran, старый паскаль, бейсик?
VD>А их подслащивания есть только в некоторых. О том и речь. Как вам не обидно и прискорбно об этом думать, но один из языков с подслащиванеим ФВП — это C#. В нем есть и лябды, и замыкания.
То есть и лямбда и замыкание это подслащенный ФВП?
Тогда наверно тебе нетрудно будет продемонстрировать это. Пока я ничего похожего не видел, все что вы показали это конкретная реализация лямбды и замыканий в конкретном языке. И притом если завтра ms стукнет в голову ввести в байт код команду типа make_closure то с точки зрения программиста ничего ни поменятся, изменится только картинка из рефлектора.
VD>Только в 2.0 синтаксис слишком пухлый. В 3.0 уже лучше чем во многих ФЯ. Так что расслабьтесь. ФП это такой же набор паттернов как и ООП, и применять его можно почти везде. А удобство его применения определяется наличием сахара/урощения реализации паттернов.
Угу, сами себе придумаем терминалогию и можем доказать все.
IT>Так оно так и есть. Есть только одна принципиальная вещь, которая не позволяет сделать полноценное замыкание — это отсутствие GC. Всё остальное детали реализации, которые безусловно интересны с позновательной точки зрения, но на саму концепцию не влияют никак.
При вашем понимании сахара GC тоже сахар, и с этой точки зрения ничто мне не мешает написать функтор в C++ завернуть его в умный указатель и доказывать что это и есть замыкание, а все остальное только сахар.
IT>>>Т.е. для этого создаётся не один объект как в .NET, а целый список — по одному объекту на каждую захваченную переменную?
FR>>А ничего что список практически состоит из указателей на переменные? (cell это указатель который позволяет ссылатся на переменные из чужой области).
IT>Правильно ли я понимаю, что в приводимых тобой в качестве примеров языках, переменные никогда не выделяются на стеке, а только в хипе, даже если это простой int?
На питоне да, в ocamle нет. Я уже приводил ассемблерный код в который вырождается простое замыкание на окамле.
FR>>И еще не понятно что будет больше один объект с полями или список указателей.
IT>А ты сам подумай
Здравствуйте, lomeo, Вы писали:
L>Мне не интересны эмуляции. Спор был чисто терминологический. Влад говорил что ФВП сахар, а я говорил, что нет. Потом Влад сказал, что я под ФВП неверно понимаю лямбды, замыкания и еще кучу всякого стаффа. Я сказал, что я под ФВП понимаю, то, чем ФВП является. Но если он хочет поговорить об этом стаффе, то и он не является сахаром. По определению автора сахар должен что то подслащивать, замещать менее сладкую, но семантически эквивалентную конструкцию. Я не вижу, чтобы это происходило ни с ФВП, ни с лямбдой, ни с замыканиями. А от того, что Влад считает их сахаром, они сахаром не становятся.
Подозреваю, что здесь спор вот в чём.
Любую фичу можно сделать сахаром, если она прикручена к языку, который без неё обходится.
А именно: замыкания, карринг, лямбда...
Замыкания можно построить двумя способами:
— упоминанием имён из внешнего контекста во вложенной функции
— каррингом свободной функции
-- первый способ
foo (x,y) = ... (bar x) ...
where
z = ...
bar t = y*z*t -- здесь y,z - внешние переменные
-- второй способ
bar' (y,z) t = y*z*t
foo (x,y) = ... (bar x) ...
where
z = ...
bar = (bar' (y,z))
В этом смысле первый способ — сахар. (Хотя для яваскрипта это не так; там передача контекстов — естественная фича реализации).
Карринг, в свою очередь, это сахар (т.е. красивый способ) записать ФВП с помощью лямбды. (А для комбинаторной логики карринг уже не сахар).
bar' = \ (y,z) -> (\t -> y * z * t)
Какая роль у лямбды в языке?
— способ определения-и-использования вложенной функции — т.е. сахар
bar' (y,z) = baryz
where
baryz t = y*z*t -- шайтан! опять появились внешние переменные!!!
— способ трансляции AST из лямбда-исчислительного вида во что-нибудь эквивалентное, более родное для базового языка (например, в комбинаторную форму J или в адский биндинг С++) — это, с некоторой натяжкой, тоже можно считать сахаром
— наконец, это и есть базис языка, основанного на лямбда-исчислении. То есть, компилятор "мыслит" в терминах лямбд.
Здравствуйте, IT, Вы писали:
IT>Т.е. для этого создаётся не один объект как в .NET, а целый список — по одному объекту на каждую захваченную переменную?
Ну, кортеж может быть и структурой. Но в языках вроде Питона и Руби все ссылочные объекты и памяти в этих языках никто не жалееет. От того у нас на сервере они дают жару дотнетным процессам сайта.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Правильно ли я понимаю, что в приводимых тобой в качестве примеров языках, переменные никогда не выделяются на стеке, а только в хипе, даже если это простой int?
Правильно за одним исключением. В принципе можно создать джит-компилятор который простые случаи оптимизирует и привратит в более менее шустрый код. Но на логическом уровне любая переменная обязана нести информацию о типах, так что без ссылок не обойтись.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Кодт, Вы писали:
К>То есть, компилятор "мыслит" в терминах лямбд.
Не соглашусь только с этой фразой. Компилятор не "мыслит" в терминах лямбд. Он как раз скорее "мыслит" в более примитивных терминах, но авторы языка пишущие компилятор безусловно мыслят (без ковыче) лямбдами и т.п.
Собственно я и говорю, что сахар — это очень относительное понятие. Все эти "гы-гы" по поводу того что if это тоже сахар не более чем недомыслие. Для ассемблера сахаром является почти любая конструкция С и уж темболее С++. Хотя был TASM с ООП, но это скорее экзотика когда в такой низкоуровневый язык попытались всунуть ООП.
А еще раньше паттернами, и соотвественно сахаром для языка являлись такие банальные вещи как взов метода. Только сейчас в языках стало совершенно пофигу как они реализованы. Теперь мы даже не здумываемся над ними. А когда-то народ на полном серьезе при взыове каждой функции думал какие регисты использовать и какие соглашения о возврате.
Точно так же для языка в котором нет некой фичи Х и эту фичу можно выразить другими средствами языка мы можем говорить о недостатке сахара в языке. И ООП тоже имеет свой сахар. Так что многие ФЯ испытывают недостаток ООП-сахара, а ООЯ недостаток ФП-сахара. И говорить об оверхэде ООП или ФЯ просто бессмысленно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>При вашем понимании сахара GC тоже сахар
Нет. GC тоже сахар при вашем понимании нешего понимания. Но судя по всему наше понимание и ваше понимание нашего понимания удаляются друг от друга на очень большой скорости.
IT>>Правильно ли я понимаю, что в приводимых тобой в качестве примеров языках, переменные никогда не выделяются на стеке, а только в хипе, даже если это простой int?
FR>На питоне да, в ocamle нет. Я уже приводил ассемблерный код в который вырождается простое замыкание на окамле.
Т.е. в осамле простой int создаётся на стеке. И как теперь будут работать ссылки на него в замыканиях, если это замыкание будет передано куда-либо вне вызывающей функции?
IT>>А ты сам подумай FR>Лучше ты когда думаешь снимай NET'овые очки
Я вот не пойму, это ты неудачно попытался нахамить или пошутить?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
VD>>>Для особо упертых повторяю последний раз. ФВП есть в любом языке.
FR>>forth, fortran, старый паскаль, бейсик?
VD>У тебя хобби такое "разговоры не по существу"? Или работа программиста убивает разумное абстрактное начало?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, FR, Вы писали:
FR>>При вашем понимании сахара GC тоже сахар
IT>Нет. GC тоже сахар при вашем понимании нешего понимания. Но судя по всему наше понимание и ваше понимание нашего понимания удаляются друг от друга на очень большой скорости.
То есть мы наконец нашли единственную несахарную конструкцию?
Удивительное открытие, может разъяснишь?
IT>>>Правильно ли я понимаю, что в приводимых тобой в качестве примеров языках, переменные никогда не выделяются на стеке, а только в хипе, даже если это простой int?
FR>>На питоне да, в ocamle нет. Я уже приводил ассемблерный код в который вырождается простое замыкание на окамле.
IT>Т.е. в осамле простой int создаётся на стеке. И как теперь будут работать ссылки на него в замыканиях, если это замыкание будет передано куда-либо вне вызывающей функции?
Подробностей не знаю, но похоже что переменная участвующая в замыкании просто не будет создаватся на стеке. Судя по результирующему ассемблерному коду старается свести gc к нулю, похоже умеет определять переменные с долгим временем жизни и размещать их статически в куче, и наооборот короткоживущие только на стеке. Кроме того использовуются пулы. В общем в небольших программах вообще обычно нет вызовов gc.
IT>>>А ты сам подумай FR>>Лучше ты когда думаешь снимай NET'овые очки
IT>Я вот не пойму, это ты неудачно попытался нахамить или пошутить?
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, lomeo, Вы писали:
L>>Мне не интересны эмуляции. Спор был чисто терминологический. Влад говорил что ФВП сахар, а я говорил, что нет. Потом Влад сказал, что я под ФВП неверно понимаю лямбды, замыкания и еще кучу всякого стаффа. Я сказал, что я под ФВП понимаю, то, чем ФВП является. Но если он хочет поговорить об этом стаффе, то и он не является сахаром. По определению автора сахар должен что то подслащивать, замещать менее сладкую, но семантически эквивалентную конструкцию. Я не вижу, чтобы это происходило ни с ФВП, ни с лямбдой, ни с замыканиями. А от того, что Влад считает их сахаром, они сахаром не становятся.
К>Подозреваю, что здесь спор вот в чём. К>Любую фичу можно сделать сахаром, если она прикручена к языку, который без неё обходится.
То есть к достаточно мощному языку у которого уже есть не уступающие по выразительности даной фиче возможности?
С этим можно согласится, но здесь утверждают что всё (кажется кроме GC это похоже некая священная корова) сахар.
Здравствуйте, FR, Вы писали:
IT>>Нет. GC тоже сахар при вашем понимании нешего понимания. Но судя по всему наше понимание и ваше понимание нашего понимания удаляются друг от друга на очень большой скорости.
FR>То есть мы наконец нашли единственную несахарную конструкцию? FR>Удивительное открытие, может разъяснишь?
Да вроде тут уже обсуждали. Например, на C++ полноценные замыкания невозможно сделать из-за отсутствия контроля времени жизни объектов самим рантаймом.
IT>>Т.е. в осамле простой int создаётся на стеке. И как теперь будут работать ссылки на него в замыканиях, если это замыкание будет передано куда-либо вне вызывающей функции?
FR>Подробностей не знаю, но похоже что переменная участвующая в замыкании просто не будет создаватся на стеке. Судя по результирующему ассемблерному коду старается свести gc к нулю, похоже умеет определять переменные с долгим временем жизни и размещать их статически в куче, и наооборот короткоживущие только на стеке. Кроме того использовуются пулы. В общем в небольших программах вообще обычно нет вызовов gc.
Тогда вопрос. Чем это будет принципиально отличаться от варианта реализации замыканий с помощью объектов? Только тем что алгоритм сложнее и оптимизация вшита в сам компилятор?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
FR>>То есть мы наконец нашли единственную несахарную конструкцию? FR>>Удивительное открытие, может разъяснишь?
IT>Да вроде тут уже обсуждали. Например, на C++ полноценные замыкания невозможно сделать из-за отсутствия контроля времени жизни объектов самим рантаймом.
Это если возвращать в качестве замыкания обычные сишные указатели на функции, но кто запретит возвращать просто объекты функторы? Или просто делать переменные участвующие в замыкании живыми до завершения программы(выделять через new POD структуру).
Кстати на шарпе проще эмулировать замыкания чем на C++ не из-за того что там есть GC, а потому что делегат это объект.
IT>Тогда вопрос. Чем это будет принципиально отличаться от варианта реализации замыканий с помощью объектов? Только тем что алгоритм сложнее и оптимизация вшита в сам компилятор?
Только тем что реализовать можно по разному, даже в NET при желании можно сделать не через объекты, а как в окамле или питоне. И поэтому код из рефлектора никак ни катит в качестве доказательства того что те же замыкания являются синтаксическим сахаром.
Здравствуйте, FR, Вы писали:
IT>>Да вроде тут уже обсуждали. Например, на C++ полноценные замыкания невозможно сделать из-за отсутствия контроля времени жизни объектов самим рантаймом.
FR>Это если возвращать в качестве замыкания обычные сишные указатели на функции, но кто запретит возвращать просто объекты функторы? Или просто делать переменные участвующие в замыкании живыми до завершения программы(выделять через new POD структуру).
Ключевое слово я выделил. Смысл в том, что без стопроцентной поддержки со стороны runtime — это всё только разговоры. Мне достаточно вернуть не объект функтор, а указатель на него и вся твоя стройная теория рассыпется.
FR>Кстати на шарпе проще эмулировать замыкания чем на C++ не из-за того что там есть GC, а потому что делегат это объект.
И это тоже, что лишь доказывает, что если язык/среда выполнения не позволяют, то никакой сахар не уже поможет.
IT>>Тогда вопрос. Чем это будет принципиально отличаться от варианта реализации замыканий с помощью объектов? Только тем что алгоритм сложнее и оптимизация вшита в сам компилятор?
FR>Только тем что реализовать можно по разному, даже в NET при желании можно сделать не через объекты, а как в окамле или питоне. И поэтому код из рефлектора никак ни катит в качестве доказательства того что те же замыкания являются синтаксическим сахаром.
Код из рефлектора не просто не "не катит", он явно и наглядно демонстрирует, что это всё сахар. Не видеть этого нужно очень очень сильно хотеть. Вот примерно как ты
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, FR, Вы писали:
FR>Это если возвращать в качестве замыкания обычные сишные указатели на функции, но кто запретит возвращать просто объекты функторы? Или просто делать переменные участвующие в замыкании живыми до завершения программы(выделять через new POD структуру). FR>Кстати на шарпе проще эмулировать замыкания чем на C++ не из-за того что там есть GC, а потому что делегат это объект.
Минус за это.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Код из рефлектора не просто не "не катит", он явно и наглядно демонстрирует, что это всё сахар. Не видеть этого нужно очень очень сильно хотеть. Вот примерно как ты
На самом деле все очень зависит от точки зрения. Но непонимание того смысла в который вкладывается в слово сахар в данном случае скорее демонстративное. Оно нужно лишь для того чтобы уйти от основного вопроса "Существует ли ОО-оверхэд?". Доказательств обсурдности этого вопроса тут было предостаточно. Но оппонетны решили сосредоточиться на борьбе с терминами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
VD>>У тебя хобби такое "разговоры не по существу"? Или работа программиста убивает разумное абстрактное начало?
FR>А у тебя?
Месье блюдет национальные традиции или отвечая вопросом на вопрос он пытается уйти от ответа?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>С этим можно согласится, но здесь утверждают что всё (кажется кроме GC это похоже некая священная корова) сахар.
Все относительно. Для языка вроде ассемблера сахаром будет почти что угодно. А для С, например, уже нет.
В общем, можешь называть это как угодно. Можешь фичами, можешь сахаром, можешь трехэтажным словосочетанием. Главное смысл. А смысл в том, что у ООП или ФЯ нет и не может быть оверхэда так как это паттерны. Нет реализации этих паттернов в языке и писать в этом стиле становится громоздко и неуклюже. Есть — и все становится куда лушче. Использовать возможности языка не по назначеню можно независимости от того ООЯ он или ФЯ. Каждый из типов языков хорош в одном и плох в другом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Это если возвращать в качестве замыкания обычные сишные указатели на функции, но кто запретит возвращать просто объекты функторы? Или просто делать переменные участвующие в замыкании живыми до завершения программы(выделять через new POD структуру). FR>>Кстати на шарпе проще эмулировать замыкания чем на C++ не из-за того что там есть GC, а потому что делегат это объект.
VD>Минус за это.
Зря, если бы в C++ указатели на функции были объектами то эмуляция на них замыканий быда бы идентична шарповой.
.
Перекуём баги на фичи!
Если нам не помогут, то мы тоже никого не пощадим.
