> G>А-ха-ха, заметил свою ошибку и пытаешься меня подловить, хамишь опять. Это была твоя мысль что у C# нет стека, это залет как сказал бы vdimas. > Если вы — второй аккаунт vdimas'а, то вас я тоже буду игнорировать. > А если нет, то мысль про отсутствие стека в C# я взял отсюда: >
> J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.
> Вы точно уверены, что это не вы писали?
Крутись-вертись но свои измышления мне приписать не получится. Это ты придумал что у C# нет стека. Это клинический троллинг в последней стадии, ради того что бы затроллить собеседника ты уже на все идешь.
Здравствуйте, samius, Вы писали:
V>>Увы, получить информацию можно только поглотив энергию. Поэтому идентичность никуда не денется. ))) V>>Ведь эту энергию поглотит "кто-то конкретный". S>Она не то что никуда не девается, она ниоткуда не берется.
Двойка по физике.
S>Испускатель фотона не знает кто его получит.
Это аргумент за или против чего? я ХЗ чтоты имел ввиду, но его получит любой, вставший на пути следования фотона. И кто тебе мешает встать аналогично на "пути следования" любого события в WinForms?
V>>>>У меня испускает. Лампочка на звонке прямо на двери. S>>>Ты добрался в тонкостях до фотонов и тут же перестаешь отличать дверь от лампочки. Толсто.
V>>В итернете ты можешь найти фото дверей, которые одна сплошная лампочка. Что было действительно толсто — так это сравнивать фотон с мячом. Спишем на кривые представления о происходящем... S>Предлагаешь поразговаривать с дверью-лампочкой по фотографии в интернете?
Предлагаю перестать юлить. ТЫ уже очень далеко убегаешь, но так и не сказал — зачем? Ты игноришь все прямые вопросы и откровенно юлишь. Поэтому отвечать тебе лишний раз неохота — ты мастер по замыливанию обсуждаемого.
V>>>>Да и какая разница, в быту или нет, если наша программа всегда абстракция прямо по определению? Тебе вообще не должно быть важно, сама дверь испускает сигнал или отражает его так, что ты способен расмотреть эту дверь. S>>>Мне неважно, но именно ты ведь пытаешься натянуть физику на ООП.
V>>Наоборот, я показываю правомочность того, что дверь мне "отвечает" на вопрос. То бишь показываю физический смысл этого явления. S>Покажи как вопрос от тебя доходит до двери
Я уже показывал более одного раза.
V>>Хотя, я ни разу не обязан был этого делать для тебя, т.к. в умозрительной модели я имею право раздать роли обектам как мне удобно. Даже если такое распределение ролей не имеет физического аналога в реальном мире. Просто я ХЗ как тебе втолковать сей очевидный момент, вот и пришлось демонстрировать аналогичное происходящее в реале. S>Вот я тебе и талдычу о том что аналога в мире нет.
Я опроверг все твои аргументы (все два) многократно. Ты мои — ни разу. Талдыч своей жене.
S>Вместо того что бы натягивать реальный мир на ООП, программисты поступают ровно наоборот, только это не всем очевидно.
Они никогда не поступают наоборот и адекватных примеров, увы, ты не приведешь. Даже здесь с дверью — никакого наоборот. Тебе в любом случае надо получать информацию от двери. А прямо или косвенно — вообще не важно, что в жизни, что в программе.
... нам в любом случае придется вводить фиктивный объект, который будет делать это ВМЕСТО двери.
S>Типа вот если бы дверь была бы как бы компьютером, и мы могли бы ей посылать сообщение, вот было бы круто.
Я же говорю, у тебя пробелы в теории информации. Для тебя сообщение — это непременно набор байт. И если ты этого набора байт в жизни не видишь, то оп-па! Твоя программа не является моделью рж!!! Я такого откровеннго детсада уже 100 лет не видел. )
S>Все, дальше выдумывать ничего не надо.
А я и не выдумываю, я сразу обозначил, что дверь нам может посылать информацию в нашей модели. А есть у ней компьютер или нет — вообще неважно. В общем, советую курить теорию информации. Ты уже десяток постов на весь интернет объясняешь, что у тебя в голове одно не страстается с другим исключительно из-за пробелов в островках знаний/эрудиции.
S>Читай Кея.
Читать Кея надо было не позже 3-го курса. А теперь всё, опоздал. Он тебе уже не поможет.
S>Только я вижу, что тебя таращит от твоей теории настолько, что ты не пытаешься понять, что тебе пишут в ответ.
Угу... Смотрю, ты готов юлить бесконечно... Дело твоё...
S>>>Это ты убегал и зарывался в тонкости. Я лишь наблюдал за этим и подтролливал.
V>>Подтроллировать надо уметь. А у тебя в каждом втором посте — серьезные ошибки. S>А у тебя-то!
Дык, ты не показал еще ни одной ошибки. Одно юление и манера отвечать вопросами на вопросы.
V>>>>Необоснованно по абзацу целиком. Но мне бы хотелось твою т.з. насчет концепции "непрерывного генерирования сигналов". S>>>Необоснован твой абзац с подпиской на фотоны.
Обоснуй!
Ы?
V>>Дык, давай аргументы. Твоя необоснованность- она в отсутствии обоснования, если ты забыл смысл этого слова. S>А не ты мне хотел показать, как близко ООП к рж,
Я и показал.
S>но потом написал что на самом деле аналога нет?
Не надо меня перефразировать. Я говорил сугубо о ролях в модели. Но сама модель — из жизни, увы. Ты опять попался!
Просто ты не видишь, где проходят границы абстракций и что такое вообще модель.
Смотри внимательней, что происходит: все многочисленные роли посредников, необходимых в рж для генерирования и доставки мне информации о двери, я объединил сначала в один посредник, а затем тот стал исопльзовать ВМЕСТО двери. Я это сделал не из-за кривизны моей умозрительной модели, а исключительно из-за её абтрактности. Напомню, абстракция — это упрощение. То бишь я всего-навсего выкинул кучу деталей, которые не являляются необходимыми для целевой программы. А если бы я так не сделал, что было бы? Напомню:
... нам в любом случае придется вводить фиктивный объект, который будет делать это ВМЕСТО двери.
Плюс еще сама дверь! Не понял?
Смотри раза внимательней: для целей моделирования происходящего, упомянутого "фиктивного объекта, который будет делать это ВМЕСТО двери" — будет более чем достаточно, это ж модель!. то бишь, сама дверь нам не нужна, ууупс! А что остается? Чем будет являться этот "фиктивный объект"? А может он и будет моделью двери, коль именно через него мы получаем о двери необходимую информацию и взаимодействуем с дверью через него?
Хочешь того или нет, но всё это время ты спорил о том, что модель не есть реальная жизнь. Детсад, сорри за повторение. Модель и не должна быть рж, на то она и модель. Но она, тем не менее, модель реально происходящего.
S>Давай так, твоя модель — ты и обосновывай ее близость к рж.
Я уже сделал это бесконечное кол-во раз и ты так и не привел контраргументов.
S>>>По поводу концепции "непрерывного генерирования сигналов", то если ты говоришь о фотонах, а не о волне, то ничего непрерывного в той концепции нет. V>>Любая дискретность происходящего сглаживается физикой/химией колбочек глаза. Уже 100ГЦ человеческий глаз не различает. S>А единичный фотон — различает, ага
Откуда ты вообще сейчас взял "единичный" фотон? Что за флуктуации мыслительной активности? По теме есть что сказать?
V>>В таком категоричном виде — нет ес-но. "События" в ООП в виде мультикаста — оно так прижилось фактически сразу. Объект шлет события и не знает кому. S>знает кому. Делегату. А тот списку подписчиков. Никаких неизвестностей в ООП нет. См. observer.
Я уже сказал, куда тебе смотреть — на медиатор. Фотоны тоже не во всякой среде распространяются. И они таки имеют вполне конкретное направление, которое можно назвать адресом. Твой медиатор — это единственный адрес, о котором знает источник события.
V>>Ну дык, вектор фотонов движения — такой же точно конкретный их адрес. А на пути этого "адреса" ты можешь расположить свои рецепторы. S>Что за на пути адреса?
Именно, это проекция на первые две составляющих полярных координат в 3-хмерном пространстве.
S>Расскажи мне о том как у рецептора есть свой адрес и как рецептор подписывается на сообщение от вектора.
Я уже рассказывал — как. Если конспектом — без фокусировки никак.
V>>Я тебе уже сказал не раз, что есть дарес для фотонов. Хотя, ты и сам должен был знать. Чтобы доставлять фотоны по произвольному адресу, нужны волноводы соотв. радиодиапазона. S>В ООП нет произвольного адреса, есть только конкретные.
Двойка тебе еще и по дизайну. Для того медиатор и нужен, чтобы источник информации ничего не знал о получателе.
V>>Тебе начать рассказывать с фокусного расстояния или с еще более ранних азов оптики? S>На твое усмотрение
ОК, Геометрическая оптика
V>>Т.е. всё это время был лишь протест против словосочетания "естественным образом"? S>Да. Жаль что до тебя это доходило так долго. Но боюсь, что еще не совсем дошло.
А до меня и сейчас твой упрямство не доходит. Я вообще не понимаю позицию из разряда "не знаю и знать не хочу".
Асбтракция — это естественное для человека понятие, т.к. сам человек склонен мыслить абстрактно, выкидывая ненужные детали.
V>>Когда такое говорят о технических моментах, то подразумевают, что некий технический момент для неких условий/ограничений/задачи наиболее удобен. S>Походу ты пропустил начало темы. Речь шла о другом.
Ну побегай, побегай.
V>>Мало ли что "считается". Ты уже достаточно его знаешь, чтобы понимать как на самом деле. На Хаскеле МОЖНО писать чистые участки кода... это да.... S>Ты так и не привел ни одного нечистого куска без использования бэкдоров.
Я могу нечистую программу целиком привести, пойдет? Без каких-либо бэкдоров. Могу еще все побочные эффекты императива повторить на ассоциативном контейнере в Хаскеле, такое пойдет? Я даже могу тебе на С++ привести ф-ию, которая вся сплошь мутабельная в КАЖДОЙ строчке, но при этом будет абсолютно чиста, как слеза младенца. Приводить?
V>>Я кроме "удобства" ещё ни одного вывода не сделал. Остальное — считай разминка для образного мышления и ничего более. Просто я ХЗ почему 10-й пост подряд должен объяснять тебе, что имею право раздавать роли объектам так, как мне, разработчику, удобно. Внося динамику в процесс, увы, удобнее всего наделить дверь "поведением", умением "отвечать" и т.д. Или нам в любом случае придется вводить фиктивный объект, который будет делать это ВМЕСТО двери. S>А я тебе 10-ый пост объясняю что я не оспариваю твоего права раздавать роли как угодно. Я оспариваю то утверждение, что как угодно разданные роли естественным образом соответствуют рж.
Они "не как угодно". Опять и снова курить "информацию". И еще курить цели и задачи моделирования. У меня как раз в модели "нечто, используемое вместо реального объекта", на то она и модель. Глупо с твоей стороны оспаривать право модели быть моделью.
S>>>А теперь о связи между боксированным представлением и вытеканием хаскеля из СП. Просим. V>>Т.е. против аналогичного происходящего в случае энергичных вычислений в ФП возражений нет? )) Я так и думал. S>Ну ты же высосал из пальца то что возражений нет. Есть возражения. Энергичные вычисления тоже могут быть чистыми.
Чистыми могут быть даже вычисления в каждой мутабельной строчке на С++, это не аргумент. Речь была сугубо о последовательности вычислений. Я утверждал, что гарантии очередности вычислений важны. Именно это ты опровергнуть и не сможешь, ес-но, бо это фундаментально.
S>Разница лишь в том, что для вычислимости на энергичных вычислений нужна особая форма if-а.
Какая еще особая? Я тебе уже разложил её в I/K базисе и показал, что для преобразования в конечный код необходимо значение предиката при if. Это всё! неужели до тебя не дошла суть этого разложения? Это уже какой-то полный П.
V>>А требование босксированого представления само по себе накладывает ограничения. То бишь для программы, генерирующей пользу во времени, ты должен понимать, что обработать такую "последовательность" с конца — неэффективно (в отличие от "последовательностей" на сравниваемом там же С/С++)... Хотя, казалось бы, одна строчка разницы в рекурсивном алгоритме... А всего-то добавилось понимание происходящего и ты уже более адекватен с т.з. инструмента. S>В теореме об СП нет ни строчки об эффективности. Поэтому отсыл к эффективности в качестве аргумента не принимается.
Ну побегай, побегай...
А я буду писать эффективные программы. Даже если это будет стоит мне поменять пару строчек местами. ))
V>>Дословно было сказанно так: "в некотором смысле побочный эфект". Никто на молекулы ничего не разнес. Пару коллег решили что это их зведный час и поделились пониманием побочного эффекта на уровне вики. )) Но это как раз фигня и детсад. А вот то, что ты и еще кто-то (уже не помню) с разбега пытались опротестовать ФАКТ упорядочивания вычислений, но быстро обломались, взяв за труд немного подумать — это уже было чуть интересней. S>Факт упорядочивания ЧИСТЫХ вычислений в СП никому не интересен.
Здрастье, приплыли! Ты без этого упорядочивания даже факториал не вычислишь. Причем, это утверждение доказывается ровно в одну строчку. Предлагаю подумать самому.
S>Они упорядочивают побочные эффекты. И не в некотором смысле побочные, а в самом прямом.
if упорядочивает вычисления как таковые. Это фундаментально по своей природе. А чистые они или нет — дело как раз десятое, когда речь идет о конечном вычислителе.
V>>Ну а остальное уже подытоживал: V>>
V>>чистая ф-ия -> порядок вычисления аргументов не важен, так?
S>Чистота функции в общем случае не кореллирует с порядком вычисления аргументов. Т.е. легко показать чистую функцию S>
S>int add(int x, int y) { return x + y; }
S>
S>, для которой порядок вычисления аргументов будет играть роль.
Я не вижу, чтобы ты это показал для чистого ФП.
V>>"в некотором смысле побочный эфект" — я назвал упорядочивание вычислений, на которые можно полагаться в программе. Только из-за этого счел возможным проводить параллели м/у таким ФП и СП, бо происходящее аналогично, как бы тебе не хотелось абстрагироваться от этого. Я тебе весьма удачную аналогию про поезд и стрелки приводил, но ты как вегда бегаешь от неудобных аргументов. S>Упорядочивание вычислений не является побочным эффектом в общеизвестном смысле.
Дык, я и так знаю, что придирание шло исключительно к словам... Просто кривое это придирание... или покажи у меня "побочным эффектом в общеизвестном смысле".
Я ж говорю: натуральный звездный час блеснуть эрудицией, не? В общем, кому как, а мне порция фана.
S>А то что ты используешь некоторые смыслы и тебя не могут понять, то это сугубо твои тараканы.
Дык, если я чего-то недопонял, я переспрашиваю, в каком таком "смысле". Но ты же бодро кинулся отвечать! И даже нагнал пурги сходу в плане отрицания упорядоченности... потом сдулся, правда, бо это было совсем уж нелепо.
V>>Контракт на методы типа? — ес-но! Это непосредственная вотчина современного ООП. Но ты непременно оспариваешь мой тезис, что парадигмы воруют друг у друга наработки. "Баба Яга против!" во всей красе. ) S>Тебе придется убедить меня что туплы/стракты с функциями/указателями на функции не использовались до засилия ООП.
Я и не собраюсь. Более того, я же и утверждал, что ООП оформило в одну парадигму некоторые уже реально устоявшиеся в процедурном подходе практики. Но понятие контракта на методы типа в современном его смысле выкристаллизовалось именно в ООП. Это медицинский факт.
S>>>Что за "экземпляр" монады? V>>Это такой функциональный объект. S>Что за функциональный объект?
Это пара { ф-ия, контекст }.
S>>>Из того что мы можем что-то проэмулировать совсем не следует что мы должны что-то эмулировать. V>>Дык, а кто тебя спросит, должен ты или нет? Работа с dictionary в ФП именно так и ведется и я тебе лишь демонстрирую, что "протягивая" последовательность смены состояний некоего объекта (например, dictionary) в ФП можно запросто получить все те же самые эффекты, что в мутабельном мире. Какая нафик разница самим этим эффектам, на каком уровне абстракции они возникли? S>Ты ответил на какой-то шум в своей голове, а не на мое утверждение.
Я ответил на твой вопрос "должны мы или нет?". Перечитывать до просветления.
Мы и так эмулируем по той лишь причине, что мы пишем модель. Т.е. у нас каждая строчка кода заведомо эмуляция.
V>>>>Это я уже молчу о том, что регистровая память полностью эквивалентна ассоциативной, если за ключ ассоциации взять некий порядковый номер. Как тебе такая изоморфность мутабельной и иммутабельной низлежащей модели? Вот нарисуй на Хаскеле некий dictionary<адрес, объект> и смоделируй на этом dictionary память компьютера c операциями read/write (возвращающими новое состояние "памяти", ес-но). Потом попробуй найти отличия от императивного мира. S>>>во-первых, отличия на поверхности. Код эмуляции будет чистым.
S>Если ты поставил себе цель воплотить все необходимые побочные эффекты в конечной программе, то на что ты жалуешься?
Опять, кто тебя спросит? Никто не задается целью воплотить специально, ес-но. Проблемы всегда из-за того, что там, где можно наплодить граблей специально, можно точно так же неспециально.
S>И видишь ли, меня интересует не только сама конечная программа.
Дык, это я же тебе и говорю, что тебя боле интересуют догмы. А меня интересует исключительно кач-во конечной программы. Поэтому я закоренелый циник. Мне все ср-ва хороши, если они работают.
V>>Я уверен — случайно, но ведь попал! В Паскале с рождения присутствует замыкание локальных (вложенных) процедур на контекст вышестоящих. Причем, отменить это поведение нельзя. S>Вообще-то я рассчитывал что тебя возмутит идея о происхождении паскаля от лямбда счисления.
Да тут и школьнику было понятно, на что ты расчитывал. У тебя в каждом втором посте основной аргумент: "О нет! Неужели?!!" и далее в лицах расписывается трагизм происходящего. Имею полное морального право посшибать лулзов с такого абсолютно неадекватного на техническом форуме подхода к обсуждению.
S>Но раз она тебя не возмутила и ты воспринял ее с воодушевлением, то пора завязывать. Я лишь хотел сказать что возможность эмуляции не доказывает родство более близкое чем вычислительная эквивалентность ЛС и МТ.
Да понимаешь... В современных высокоуровневых программах такая эмуляция может происходить взаимно-многократно через многие слои либ... независимо от твоего желания. Именно поэтому в программах на Хаскеле программисты точно так же допускают кучу ошибок, которые приводят к ошибкам в том самом побочном эффекте, который целевой у всех программ. В общем, ты правильно говоришь насчет того, что "код эмулятора чист". Да, некий кусочек кода может быть чист. Как насквозь мутабельная в каждой строчке ф-ия на С++ может быть чиста... А что толку? Львиная доля современных ошибок (или неожиданных эффектов, не позволяющей программам полноценно работать, например, "пространственный дедлок" двух ендпоинтов в TCP-стеке) случается от недостаточного понимания программистами механики инструмента, включая особенность работы низлежащей аппаратуры (и сети). Как раз по работе много лечу подобного кода... Отсюда столько цинизма, бо повидал достаточно...
Re[42]: Как мало людей понимает ООП так же, как это понимаю великий Я...
Здравствуйте, grosborn, Вы писали:
>> V>>Да и какая разница, в быту или нет, если наша программа всегда абстракция прямо по определению? Тебе вообще не должно быть важно, сама дверь испускает сигнал или отражает его так, что ты способен расмотреть эту дверь. >> S>Мне неважно, но именно ты ведь пытаешься натянуть физику на ООП. >> >> Наоборот, я показываю правомочность того, что дверь мне "отвечает" на вопрос. То бишь показываю физический смысл этого явления. Хотя, я ни разу не обязан был этого делать для тебя, т.к. в умозрительной модели я имею право раздать роли обектам как мне удобно. Даже если такое распределение ролей не имеет физического аналога в реальном мире. Просто я ХЗ как тебе втолковать сей очевидный момент, вот и пришлось демонстрировать аналогичное происходящее в реале.
G>Ты эта, как у женщин извечный вопрос про моду, как бы так одеться, что бы раздеться?
G>Сам же признаешь, что смоделировать реальность невозможно,
G>ты ни разу не моделируешь реальность, а моделируешь свои мысленные абстракции
Дык, ни я ни ты я по-другому и не умеем. Мы моделируем наше представление о реальности. Как оно на самом деле всё-равно никто не знает.
G>да еще и раздавая роли как тебе удобно, то есть не основываясь на реальности.
Ты очень правильно подобрал слово "как удобно", хорошо, что не "как угодно". Удобство тут проявляется исключительно в избавлении от подробностей. Но ведь это и есть право модели, не? )))
G>Ну давайте все вместо не связанной с реалом абстракции bool Дверь.Открыта будем подписываться векторами на фотоны, что бы определить открыта ли она.
Давай, попрбуй фотонами. Боюсь, фотоны в программе у тебя тоже будут воможны лишь в виде их модели. Собственно, свойства get — это и есть модель возможности наблюдения при надобности неких характеристик/состояний объектов.
G>Представляю как ты там программируешь
Боюсь, пока не представляешь. Еще рано.
G>Попытка "моделировать реальный мир", это костыль для людей не знающих или не способных найти эффективное решение задачи.
Пустозвонство и бла-бла-бла. Проходили многократно... а стоит начать разбирать любой пример — и всё-равно сдуешься.
G>Если ты не можешь создать свою абстрактную модель направленную на решение задачи, конечно ты будешь пытаться что-то там в своем мозгу "моделировать". Если не знаешь чисел и математики, то считать ты вынужден моделируя реальный мир — загибая пальцы.
Ох уж эти мне интернетные умники, ловящиеся на собственных аналогиях... я тебе как бывший разработчик аппаратуры скажу, что двоичная железка при сложении именно "загибает пальцы" и "переносит в уме".
А если ты попытаешься в своей работе программиста подходить к числам в программе, как в математике... кароч, ты будешь первый претендент при сокращении рабочих мест, только и всего. Есть математика фундаментальная, а есть прикладная. Программист должен владеть разделами и той и той. Ты должен понимать, что есть дискретизация, что есть цифровое представление значение, что есть шумы округления и т.д. до бесконечности... Это если мы всё еще говорим о цифровой модели какой-нить математики. Все цифровые эффекты представления чисел, кстате, тоже математикой описываются, но уже прикладной.
V>>На Хаскеле МОЖНО писать чистые участки кода... это да.... K>Да, и весь код из таких участков и состоит.
А толку, если на них можно огрести точно такие же побочные эффекты? Какая разница на каком уровне абстракции мы эти побочные эффекты огребаем? У нас в программе слоёв абстракций — мильон.
V>>Т.е. против аналогичного происходящего в случае энергичных вычислений в ФП возражений нет? )) K>Возражение простое, ваша посылка "все дело в ленивости" — неверная.
Это не моя посылка. Это был ответ на детсад с попыткой попытку объяснить мне, как работает if в Хаскеле, т.е. оппоненты мне пытались объяснить как работает ленивость, но не опровергнуть фундаментальное требование упорядочивание вычислений. Я им и показал, что именно они мне пытались объяснить, а чего сами не понимают.
K>ну и все ваши выводы из неверной посылки, следовательно, тоже ошибочны.
Уже второе подряд безосновательное утверждение. Давай или ближе к телу или никак — всё-таки глубоко ветка ушла.
V>>чистая ф-ия -> порядок вычисления аргументов не важен, так? K>Нет, не так. V>>Ну т.е. прикол-оксюморон и ничего больше... K>Ну, неправильная посылка -> абсурдный вывод. Все как обычно.
Ясно. Аргументов не будет.
V>>"в некотором смысле побочный эфект" — я назвал упорядочивание вычислений, на которые можно полагаться в программе. K>В императивных языках — упорядочивание неявное. В чистых ФЯ — явное. Вот такая вот разница.
А мне это зачем ты пишешь? Пиши оппонентам. Я им это несколько постов пытался объяснисть и не уверен, что дошло.
V>> Только из-за этого счел возможным проводить параллели м/у таким ФП и СП, бо происходящее аналогично
K>Происходящее в чистых ФЯ и императивных языках настолько неаналогично, что никакий пользы из проведения аналогий нельзя извлечь вообще.
Это самообман, причем в клинической стадии. Подозреваю — как обычно из-за фривольного перепутывания понятия "иммутабельности" и понятия "чистоты кода", как это было при обсуждении const рядом. Не надо мешать одно с другим.
K>Чем дальше вы проводите аналогию — тем серьезнее проблемы с пониманием.
Не надо проводить аналигии вместо меня и приписывать мне лишнее. Все сообщения на месте, можно освежить, что именно я пишу.
S>>>Что за "экземпляр" монады? V>>Это такой функциональный объект. K>Это не ответ на вопрос.
Это ответ. Курить что есть функциональынй объект.
V>>волнует конечная генерируемая программой польза, то бишь её побочные эффекты. K>Опять же — неверная посылка. "Генерируемая программой польза" — это не "побочный эффект", а эффект самый что ни на есть "прямой" — результат.
Отлично, стоило тебе попытаться обосновать хоть одно своё "неверно" и ты сразу сел в лужу. Видишь ли... Наблюдать результат работы программы можно только через побочные эффекты. Без побочных эффектов ты даже не будешь знать, работает программа или нет.
V>>и защиты от них НЕТ. K>Наоборот — защита есть. Ради этого все и затевалось.
Это защита от нерадивого программиста уровня 0. Т.е. самообман. Если я могу без всяких бэкдоров в абсолютно чистом ФП-коде проэмулировать специально все случайные побочные эффекты, бывающие в императиве... то кто помешает произойти этому же в достаточно сложной программе случайно? Да и это необязательно до тех пор, пока программисты допускают на функциональных языках так же много ошибок, как и на любых других.
Просто GC и иммутабельность помогают от тех самых ошибок уровня 0. Ну ОК, отлично. Только оба упомянутых перпендикулярны как чистоте, так и ссылочной прозрачности, а лишь эти последние 2 характеристики являются целевыми.
Здравствуйте, Ikemefula, Вы писали:
I>Это зачатки функциональщины, а ты записываешь это в процедурное.
Вы как-нить договоритесь м/у собой. )))
А то оппонент обиделся и написал:
Вообще-то я рассчитывал что тебя возмутит идея о происхождении паскаля от лямбда счисления. Но раз она тебя не возмутила и ты воспринял ее с воодушевлением, то пора завязывать.
Здравствуйте, samius, Вы писали:
S>А вот если поковыряться в википедии, то выяснится что термин "замыкание" при упоминаниии вложенных процедур паскаля (с его рождения) ты употребил совершенно напрасно.
Интересно, а на чем ты делал лабораторки по программированию в ВУЗе?
Здравствуйте, samius, Вы писали:
S>А замыкание продлевает время жизни связанного окружения до времени своего существования,
Так и есть.
S>которое не ограничено временем выполнения внешней функции.
Для Паскаля именно временем выполнения внешней ф-ии и было ограничено.
S>Таким образом, пока паскаль располагал локальные переменные на стеке, его вложенные функции не могли считаться замыканиями.
Замыканию вообще фиолетово, как переменные располагаются. Локальный контекст одних вычислений доступен в контексте других. Это всё.
Вот определение из вики:
Замыкание (англ. closure) в программировании — процедура или функция, в теле которой присутствуют ссылки на переменные, объявленные вне тела этой функции и не в качестве её параметров (а в окружающем коде). Говоря другим языком, замыкание — это процедура или функция, которая ссылается на свободные переменные в своём лексическом контексте.
Паскалевские локальные процедуры/ф-ии в точности соответствуют.
Здравствуйте, samius, Вы писали:
S>Замыкание — это в основном и есть способ реализации, который отличается от способа реализации через передачу указателя на фрейм стека.
А какая разница, на фрейм переменных в стеке был передан указатель, или на память из кучи?
Ты посомтри, до чего ты уже дошел в расуждениях. Ты всерьез претендуешь на то, что именно такая твоя формулировка, относительно указателя на непременно фрейм из стека будет являться отличительной для "ненастоящих" замыканий? ))
S>Именно потому и отличия в возможностях.
Как раз в возможностях никаких отличий нет и не может быть. Есть полноценный доступ к переменным, объявленным во внешнем контексте.
S>Способ реализации "замыкание" в полный рост может использоваться и для вызовов вложенных функций внутри вложенной (т.е. без передачи вложенной функции наверх).
Вообще-то вниз. Но разве нас интересует механика? Ведь это можно сделать в ЛЮБОЙ механике. Например, при оптимизации локальных замыканий компиляторы функциональных языков могут поступать точно так же как Паскаль — то бишь не создавать фреймы переменных на куче для замыканий, если компилятор видит, что время жизни этих переменных ограничено временем жизни контекста, в котором они определены. То бишь, если лямбда вызывается непосредственно, а не передается куда-то и не возвращается как результат ф-ии.
S>Но это лишь потому, что некоторым компиляторам лень разбираться, в каком контексте будет вызываться вложенная функция. Так, например C# не разбирается и использует замыкание(т.е. технику реализации) даже там где передавать вложенную функцию вовне не надо, а можно было бы обойтись указателем на фрейм стека.
Потому что в CLI никак нельзя представить указатель на фрейм стека. То бишь, если делать хоть какую-то оптимизацию, то разве что ref-type анонимного объекта-замыкания переделать в value-type, экземпляр который передавать по ссылке... Но в C# с оптимизацией вообще непонятно что происходит. Выглядит так, что ничего.
S>Но нет, не поддерживает по определению замыкания и нелокальной переменной.
-1
Ну блин, понимать формулировки надо таки уметь. См. хотя бы вики.
Здравствуйте, Sinclair, Вы писали:
G>>Вложенные процедуры имеют пересекающиеся scop-ы. S>О как. Я правильно понимаю, что в C++ фигурные скобочки — это уже замыкание???
А разве ты можешь для таких "скобочек" вводить переменные-параметры и вызывать многократно с различными значениями этих параметров? Если бы мог — были бы полноценные замыкания.
S>У вас странное (для меня) понимание локальности. Но это, наверное, оттого, что я слишком много читаю Липперта.
Это он придумал замыкания?
G>>Лень тут совершенно не при чем. J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации. S>Вот это новости! Куда делся стек? В прошлый раз, когда я читал ECMA-338, стек дотнета был на месте. S>Коллега, вы меня пугаете! Можно пруфлинк в студию?
Ключевое выделено. Нет никакого требования размещать фреймы локальных переменных в том же стеке, что упоминается в ECMA-338.
Здравствуйте, Sinclair, Вы писали:
G>>А-ха-ха, заметил свою ошибку и пытаешься меня подловить, хамишь опять. Это была твоя мысль что у C# нет стека, это залет как сказал бы vdimas. S>Если вы — второй аккаунт vdimas'а, то вас я тоже буду игнорировать.
Какие глупоcти, ты же видишь, что я пишу посты любой степени провокационности из собственного ника? Т.е. нафига мне дополнительные ники для того же самого, типа как у некоторых тимовцев?
S>А если нет, то мысль про отсутствие стека в C# я взял отсюда: S>
S>J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.
S>Вы точно уверены, что это не вы писали?
Он прав, коль речь была о локальных переменных. Нет там требований или рекомендаций располагать фреймы локальных переменных на том стеке, который описан в инструкциях ВМ.
Здравствуйте, vdimas, Вы писали:
V>А толку, если на них можно огрести точно такие же побочные эффекты?
Об этом можно было бы поговорить, если бы можно было "огрести". Но, раз уж "огрести" (без лупхолов всяких) нельзя — то и говорить тут не о чем.
V>Какая разница на каком уровне абстракции
Если нет разницы на каком уровне абстракции — то в чем вообще может быть разница?
V>>>Т.е. против аналогичного происходящего в случае энергичных вычислений в ФП возражений нет? )) K>>Возражение простое, ваша посылка "все дело в ленивости" — неверная.
V>Это был ответ на детсад с попыткой попытку объяснить мне, как работает if в Хаскеле, т.е. оппоненты мне пытались объяснить как работает ленивость, но не опровергнуть фундаментальное требование упорядочивание вычислений.
Вы имеете в виду объяснение, что в ветках хаскельного if не производится действий, а возвращается то действие, которое будет произведено? Ленивость этому совершенно ортогональна. Тут обычные первоклассные функции. В строгом чистом языке будет происходить то же самое.
V>>>чистая ф-ия -> порядок вычисления аргументов не важен, так? K>>Нет, не так. V>Ясно. Аргументов не будет.
Да какие проблемы с аргументами? Если у нас язык строгий, то аргументы вычисляются перед тем, как они передаются в функцию. Таким образом нет никакой связи между чистотой функции и порядком вычисления аргументов. Т.е. ваша посылка неверна.
Если язык ленивый, то порядок вычисления аргументов определяется кодом функции и он, разумеется, важен.
-- определяем чистую функцию (||) двумя способами:
-- один сначала вычисляет правый аргумент
> let { _ ||> True = True; True ||> _ = True; _ ||> _ = False}
-- другой - левый
> let { True <|| _ = True; _ <|| True = True; _ <|| _ = False}
-- в "тотальном" языке разницы между ними действительно не было бы:
> [(a, b, a ||> b) | let xs = [True,False], a <- xs, b <- xs]
[(True,True,True),(True,False,True),(False,True,True),(False,False,False)]
> [(a, b, a <|| b) | let xs = [True,False], a <- xs, b <- xs]
[(True,True,True),(True,False,True),(False,True,True),(False,False,False)]
-- Но в тьюринг-полном разница есть:
> True <|| undefined
True
> True ||> undefined
*** Exception: Prelude.undefined
> undefined ||> True
True
> undefined <|| True
*** Exception: Prelude.undefined-- именно это и имеет определяющее значение, а не чистота.
-- "левый" ИЛИ можно использовать для сворачивания бесконечных cons-списков:
> foldr1 (<||) . repeat $ True
True-- "правый" - нет.
> foldr1 (||>) . repeat $ True-- эта музыка будет вечной (если хватит места в куче)
-- в случае snoc-списка - все ровно наоборот.
Т.е. и в этом случае ваша посылка неверна.
K>>Происходящее в чистых ФЯ и императивных языках настолько неаналогично, что никакий пользы из проведения аналогий нельзя извлечь вообще. V>Это самообман, причем в клинической стадии.
Это реальность данная нам в ощущениях. Аналогия между декларативным ФП и императивным СП ложная — она не поможет понять ни того ни другого, а вот помешает — легко. Этот тред — очередное подтверждение.
S>>>>Что за "экземпляр" монады? V>>>Это такой функциональный объект. K>>Это не ответ на вопрос. V>Это ответ. Курить что есть функциональынй объект.
И это — не ответ.
K>>Опять же — неверная посылка. "Генерируемая программой польза" — это не "побочный эффект", а эффект самый что ни на есть "прямой" — результат. V>Отлично, стоило тебе попытаться обосновать хоть одно своё "неверно" и ты сразу сел в лужу. Видишь ли... Наблюдать результат работы программы можно только через побочные эффекты. Без побочных эффектов ты даже не будешь знать, работает программа или нет.
Наблюдать результат работы программы можно 1) непосредственно, не наблюдая никаких "эффектов". 2) Наблюдая эффекты, но с какой стати они должны быть "побочными"? Эффект побочный, когда он не отражен в сигнатуре функции — но в чистых ФЯ так не бывает — все эффекты отражены в сигнатуре — побочных нет.
V>Если я могу без всяких бэкдоров в абсолютно чистом ФП-коде проэмулировать специально все случайные побочные эффекты, бывающие в императиве... то кто помешает произойти этому же в достаточно сложной программе случайно?
Никаких побочных эффектов вы без бекдоров не "проэмулируете". Все эффекты в чистом ФЯ прямые и явные — "побочных" без "бэкдоров" не бывает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, grosborn, Вы писали: G>Крутись-вертись но свои измышления мне приписать не получится. Это ты придумал что у C# нет стека.
Ок, отлично. Вы попали в мой личный игнор-лист. Прощайте.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
I>>Это зачатки функциональщины, а ты записываешь это в процедурное.
V>Вы как-нить договоритесь м/у собой. ))) V>А то оппонент обиделся и написал:
Вообще то самиус писал это тебе а не мне.
V>
V>Вообще-то я рассчитывал что тебя возмутит идея о происхождении паскаля от лямбда счисления. Но раз она тебя не возмутила и ты воспринял ее с воодушевлением, то пора завязывать.
Ты сам то понял, что процитировал ? функционалное это и есть лямбда счисление. Ты головой то думай. в однмо месте ты с этим соглашаешься, а как доходит до локальных функций, то вдруг начинаешь это же самое отрицать. Естественно, старый паскаль это не функциональный язык, но в ем есть поддержка некоторых функциональных фич. Новый паскаль вполне себе функциональный — легко.
> G>Крутись-вертись но свои измышления мне приписать не получится. Это ты придумал что у C# нет стека. > Ок, отлично. Вы попали в мой личный игнор-лист. Прощайте.
Я безмерно счастлив, вспоминая все твои перевирания слов и тролление.
Здравствуйте, samius, Вы писали:
V>>Молодца, ты попался на тривиальный очевидный момент. Потому что поторопимшись. Давай ты напишешь пример, где предикат при if ОБЯЗАТЕЛЬНО вычисляется, но не будет вычислена возвращаемая if ветка. S>Да, соглашусь что именно в этом я попался. Но в остальном притягивании ФП к СП ты так и не отмазался.
Ну дык, я же не виноват, что ты не поспеваешь за мной. )
Итого:
1. аргумент-предикат вычисляется тогда, когда надо будет вычислить одну из веток then-else.
2. аргумент-предикат обязательно вычисляется перед вычислением удачной выбранной ветки.
Уффффф... ))
V>>Ты увидишь кое-что важное, когда наконец сможешь этот пример породить. Что именно? А достаточно будет сравнить полученный вариант с вариантом работы некоего вычислителя на энергичной технике и попробовать найти отличия в семантике. S>Ты уже задолбал делать выводы по вычислителю.
Дело не в выводах, а в том, что все рассуждения должны сойтись на всех моделях, соответствующих рассматриваемому (в данном случае — чистому ФП). ИМХО, полезно крутить в голове семантику собственного кода в случае его ленивого и не ленивого исполнения, верифицируя её идентичность — это как проверка уравнения после решения... поможет, в случае чего, найти ошибки в неверном решении.
V>>Так что ваш аргумент, по-сути, о том, что ф-ия if, как и все остальные ф-ии Хаскеля — ленивые. Это был, конечно, очень крутой и правильный аргумент. Только ни о чем, бо он сугубо о семантике низлежащего вычислителя. Т.е. ты имеешь полное право писать свои чистые ф-ии вовсе не заботясь о низлежащей семантике вычислителя. Где-то так... S>Аргумент был не только в ленивости if-а, если ты внимательно читал. Аргумент был еще и в том, что вычисление ветки чисто.
Это НЕ принципиально. В насквозь императивном языке вычисление ветки тоже может быть чисто, даже если будет мутабельность в каждой строчке кода. И прямо отсюда тебе надо искать еще аргументы в разнице происходящего.
S>>>По другим пунктам тоже можно поглядеть. S>>>1. — сиквенсинг в хаскеле нужен лишь для организации побочных эффектов. Никакое вычисление в нем не нуждается.
V>>Я таки вижу, что именно само вычисление раскладывают на шаги: сначала задают промежуточные данные (let var=...), потом из них — конечные (in expr). Опять и снова, тот факт что вычисление производится в ленивой манере — ненужные подробности. Теперь найди отличия в описании шагов таких вычислений от описаний точно таких же шагов, записанных в императивном языке (порой с точностью до синтаксиса в compile-time и конечного кода в runtime). Другая модель? Хмм... арифметика, она и в Африке арифметика, как раз на арифметике можно абстрагироваться от любых низлежащих моделей вычислетелей. S>отличие в том, что каждый императивный statement несет побочный эффект, иначе без него можно обойтись.
Неверно. Не каждый. А в языке D можно задать гарантии, что ф-ия будет pure, то бишь не будет производить побочных эффектов. При этом будет оставаться мутабельной.
S>>>А Бём-Якопини говорили именно о вычислении функций. Вобщем первый пункт пролетает.
V>>Ну, если подходить догматически, расставить рамки и т.д. то пролететь может что угодно. А если рассматривать лямда-исчисление только как входные описания для некоего вычислителя на машине Тьюринга (а оно так и есть) — то я имею право искать похожие механизмы. ИМХО, ветвление и разложение сложных вычислений на более простые шаги — это фундаментальные практики, и там и там. S>Да, я вижу что сводимость вычислителей к МТ дает тебе право не только искать, но даже утверждать об императивности всего что шевелится вплоть до языков высокого уровня. Неясно только, почему Пролог оттуда выбился.
Потому что Пролог выполняет высокоуровневый дополнительный алгоритм, вносящий собственную семантику, а ФП и ИП — нет. ФП и императивные языки они описывают одни и те же вычисления ровно с одной и той же степенью подробности (при прочих остальных равных, например при наличии GC). Просто описывают в разном базисе. Из-за идентичной степени подробности мы получаем такой эффект, что если ветвление присутствует в императивном варианте, то оно будет и в ФП-варианте аналогичного кода. Именно такое взаимное обязательное отображения дает мне право назвать эту практику (ветвление) фундаментальной практикой, которая не только имеет аналогичную семантику для ФП и императива, но даже без всякого вреда для этой семантики может быть одинаково реализована что там что там, например когда ФП работает в энергичной манере. А теперь поднимись на пару абзацев выше, и посмотри, что я говорил про проверку семантик на различных моделях.
V>>Цикл — это повтор одного и того же кода. И ты тут пытаешься манипулировать, бо результат подпрограммы будет один и тот же только при одних и тех же входных данных. А если входные аргументы на каждом шаге цикла разные, то и результат будет разный. Почему-то комбинатор неподвижной точки так и называют — циклом или рекурсией, а вы тут упрямитесь? )) S>Тебе уже намекали что у тела цикла нет результата, потому цикл без побочных эффектов способен лишь греть атмосферу.
Мне намекали неграмотные коллеги и я уже на это отвечал. Курите, для начала, определение чистоты функций. В абсолютно чистой ф-ии запросто может быть обычный императивный "мутабельный унутре" цикл.
Собсно, я начинаю понимать причины твоего спора со мной. )))
Это уже даже не догматика, а натуральное плавание в базовых понятиях...
V>>Да ради бога. Мне просто опять прикольно как ты скачешь с теории на сугубо подробности (ленивое выполнение в случае if) и потом обратно. Эдак даже не получается ровненько провести границы догм, приходится бегать подправлять? S>А мне прикольно как ты опять влез на МТ
Я влез только для демонстрациия обязательного взаимного аналогичного отображения. А то некоторые порой забываются...
S>V>Ес-но, она Тьюринг-полна, потому что может быть исполнено на конечном вычислителе, который ВЫНУЖДЕН аргументы некоторых ф-ий считать в определенном порядке. S> S>Твоя аргументация убивает
Опять показываешь всю степень трагизма? )
А меня убивает твоя оторванность от понимания работы ФП, хотя ты выступаешь последнее время со стороны этого "лагеря".
V>"в некотором смысле побочный эфект" — я назвал упорядочивание вычислений, на которые можно полагаться в программе.
В императивных языках — упорядочивание неявное. В чистых ФЯ — явное. Вот такая вот разница.
И далее почитай ветку, там более-менее по-делу.
И, хотя я несогласен с формулировкой о неявном упорядочиваниия в императивне (оно дается сверху как обязательно присутствующее в каждой строчке программы), но с явным упорядочиванием на if в ФП он не только не спорит, он даже показывает в след. по ветке посте
, почему именно так. Показывает, ес-но, отталкиваясь от конечности вычислителя! Ну разве не фан мне тут с вами, горемычными? )))
V>>На самом деле вы тут фигней маетесь, но мне было лень расписывать, думая, что вы и так знать должны. Само использование сочетания комбинаторов I/K таково, что упорядочивание происходит как упорядочивание вызовов ф-ий I(K/KI?(x,y)), то бишь происходит такое же упорядочивание как на монаде IO, технически реализуемое как вложение вызовов ф-ий друг в друга. То бишь, даже если в синтаксисе выражения if-then-else все аргументы выглядят как аргументы одного уровня иерархии вычислений, на самом деле одни из них вкладываются в низлежащие вызовы, при росписи этого дела на комбинаторах. И хорошо видно, что для того, чтобы раскрыть цепочку комбинаторов, СНАЧАЛА надо определиться с составом самой этой цепочки (K/KI?), то бишь с аргументом при if — true или false, иначе дальнейшие комбинаторные преобразования в конечный исполняемый код будут невозможны. Я так-то не собирался грузить всей этой догматической чепухой, полагая очевидным здравому смыслу, что аргумент при if, если он вычисляется, он вычисляется всегда РАНЬШЕ нужной ветки (даже если ветка не вычисляется вовсе затем), т.е. считал, что такое де-факто упорядочивание очевидно здравому смыслу в любой технике исполнения ФП, что в энергичной, что в ленивой.
S>Что-то много букав.
Блин, хорош прикалываться. А так и будем ни о чем.
Я думал, что очевидно было это: для преобразования вычислений в код необходимо выяснить вид комбинации:I(K(x,y)) или I(KI(x,y)). Если предикат при if невозможно вычислить в compile-time, то такое выяснение оставляется на run-time. То бишь, как ни крути, но получаетсяч фундаментальное требование сначала найти значение true/false (именно уже само значение, а не ленивую ф-ию), и только потом получить правильный хвост выражения, будь он хоть ленивым, хоть энергичным. А все мои якобы "провокационные" заявления об идентичности происходящего что в ФП, что в императиве исходили из того, что в энергичной технике исполнения ФП будет ровно аналогичное (почему так — уже доказал), а семантика ленивого вычисления не должна отличаться от семантики энергичных. Всё!
S>Да, конкретно в хаскеле K/KI будет вычислено раньше.
Да в любом, хоть в чистом, хоть в глязном, хоть в ленивом, хоть в энергичном — везде будет раньше. Через это не перепрыгнуть.
S>понимаешь, в СП можно написать как "a;b;", так и "b;a;". В результате мы будем иметь разный мир (т.к. результатов у стейтментов нет).
Ээээ... а причем тут это и ветки if?
И вообще, насчет стетментов и "мира" — отдельная тема. Как раз, если мы рассматриваем не зачаточный императив, а именно знакомое нам СП, то во всех СП-языках обязательно присутствуют локальные переменные. То бишь стейтменты в СП-языках могут не оперировать глобальными переменными, то бишь в СП "изкаробки" заложена возможность писать чистые ф-ии, даже если код этих ф-ий мутабельный или содержит императивные циклы.
Здравствуйте, Klapaucius, Вы писали:
V>>А толку, если на них можно огрести точно такие же побочные эффекты? K>Об этом можно было бы поговорить, если бы можно было "огрести". Но, раз уж "огрести" (без лупхолов всяких) нельзя — то и говорить тут не о чем.
Я уже рядом объяснял — как. Например, эмулируешь явно на ассоциативной памяти некую регистровую память — и отгребай сколько угодно. Т.е. достаточно, чтобы "объекты" дизайна ссылались друг на друга не прямо, а косвенно — через такую ассоциативную память (через некий ключ). То бишь, эмулируешь ту самую косвенную адресацию из-за которой всё и происходит в императиве, и получай сколько угодно точно такие же побочные эфекты, ноу проблема.
V>>Какая разница на каком уровне абстракции K>Если нет разницы на каком уровне абстракции — то в чем вообще может быть разница?
Я и говорю, что в строгом смысле разницы вообще нет. Вся разница в том, что случайные побочные эффекты в случае ФП можно огрести не на уровне строчек исходника, а на уровне происходящего м/у оперируемыми абстракциями. Как тут рядом правильно хватались за соломинку: "но ведь код эмулятора чист!"
О да! Код эмулятора чист.
Дык, фан в том, что в императивном ПО тоже на уровне строчек исходника довольно редко случайные эффекты возникают (если уж совсем студентов не брать). Всё больше где-то при нагромождении абстракций.
V>>Это был ответ на детсад с попыткой попытку объяснить мне, как работает if в Хаскеле, т.е. оппоненты мне пытались объяснить как работает ленивость, но не опровергнуть фундаментальное требование упорядочивание вычислений.
K>Вы имеете в виду объяснение, что в ветках хаскельного if не производится действий, а возвращается то действие, которое будет произведено? Ленивость этому совершенно ортогональна. Тут обычные первоклассные функции. В строгом чистом языке будет происходить то же самое.
Думаю, ты ошибаешься. В строгом чистом языке вообще нет никакого требования, чтобы if возвращало действие. В энергичном ФП-языке if возвращает значение, а не ленивое тело одной из своих веток then-else. См. хотя бы язык Схема — покатит как пример чистого языка? Чтобы вернуть из ветки if ПФ в Схеме, это надо описать явно. Но ветка в любом случае вычисляется энергично, просто результатом вычисления ветки будет ПФ.
K>Да какие проблемы с аргументами? Если у нас язык строгий, то аргументы вычисляются перед тем, как они передаются в функцию.
Правильно.
K>Таким образом нет никакой связи между чистотой функции и порядком вычисления аргументов. Т.е. ваша посылка неверна.
Это не моя посылка, это мне там же и писали, что для чистого языка порядок вычисления аргументов не важен. Я лишь показываю, что для ветвления — важен. То бишь показываю, что if НЕ является обычной ф-ией. Поэтому, отдельные рассуждения относительно операции ветвления, вести можно. (Отдельные от семантики обычных ф-ий в ФП).
Даже если ты приведешь на Хаскеле ф-ию, которая будет работать как if... То она будет работать исключительно из-за ленивости Хаскеля. В энергичном языке ты никак не сможешь заменить if некоей равноправной остальным ф-ией.
K>Если язык ленивый, то порядок вычисления аргументов определяется кодом функции и он, разумеется, важен.
Елки, единственно здравомыслящий человек во всей ветке. )))
Собсно, повторяешь мои перефразированные слова.
K>-- Но в тьюринг-полном разница есть:
Вернее, в конечном вычислителе разница есть. Твой пример можно было сократить до 2-х строчек.
Если бы был вычислитель, выполняющий бесконечный цикл за секунду, работали бы оба твоих варианта, ес-но. ))
Ты опять, по-сути, повторяешь мои рассуждения.
Не желаешь попробовать верифицировать вот эти рассуждения насчет росписи if в базие I/K?
Исходное выражение на if: I(K/KI?(x,y))
...для того, чтобы раскрыть цепочку комбинаторов, СНАЧАЛА надо определиться с составом самой этой цепочки (K/KI?), то бишь с аргументом при if — true или false, иначе дальнейшие комбинаторные преобразования в конечный исполняемый код будут невозможны.
для преобразования вычислений в код необходимо выяснить вид комбинации:I(K(x,y)) или I(KI(x,y)). Если предикат при if невозможно вычислить в compile-time, то такое выяснение оставляется на run-time. То бишь, как ни крути, но получаетсяч фундаментальное требование сначала найти значение true/false (именно уже само значение, а не ленивую ф-ию), и только потом получить правильный хвост выражения, будь он хоть ленивым, хоть энергичным.
K>>>Происходящее в чистых ФЯ и императивных языках настолько неаналогично, что никакий пользы из проведения аналогий нельзя извлечь вообще. V>>Это самообман, причем в клинической стадии.
K>Это реальность данная нам в ощущениях. Аналогия между декларативным ФП и императивным СП ложная — она не поможет понять ни того ни другого, а вот помешает — легко. Этот тред — очередное подтверждение.
Ладно, в эту сторону бодаться бесполезно, бо в этой стороне спорим об ощущениях.
Лично мне ничего не мешает понять ни то, ни другое. То бишь, запросто смог бы писать компиляторыы ФП-языков, как энергичных, так и ленивых. (Как там говориться — понять язык, это уметь написать его компилятор). Точно так же как я могу эмулировать работу ФВП на процедурных языках: http://www.rsdn.ru/forum/philosophy/4841569.1.aspx
Но ощущения у меня другие, се ля ви. Я вижу такую фундаментальную вещь, что в императиве и ФП приходится описывать алгоритмы ровно с одной и той же степенью подробностей. (Именно поэтому я не люблю, когда ФП награждают эпитетом "деларативный"). А об однозначном отображении операции "ветвление" для обоих таких вариантов, описанных с однойи той же степенью подробностей, я уже высказывался: http://www.rsdn.ru/forum/philosophy/4859218.1.aspx
Я ведь всё-равно не поверю, что ты, или другие коллеги не видят этого однозначного отображения. Просто это какая-то специальная самоустановка относительно ФП — "забыть всё что знал и начать жизнь сначала". )))
Хрень полная, как по мне. Одно другому не мешает.
S>>>>>Что за "экземпляр" монады? V>>>>Это такой функциональный объект. K>>>Это не ответ на вопрос. V>>Это ответ. Курить что есть функциональынй объект. K>И это — не ответ.
Это пара { ф-ия, контекст }.
По последней ссылке более подробно.
K>>>Опять же — неверная посылка. "Генерируемая программой польза" — это не "побочный эффект", а эффект самый что ни на есть "прямой" — результат. V>>Отлично, стоило тебе попытаться обосновать хоть одно своё "неверно" и ты сразу сел в лужу. Видишь ли... Наблюдать результат работы программы можно только через побочные эффекты. Без побочных эффектов ты даже не будешь знать, работает программа или нет.
K>Наблюдать результат работы программы можно 1) непосредственно, не наблюдая никаких "эффектов".
Это не ответ. (С)
K>2) Наблюдая эффекты, но с какой стати они должны быть "побочными"? Эффект побочный, когда он не отражен в сигнатуре функции — но в чистых ФЯ так не бывает — все эффекты отражены в сигнатуре — побочных нет.
По определению побочных эффектов, ввод-вывод — это тоже побочный эффект. Поэтому, программа без побочных эффектов — это фантом, а не программа.
V>>Если я могу без всяких бэкдоров в абсолютно чистом ФП-коде проэмулировать специально все случайные побочные эффекты, бывающие в императиве... то кто помешает произойти этому же в достаточно сложной программе случайно? K>Никаких побочных эффектов вы без бекдоров не "проэмулируете". Все эффекты в чистом ФЯ прямые и явные — "побочных" без "бэкдоров" не бывает.
Ясно. Пример с эмуляцией косвенной адресации ср-вами ФП и протягивание состояний "мира" ты пока не понял. Ну ОК, подожду...
Здравствуйте, grosborn, Вы писали:
G>Лень тут совершенно не при чем. J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.
с каких пор паскаль стал стековой машиной?
(внимательно читаем определение)
G>J или C# это не стековая машина
курим msil до полного просветления.
Всё сказанное выше — личное мнение, если не указано обратное.
> G>Лень тут совершенно не при чем. J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации. > > с каких пор паскаль стал стековой машиной? > (внимательно читаем определение)
Опаньки. Еще один вики-адепт. То есть для тебя то что в вики еще не упомянуто, того не существует? И скоро собачку нельзя назвать жучкой, патамучта "читаем определение". Вы уже достали со своей вики, совершенно неспособны думать головой. Вообще уже маразм.
> G>J или C# это не стековая машина > > курим msil до полного просветления.
Кури, я подожду.
И обрати внимание, vdimas понял. Он-то как раз курил паскаль и msil и просветлен. А вы с синклером чего-то недокурили.
Здравствуйте, Ikemefula, Вы писали:
I>То есть, ты только что удесятерил минимально необходимое количество кода.
Ты так и не показал удесятирение. А разговаривать ярлыками со мной бесполезно.
I>А это именно то о чем я говорил — ручное связывание.
Не вседа это связывание (пытаюсь опять обратить на этот ВАЖНЫЙ аспект твоё внимание). Зачастую выгодней или надежней создать копию значения для замыкания. Но тебе как об стенку горох. Да, в процедурном программировании способ передачи данных в процедуры — это часть дизацна и часть работы программиста.
Т.е. да, я ручками тебе показал то, что в лямбдах происходит автоматом. Я именно это и обещал показать.
I>Ты бил себя пяткой в грудь что это не надо.
Фантазии. Ветка на месте, можно освежить, коль забыл. Я изначально утверждал, что тонкости ФП они обычно не на уровне дизайна, а на уровне внутренних подробностей. Имнно потому ФП неплохо смотрится в методах ООП, что он неплохо выглядит в кач-ве помощника по оформлению кода вокруг вычислительных подробностей.
I>Пойми простую вещь, если язык умеет локальные функции — это ФП и тогда не ясно нахрен вообще все твои пример, ибо это ФП против ФП. А если не умеет, то работы в десять раз больше чем ты показал.
Прочитав это предложение я уже малость сомневаюсь, что же ты имел ввиду под "локальными ф-ями"? Я имел ввиду обычные ф-ии, которые имеют некую ограниченную область видимости, чтобы не засорять ими глобальную видимость из всего проекта.
