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

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

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

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

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

S>>>Ты забыл сказать "пожалуйста". Но, я, пожалуй, отвечу таки. Из определения TAPL следует необходимость анализа поведения, будет ли оно разным для разных типов. По Strachey 67 становится ясно что нужно анализировать, будет ли выполняться различный код для каждого типа.

_>>Тогда 3 уточняющих вопрос:
_>>1. Т.е. у тебя нет разделения на полиморфизм на уровне исходного и машинного кода и ты всегда выводишь для функции объединение обоих критериев (я предпочитаю рассмотреть отдельно на каждом уровне и озвучивать для каждой функции два отдельных результата)?
S>Нет, такого разделения я не делаю. И не знаю никого, кроме тебя и vdimas-а, кто бы так делал. И объединение обоих критериев я тоже не использую. Я смотрю на поведение.
_>>2. Т.е. под фразой "будет ли выполняться различный код для каждого типа" ты подразумеваешь сравнение машинного кода функции, генерируемого для каждого типа или же что-то другое?
S>Зачем сравнение машинного кода? Достаточно знать, будет ли вызван специфический для типа код. Догадаться об этом можно по execution model или даже по весьма приблизительным представлениям о ней.
_>>3. Если в пункте 2, ты говорил про машинный код, то подразумеваешь только сравнение тела функции или же добавляешь к этому ещё и сравнение машинного кода всех других функций из стека вызова нашей?
S>Хорошо, если даже я не говорил в пункте 2 о машинном коде, то execution model может предполагать стек вызовов. И поэтому можно поговорить и о стеке. Тут я предлагаю на минуту отвлечься от критериев полиморфизма и рассмотреть некое свойство функции g, например, может ли случиться исключение при выполнении g, или обращается ли g к функции h? Если g - обычная функция (не ФВП), то ответ для нее получить довольно просто. Достаточно рассмотреть все ветвления при исполнении. Если мы там обнаружим вызов h или нечто, что может возбудить исключение, станет очевиден ответ на вопрос для функции g. Если g есть ФВП, то поиск ответа становится менее очевиден. Для ответа не достаточно найти функцию f, что g(f) укажет на выполнение h или возбуждение исключения. Хорошо бы еще либо найти такую p, что g(p) не даст такого ответа, либо убедиться что такой функции не существует.

S>Так вот, если мы нашли такую f, что g(f) возбуждает исключение и p что g(p) не возбуждает, то это как бы намекает на то, что сама g не обладает проверяемым свойством, что оно наведенное переданным параметром.

S>Есть надежда что по вышеописанному у тебя схожая позиция.

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

S>>>>>http://rsdn.org/forum/flame.comp/6676499.1
S>>>>>http://rsdn.org/forum/flame.comp/6677933.1
_>>>>В данные цитатах нет ни одного слова про подобное. Или у тебя своё особое понимание и английского языка?
S>>>Особое от твоего - точно. Я вот в этих определениях не увидел ничего про "тело функции". А ты - увидел.

_>>Ха, так я то как раз не пытаюсь прятаться за чужие цитаты, а говорю именно свою точку зрения. Но при этом она неплохо совместима с этими известными цитатами. А вот ты наоборот пытаешься сделать вид, что высказываемый тобой бред является прямым следствием из этих цитат, хотя в них нет ничего даже отдалённо похожего.
S>Интересно, на что по-твоему похожа фраза "function may execute different code for each type of argument"? Опиши, пожалуйста, своими словами, не отрываясь от своей теории полиморфизма в тексте. Приведи примеры функций, которые обладают и не обладают данным свойством.

_>>>>И? ) Тебе что-то не нравится? )
S>>>То, что различный код для equal_to выполняется, но ты уперся "в тело".

_>>На низком уровне различный код исполняется всегда (хотя бы потому что ЦПУ у нас по сути ad hoc). И соответственно если следовать твоей логике, то само понятие параметрического полиморфизма теряет смысл для подавляющей части реального кода.
S>Да, вспомнил как ты трактуешь "всегда" и "абсолютно никогда". А тут еще и "смысл", "подавляющей", "части" и "реального". Улыбнуло. Ну и что, зато для "остальной" части реального кода понятие смысл не теряет.

S>>>Ничего не получается такого с ФВП. apply параметрически полиморфна.

_>>Это согласно моей точки зрения. И так же согласно твоим отдельным заявлениям. А теперь (когда ты конкретизируешь те 3 пункта в начале сообщения) мы посмотрим получается ли тоже самое из твоего определения критериев. И соответственно если не получится, то будем в очередной раз громко смеяться.
S>Да пожалуйста.

_>>>>Ну и насчёт чистоты... Если уж ты заикнулся про это, то должен знать, что в том же Хаскеле есть известные механизмы для изоляции "грязного кода", так что в определённых случаях он вполне может располагаться внутри чистой функции. Как раз очень хорошая аналогия наблюдается... )))
S>>>Аналогия чему? Ты хочешь сказать что map стала перманентно грязной от того что ты в нее смог однажды подсунуть изолированную грязную функцию?

_>>Ты снова путаешь свои взгляды и мои?) В моих как раз на поведение apply ничего не влияет. )
S>В моих - поведение apply не влияет на поведение той функции, что ей передают. А apply - вообще никаким своим поведением, отличающим ее от поведения того, что ей передали, не обладает.

