Новое сообщение в форум Компьютерные священные войны

Форум	Компьютерные священные войны
Тема	Как правильно задавать вопросы

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

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

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

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

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

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

_>>The name "currying", coined by Christopher Strachey in 1967, is a reference to logician Haskell Curry. :))):))):)))
S>Рад, что ты это находишь смешным.

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

_>>Ну т.е. ты так и не можешь представить своё определение понятия "поведение функции"? Хотя при этом говоришь что все его понимают одинаковым образом (так каким же тогда?)...
S>А для чего мне представлять именно свое определение? Свое понимание (и не только мое) этого вопроса - я уже излагал. Указывал, где посмотреть на специфику для C++. Мало? Извини, определения поведения функции в аппаратных стеках у меня нема.

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

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

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

_>>И тут тебе сказать нечего. В общем всё понятно.
S>Понятно что ты спецификацию не откроешь и про поведение программы не прочитаешь.

_>>>>Ничего общего с твоим бредом тут нет. Операторов равенства для разных типов много - это и есть ad hoc. А оператор равенства для eq ровно один.
S>>>функция
S>>>myEq a b = a == b
S>>>тоже одна. И она ad-hoc.

_>>Глупости какие. Если убрать библиотечный сахар (реализуемый через МП) в C++ варианте и синтаксический сахар (посмотреть на внутреннюю реализацию классов типов) Хаскеля, то легко увидеть, что в обоих вариантах эти функции в реальности выглядят как-то так:
_>>[ccode]
_>>bool my_equal_to(void* a, void* b, bool (*f)(void*, void*))
_>>{
_>>	return f(a, b);
_>>}
_>>[/ccode]
_>>а значение f автоматически подставляется компилятором (по определению работы Хаскеля/по МП коду в конструкторе eq в варианте C++) в точках вызова my_equal_to в соответствие с передаваемыми там типами. Никакого принципиального отличия от обсуждаемой тут apply эти реализации не имеют. Но при этом они у тебя ad hoc полиморфные, а apply параметрически полиморфная.
S>Видишь, реализации! А в терминах поведения они существенно отличаются. apply ведет себя неотличимо от любой (здесь я использовал квантор всеобщности, если ты когда-нибудь с ними таки ознакомишься) функцции f. А my_equal_to ведет себя неотличимо от eq для каждого типа, для которого определен eq. А значит, специальнымм образом на ограниченном наборе. Но ты гляди в аппаратный стек, что бы не ошибиться. Оттуда, наверное, вообще все функции полиморфными кажутся

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail