Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата D_KEY @ 16.11.11, 13:49

Тогда зачем мы делали эту специализацию ?

местоимение "мы" там используется образно. это может быть кто угодно.

Добавлено 16.11.11, 14:21

Цитата D_KEY @ 16.11.11, 13:49

my_map fn x:<какое-то конкретное значение>   = []
my_map fn other = map fn other

какой еще my_map? я сказал сломай map

Цитата korvin @ 16.11.11, 14:18

это же могло произойти и неявно

Цитата D_KEY @ 16.11.11, 14:19

Как?

подключили хидер, который подключил другой хидер, который ... подключил хидер со специализированным Map.
не, я согласен, что ситуация не частая, но вполне возможная.

Цитата korvin @ 16.11.11, 14:20

Цитата D_KEY @ 16.11.11, 13:49

Тогда зачем мы делали эту специализацию ?

местоимение "мы" там используется образно. это может быть кто угодно.

Не понимаю, как это возможно.

Цитата

Цитата D_KEY @ 16.11.11, 13:49

my_map fn x:<какое-то конкретное значение>   = []
my_map fn other = map fn other

какой еще my_map? я сказал сломай map

Я привел пример аналогичной поломки.
Если специализацию написал ты сам - то и ССЗБ.
Если ее написал автор библиотеки, где описан Map - значит так и задумывалось.
Если ее написал автор какой-то другой библиотеки, которая использует Map - значит он хотел, чтобы Map работал именно так для списков, в которых содержится данный тип.
Пока все логично.
Еще варианты?

Цитата D_KEY @ 16.11.11, 13:49

В зависимости от контекста такого сравнения. В обсуждаемом случае - различия не важны.

ну когда сломаешь хаскелловый map вышеуказанным (или схожим) образом, тогда да, я соглашусь, что различия не важны и твой Map является аналогом хаскеллового map

Цитата korvin @ 16.11.11, 14:23

подключил хидер со специализированным Map.

Значит это было нужно.

Цитата

не, я согласен, что ситуация не частая, но вполне возможная.

В специализации нет ничего страшного. При отладки шаблонного кода есть масса других проблем

Цитата D_KEY @ 16.11.11, 14:24

Я привел пример аналогичной поломки.

нет, не привел. я сломал тот же самый Map, а ты взял и написал какой-то свой my_map, который на оригинальный map никак не влияет.

Добавлено 16.11.11, 14:27

Цитата D_KEY @ 16.11.11, 14:24

Если специализацию написал ты сам - то и ССЗБ.
Если ее написал автор библиотеки, где описан Map - значит так и задумывалось.
Если ее написал автор какой-то другой библиотеки, которая использует Map - значит он хотел, чтобы Map работал именно так для списков, в которых содержится данный тип.
Пока все логично.

ну так и не утверждай тогда, что твой Map аналогичен моему map, у них разная семантика

Цитата korvin @ 16.11.11, 14:24

Цитата D_KEY @ 16.11.11, 13:49

В зависимости от контекста такого сравнения. В обсуждаемом случае - различия не важны.

ну когда сломаешь хаскелловый map вышеуказанным (или схожим) образом, тогда да, я соглашусь, что различия не важны и твой Map является аналогом хаскеллового map

Если хаскеллевский map более ограничен в возможностях(не позволяет кастомизировать работу в зависимости от значений списка), это не значит, что Map для списков типов не может рассматриваться в нашем контексте.
Ты и так отвлекся от обсуждения Тебе понятны опциональные возможности, классы-политики, классы-характеристики, и вообще шаблоны как генераторы типов?

Добавлено 16.11.11, 14:29

Цитата korvin @ 16.11.11, 14:26

Цитата D_KEY @ 16.11.11, 14:24

Если специализацию написал ты сам - то и ССЗБ.
Если ее написал автор библиотеки, где описан Map - значит так и задумывалось.
Если ее написал автор какой-то другой библиотеки, которая использует Map - значит он хотел, чтобы Map работал именно так для списков, в которых содержится данный тип.
Пока все логично.

ну так и не утверждай тогда, что твой Map аналогичен моему map, у них разная семантика

Нет, у них просто разная степень кастомизации.

Сообщение отредактировано: D_KEY - 16.11.11, 14:29

Цитата D_KEY @ 16.11.11, 14:28

Если хаскеллевский map более ограничен в возможностях(не позволяет кастомизировать работу в зависимости от значений списка), это не значит, что Map для списков типов не может рассматриваться в нашем контексте.

щито? у хаскеллового (да и вообще функционального) map строго определенное поведение, заданное автором по мат.определению. считай это, ну не знаю, инвариантом(?), это дает гарантии однозначности его поведения независимо от параметров.

и о какой кастомизации идет речь, если map работает с одним конкретным типо -- список, пусть даже это список типов, т.е. твой Map фактически является даже не обобщенным

Map :: (a -> b) -> [a] -> [b]

а конкретным

Map :: (Type -> Type) -> [Type] -> [Type]

с возможностью доопределить образцы например таким:

Map fn (SomeType : _) = []

что приведет вызов

Map (\t -> Vector t) [Int, Double, SomeType, String, Bool]

к результату

[Vector Int, Vector Double]

Добавлено 16.11.11, 14:45

Цитата D_KEY @ 16.11.11, 14:28

Нет, у них просто разная степень кастомизации.