_>>А по поводу аналогии очевидно же. Возьмём мой пример my_equal_to на C++. Он использует некий тип eq, который как раз и осуществляет изоляцию ad hoc кода в себе, так что вызов его оператора равенства из my_equal_to получается параметрически полиморфным (такой оператор опять же ровно один для всех типов, и в исходных кодах и в машинных).
S>Только лишь с оговоркой что my_equal_to вызываает различный код при различных типах и, в соответствии с вызываемым кодом, меняет и свое поведение от типа к типу.

S>>>Один раз ты сравнил поведения двух различных функций, у которых различная реализация на уровне машинных кодов. При этом сказал что поведение будет "как у", т.е. одинаковое. Я полагаю, ты интуитивно использовал procedural abstraction.

_>>Непонятно зачем ты постоянно приплетаешь данный термин из области методологии разработки ПО. У нас же вроде как чисто техническая дискуссия.
S>Разве? Когда ты смотришь чисто на исходный код - где тут техническая дискуссия?

_>>Да, и кстати, ещё непонятно зачем ты его пишешь по английский, хотя это полная древность, имеющая очевидную запись на русском языке.
S>Твой вопрос имеет отношение к "технической" дискуссии?

S>>>В этом же сообщении ты в отношении другой (других функций) my_equal_to заявил что их поведение абсолютно одинаковое, но при этом перешел от поведения функций к поведению исполнителя при очевидно разном поведении функций на уровне procedural abstraction для разных типов.

_>>Ээээ что? ) У меня такое впечатление, что ты хочешь сказать, что слово "поведение" является каким-то программистским термином, а не просто общеупотребимым словом с очевидным значением. Если ты реально так считаешь, то я буду рад, если ты и меня просветишь в этом вопросе (естественно со ссылками на определение данного "термина"). А то мало ли, вдруг я действительно не в курсе и такой интересный термин реально существует... :)))
S>Термин-то обычный бытовой. Но имеет значение, чего именно поведение ты рассматриваешь. Говоря о поведении функции, имеет смысл рассматривать поведение именно функции, а не переходить к подробностям ее реализации на определенной платформе определенной версии компилятора с определенными опциями.

S>>>[q]
S>>>>твоя my_equal_to абсолютно и полностью укладывается.
S>>>Не укладывается, т.к. поведение абсолютно одинаковое: вызов оператора равенства для соответствующего типа. )
S>>>[/q]
S>>>То есть у тебя слово "поведение" вызывает некий диссонанс, что может объяснять проблемы понимания определений, использующих слово "поведение".
S>>>И если в определениях использовать твой первый вариант (процедурной абтракции), то как раз и выйдет, что функция my_equal_to ведет себя по разному для разных типов, а значит вписывается в ad-hoc.
S>>>Но ты почему-то уперся и используешь второе понятие - поведение исполнителя (через вызов оператора).

_>>С трудом понял о чём ты говоришь, настолько странно ты используешь (а точнее чаще вообще не используешь) терминологию нашей отрасли. По сути ты здесь хочешь предложить включать во внешний контракт функции my_equal_to не только тот факт, что она производит сравнение полиморфных типов, но и то, что она это делает обязательно с помощью вызовов операторов равенства соответствующих типов. Но это на самом деле не верно. Потому как в реальности происходит вызов не этих операторов, а оператора равенства типа eq (что легко проверить чуть поменяв этот тип так, чтобы он перестал захватывать и использовать пользовательские операторы). Вот данный факт (про использования оператора равенства eq) вполне возможно стоит рассматривать как часть внешнего контракта my_equal_to. Однако он явно не будет свидетельствовать об ad hoc природе my_equal_to.
S>Возвращаясь к поведению my_equal_to - оно разное в зависимости от разных типов. Я говорю здесь о поведении функции, о свойствах отображения, если переводить на язык математической абстракции. А не о том, что она вызовет и вообще вызывает ли.

_>>Да, ну и напоследок. Если так случилось, что контракт функции по сути оказался полным описанием её внутреннее реализации, то это всего лишь свидетельствует о крайней простоте (ну обёртка и есть обёртка) этой функции. А не об использование деталей реализации в описание контракта.
S>Вот смотри (цитата с http://www.cplusplus.com/reference/string/char_traits/eq/)
S>[q]
S>Returns whether characters c and d are considered equal.

S>In the standard specializations of char_traits,[b] this function behaves as the built-in operator==[/b], but custom character traits classes may provide an alternative behavior.
S>[/q]
S>Перевести тебе выделенное? Здесь пишут что "эта функция ведет себя как встроенный оператор ==". Они пишут не о том, как ведет себя реализация функции (что она там вызывает). Они пишут о схожем поведении с чем-то еще. Если бы они сказали что eq что-то вызывает, а не ведет себя подобнымм образом, пришлось бы скрывать то что она ведет себя подобным образом, ибо реализация == может уже третьего оператора не вызывать. Итого, факт вызова - это не касается поведения функции. Это за гранью procedural abstraction.

S>То есть ты со своим вниманием к мелкой оптимизации просто выпал из терминов, на котором описаны функции в cplusplus.com. Или там кто-то поработал из секты свидетельства ad-hoc полиморфизма. Потому, тебе придется и их вычеркнуть из списка доверенных источников, если уже не выкинул, как хаскельвики.

S>>>Хотя, заметь! Сам ты используешь оба смысла слова "поведение", причем, даже в одном посте, и наверняка с разницей не более пары минут.

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

Теги:

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

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