Re[59]: «Собаку съел»
От: samius Япония http://sams-tricks.blogspot.com
Дата: 21.02.17 05:05
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, samius, Вы писали:


S>>Хы, пропустил я как-то момент, когда студенты начали изучать принципы устройства ЦПУ c реализации каррирования в GHC.


_>Ты похоже уже забыл, что я тебе уже писал. Для того, чтобы посмеяться над идеей каррирования в машинных кодах не надо ничего знать про какие-то реализации Хаскеля и т.п. Это смешно само по себе, если знать устройство современных процессоров (попробуй просто представить себе что потребуется сгенерировать компилятору и как будет выглядеть вызов всего этого скажем в случае функции 5-и переменных). И то, что ты по прежнему этого не понимаешь, прямо поражает. Ты вообще в курсе таких вещей как аппаратный стек, пролог и эпилог функции и т.п. базовые вещи, знакомые каждому студенту? )

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

S>>Да и похоже что сам Стрэчи, введя классификацию в 1967м году выглядел бы жалко и убого. Он, бедолага, и Хаскеля-то не видел. Как он вообще мог, не зная частной реализации каррирования в машинных кодах, вводить такие классификации!!!


_>The name "currying", coined by Christopher Strachey in 1967, is a reference to logician Haskell Curry.

Рад, что ты это находишь смешным.

S>>Тебе надо было листать не мое сообщение, а спецификацию C++. Я вроде бы недвусмысленно указал на это. Да ладно уж.


_>Ну т.е. ты так и не можешь представить своё определение понятия "поведение функции"? Хотя при этом говоришь что все его понимают одинаковым образом (так каким же тогда?)...

А для чего мне представлять именно свое определение? Свое понимание (и не только мое) этого вопроса — я уже излагал. Указывал, где посмотреть на специфику для C++. Мало? Извини, определения поведения функции в аппаратных стеках у меня нема.

_>>>В прошлом ты пытался выкрутиться из этого противоречия в своём мировоззрение с помощью утверждения, что "apply f" — это уже совсем другая функция с другими свойствами. Когда же ты открыл для себя, что в реальности используется всё та же apply, то начал придумывать новые отмазки, что мол для ФВП надо делать исключения и определять их по другому. Так что конкретно ты имеешь в виду под "своим мнением"? В этом потоке судорожных попыток как-то замять противоречивость никакой чёткой и однозначной позиции я так и не увидел.

S>>Мне жаль.

_>Ну т.е. и насчёт противоречия с apply тебе сказать нечего? ) Что-то ты совсем сдулся как оппонент. )

Я тебе уже сказал. Хочешь повторить — отмотай назад.

S>>Я уже перчислял, чему противоречат твои взгляды. Возможно, тебе стоило бы озадачитьься этим, а не искать противоречие в моих.


_>И тут тебе сказать нечего. В общем всё понятно.

Понятно что ты спецификацию не откроешь и про поведение программы не прочитаешь.

_>>>Ничего общего с твоим бредом тут нет. Операторов равенства для разных типов много — это и есть ad hoc. А оператор равенства для eq ровно один.

S>>функция
S>>myEq a b = a == b
S>>тоже одна. И она ad-hoc.

_>Глупости какие. Если убрать библиотечный сахар (реализуемый через МП) в C++ варианте и синтаксический сахар (посмотреть на внутреннюю реализацию классов типов) Хаскеля, то легко увидеть, что в обоих вариантах эти функции в реальности выглядят как-то так:

_>
_>bool my_equal_to(void* a, void* b, bool (*f)(void*, void*))
_>{
_>    return f(a, b);
_>}
_>

_>а значение f автоматически подставляется компилятором (по определению работы Хаскеля/по МП коду в конструкторе eq в варианте C++) в точках вызова my_equal_to в соответствие с передаваемыми там типами. Никакого принципиального отличия от обсуждаемой тут apply эти реализации не имеют. Но при этом они у тебя ad hoc полиморфные, а apply параметрически полиморфная.
Видишь, реализации! А в терминах поведения они существенно отличаются. apply ведет себя неотличимо от любой (здесь я использовал квантор всеобщности, если ты когда-нибудь с ними таки ознакомишься) функцции f. А my_equal_to ведет себя неотличимо от eq для каждого типа, для которого определен eq. А значит, специальнымм образом на ограниченном наборе. Но ты гляди в аппаратный стек, что бы не ошибиться. Оттуда, наверное, вообще все функции полиморфными кажутся
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.