Форум
Философия программирования
Тема
Как правильно задавать вопросы
B
I
abc
U
X
3
X
3
H1
H2
H3
H4
H5
H6
Asm
C/C++
C#
Erlang
Haskell
IDL
Java
Lisp
MSIL
Nemerle
ObjC
OCaml
Pascal
Perl
PHP
Prolog
Python
Ruby
Rust
SQL
VB
Здравствуйте, samius, Вы писали: S>Здравствуйте, vdimas, Вы писали: V>>Здравствуйте, samius, Вы писали: S>>>видишь ли, под пунктом 2 управляющая структура, которая выполняет подпрограммы. хаскель-if их не выполняет, а лишь выбирает ветку. У нас есть гарантия что выбранная ветка будет вычислена хоть когда-нибудь? V>>Я так и знал. ))) V>>Молодца, ты попался на тривиальный очевидный момент. Потому что поторопимшись. Давай ты напишешь пример, где предикат при if ОБЯЗАТЕЛЬНО вычисляется, но не будет вычислена возвращаемая if ветка. S>Да, соглашусь что именно в этом я попался. Но в остальном притягивании ФП к СП ты так и не отмазался. V>>Ты увидишь кое-что важное, когда наконец сможешь этот пример породить. Что именно? А достаточно будет сравнить полученный вариант с вариантом работы некоего вычислителя на энергичной технике и попробовать найти отличия в семантике. S>Ты уже задолбал делать выводы по вычислителю. V>>Так что ваш аргумент, по-сути, о том, что ф-ия if, как и все остальные ф-ии Хаскеля - ленивые. Это был, конечно, очень крутой и правильный аргумент. Только ни о чем, бо он сугубо о семантике низлежащего вычислителя. Т.е. ты имеешь полное право писать свои чистые ф-ии вовсе не заботясь о низлежащей семантике вычислителя. Где-то так... S>Аргумент был не только в ленивости if-а, если ты внимательно читал. Аргумент был еще и в том, что вычисление ветки чисто. S>>>По другим пунктам тоже можно поглядеть. S>>>1. - сиквенсинг в хаскеле нужен лишь для организации побочных эффектов. Никакое вычисление в нем не нуждается. V>>Я таки вижу, что именно само вычисление раскладывают на шаги: сначала задают промежуточные данные (let var=...), потом из них - конечные (in expr). Опять и снова, тот факт что вычисление производится в ленивой манере - ненужные подробности. Теперь найди отличия в описании шагов таких вычислений от описаний точно таких же шагов, записанных в императивном языке (порой с точностью до синтаксиса в compile-time и конечного кода в runtime). Другая модель? Хмм... арифметика, она и в Африке арифметика, как раз на арифметике можно абстрагироваться от любых низлежащих моделей вычислетелей. S>отличие в том, что каждый императивный statement несет побочный эффект, иначе без него можно обойтись. S>>>А Бём-Якопини говорили именно о вычислении функций. Вобщем первый пункт пролетает. V>>Ну, если подходить догматически, расставить рамки и т.д. то пролететь может что угодно. А если рассматривать лямда-исчисление только как входные описания для некоего вычислителя на машине Тьюринга (а оно так и есть) - то я имею право искать похожие механизмы. ИМХО, ветвление и разложение сложных вычислений на более простые шаги - это фундаментальные практики, и там и там. S>Да, я вижу что сводимость вычислителей к МТ дает тебе право не только искать, но даже утверждать об императивности всего что шевелится вплоть до языков высокого уровня. Неясно только, почему Пролог оттуда выбился. S>>>3. Выполнение подпрограммы пока ...уже бессмыслица в хаскеле, т.к. подпрограмма это выражение, которое сколько не выполняй, результат будет тот же самый ... пока булево выражение является true - тоже бессмысленно, т.к. в хаскеле выражение чему равно, тому и равно, сколько его не вычисляй, и выполнение подпрограммы на результат выражения не влияет. V>>Цикл - это повтор одного и того же кода. И ты тут пытаешься манипулировать, бо результат подпрограммы будет один и тот же только при одних и тех же входных данных. А если входные аргументы на каждом шаге цикла разные, то и результат будет разный. Почему-то комбинатор неподвижной точки так и называют - циклом или рекурсией, а вы тут упрямитесь? )) S>Тебе уже намекали что у тела цикла нет результата, потому цикл без побочных эффектов способен лишь греть атмосферу. S>>>В итоге, все 3 пункта не о хаскеле. V>>Да ради бога. Мне просто опять прикольно как ты скачешь с теории на сугубо подробности (ленивое выполнение в случае if) и потом обратно. Эдак даже не получается ровненько провести границы догм, приходится бегать подправлять? ;) S>А мне прикольно как ты опять влез на МТ V>>>>Это явное переключение потока исполнения. И ты мне так и не показал принципиальное отличие от императива для такого случая применения if. ИМХО, там всей разницы, что в императиве мы переводим стрелки непосредственно перед поездом, а в Хаскеле - немного раньше, а поезд пускаем затем по уже сформированному пути. Но кроме бла-бла я так и не услышал от тебя внятных пояснений, почему ты эти два сценария считаешь принципиально различными? Сможешь без юления четко сформулировать свою мысль? S>>>выше две мысли. Одна - if не выполняет ветки, вторая - (*)побочные эффекты не влияют на вычислимость функций, о которой писали авторы теоремы. S>>>Если ты хочешь притянуть за уши ФП к СП, то тебе придется обойтись без IO. Потому что (*). А так же потому что имея IO, мы можем на ФП спародировать любую императивную программу. Но ведь ФП Тьюринг-полна вовсе не потому что IO, так ведь? S>[b]V>Ес-но, она Тьюринг-полна, потому что может быть исполнено на конечном вычислителе,[/b] который ВЫНУЖДЕН аргументы некоторых ф-ий считать в определенном порядке. S> :wow: :))) S>Твоя аргументация убивает V>>На самом деле вы тут фигней маетесь, но мне было лень расписывать, думая, что вы и так знать должны. Само использование сочетания комбинаторов I/K таково, что упорядочивание происходит как упорядочивание вызовов ф-ий I(K/KI?(x,y)), то бишь происходит такое же упорядочивание как на монаде IO, технически реализуемое как вложение вызовов ф-ий друг в друга. То бишь, даже если в синтаксисе выражения if-then-else все аргументы выглядят как аргументы одного уровня иерархии вычислений, на самом деле одни из них вкладываются в низлежащие вызовы, при росписи этого дела на комбинаторах. И хорошо видно, что для того, чтобы раскрыть цепочку комбинаторов, СНАЧАЛА надо определиться с составом самой этой цепочки (K/KI?), то бишь с аргументом при if - true или false, иначе дальнейшие комбинаторные преобразования в конечный исполняемый код будут невозможны. Я так-то не собирался грузить всей этой догматической чепухой, полагая очевидным здравому смыслу, что аргумент при if, если он вычисляется, он вычисляется всегда РАНЬШЕ нужной ветки (даже если ветка не вычисляется вовсе затем), т.е. считал, что такое де-факто упорядочивание очевидно здравому смыслу в любой технике исполнения ФП, что в энергичной, что в ленивой. S>Что-то много букав. Да, конкретно в хаскеле K/KI будет вычислено раньше. Только причем здесь последовательность императивных стейтментов, задаваемая вручную? S>понимаешь, в СП можно написать как "a;b;", так и "b;a;". В результате мы будем иметь разный мир (т.к. результатов у стейтментов нет).
Теги:
Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например:
"Visual Studio" .NET
Имя, пароль:
Загрузить
Нравится наш сайт?
Помогите его развитию!
Отключить смайлики
Получать ответы по e-mail
Проверить правописание
Параметры проверки …