нет, это разная семантика

Сообщение отредактировано: korvin - 16.11.11, 14:47

Цитата korvin @ 16.11.11, 14:44

Цитата D_KEY @ 16.11.11, 14:28

Если хаскеллевский map более ограничен в возможностях(не позволяет кастомизировать работу в зависимости от значений списка), это не значит, что Map для списков типов не может рассматриваться в нашем контексте.

щито? у хаскеллового (да и вообще функционального) map строго определенное поведение, заданное автором по мат.определению. считай это, ну не знаю, инвариантом(?), это дает гарантии однозначности его поведения независимо от параметров.

Это не противоречит тому, что ты процитировал.

Цитата

и о какой кастомизации идет речь

О специализации поведения для списка содержащего наш тип.

Цитата

твой Map фактически является даже не обобщенным

Ты это только сейчас понял?

Цитата

Цитата D_KEY @ 16.11.11, 14:28

Нет, у них просто разная степень кастомизации.

нет, это разная семантика

Если ты не будешь кастомизировать, то будет та же семантика. Согласен?
Значит, разница в степени кастомизации

Добавлено 16.11.11, 14:52
korvin

Цитата D_KEY @ 16.11.11, 14:28

Ты и так отвлекся от обсуждения Тебе понятны опциональные возможности, классы-политики, классы-характеристики, и вообще шаблоны как генераторы типов?

Цитата D_KEY @ 16.11.11, 14:51

Если ты не будешь кастомизировать, то будет та же семантика. Согласен?
Значит, разница в степени кастомизации

нет, семантика уже другая. изначально. сама возможность этой сомнительной "кастомизации" -- уже есть другая семантика

Добавлено 16.11.11, 14:57
нет, мне определенно нравится, когда С++-ники называют возможность сломать абстракцию(из-за невозможности эту абстракцию полноценно реализовать видимо?) "возможностью кастомизации", "фичей"... =)

Сообщение отредактировано: korvin - 16.11.11, 14:57

Цитата korvin @ 16.11.11, 14:54

нет, семантика уже другая. изначально.

Цитата

сама возможность этой сомнительной "кастомизации" -- уже есть другая семантика

Почему? А если у нас такая "структура данных", что мы каким-то образом можем узнать длину хвоста у элемента(например, у нас какой-то кэш), то почему бы это не сделать, вместо того, чтобы бегать по списку? Да мало ли что может понадобится...

Цитата

нет, мне определенно нравится, когда С++-ники называют возможность сломать абстракцию(из-за невозможности эту абстракцию полноценно реализовать видимо?) "возможностью кастомизации", "фичей"... =)

Трололо
Ты пока не показал ни одного недостатка шаблонов.
И собираешься ли ты отвечать на мой вопрос, который я задаю тебе уже несколько раз?

Цитата D_KEY @ 16.11.11, 15:03

Почему? А если у нас такая "структура данных", что мы каким-то образом можем узнать длину хвоста у элемента(например, у нас какой-то кэш), то почему бы это не сделать, вместо того, чтобы бегать по списку? Да мало ли что может понадобится...

как это вообще относится к map? o_O'

ну а для произвольных типов у нас есть отличный

class Functor f where
    fmap :: (a -> b) -> f a -> f b

который соответственно для списков определен как

instance Functor [] where
    fmap = map

Добавлено 16.11.11, 15:17

Цитата D_KEY @ 16.11.11, 15:03

Ты пока не показал ни одного недостатка шаблонов.

вы просто не хотите видеть.

Добавлено 16.11.11, 15:19

Цитата D_KEY @ 16.11.11, 15:03

И собираешься ли ты отвечать на мой вопрос, который я задаю тебе уже несколько раз?

который? ни на 348-й, ни на 347-й странице от тебя вопросов, на которые я не ответил, нет

Сообщение отредактировано: korvin - 16.11.11, 15:20

Цитата korvin @ 16.11.11, 15:16

вы просто не хотите видеть.

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

Цитата

Цитата D_KEY @ 16.11.11, 15:03

И собираешься ли ты отвечать на мой вопрос, который я задаю тебе уже несколько раз?

который? ни на 348-й, ни на 347-й странице от тебя вопросов, на которые я не ответил, нет

Вот же:

Цитата

Ты и так отвлекся от обсуждения Тебе понятны опциональные возможности, классы-политики, классы-характеристики, и вообще шаблоны как генераторы типов?

Добавлено 16.11.11, 15:27

Цитата korvin @ 16.11.11, 15:16

как это вообще относится к map? o_O'

Сорри, я о другом думал

Цитата D_KEY @ 16.11.11, 15:27

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

я поменял тему? я привел пример, того, что требование дженериками реализовывать все свои методы не связано с динамикой, о чем шло рассуждение изначально. затем Вы же вспомнили опять про паттерн-матчинг. зачем? назвали бы уж перегрузкой, было бы логичней

Добавлено 16.11.11, 15:37

Цитата D_KEY @ 16.11.11, 15:27

Вот же:

Цитата

Ты и так отвлекся от обсуждения Тебе понятны опциональные возможности, классы-политики, классы-характеристики, и вообще шаблоны как генераторы типов?

это-то мне более-менее понятно, непонятно только при чем тут шаблоны, если это можно сделать и без них? впрочем ладно, все опять скатывается к Compile time vs Run time, а хаскелл тут оффтоп.