S>У тебя другие слова обозначают совсем не то же самое, что A is B. Т.к. A is B это бинарное отношение.
мне кажется, что ты запутался в абстракциях.
вот есть множество типов Ts: (IEnumerable<T>, ICollection<T>, T[] и т.д.), поверх него определено бинарное отношение is, которое можно задать в табличном виде
IEnumerable<T> is IEnumerable<T> = true
ICollection<T> is IEnumerable<T> = true
T[] is IEnumerable<T> = true
IEnumerable<T> is ICollection<T> = false
ICollection<T> is ICollection<T> = true
T[] is ICollection<T> = true
IEnumerable<T> is T[] = false
ICollection<T> is T[] = false
T[] is T[] = true
это множество типов Ts и бинарное отношение is образует категорию C, где в качестве объектов берутся элементы множества Ts, а в качестве стрелок берутся true-шные строки из данной таблицы, что можно задать следующей таблицей:
S>Твое деление отличается от общепринятого, ты и доказывай его полезность. А я тебе растолковываю то что написано в википедии.
полезность я уже показывал ранее.
что на уровне описания кода можно обойтись одним parametric polymorphism-ом + код уровня компиляции, а всё остальное может сгенерить компилятор.
это упрощает жизнь программиста, не теряя при этом общности и эффективности при исполнении.
Здравствуйте, DarkGray, Вы писали:
S>>У тебя другие слова обозначают совсем не то же самое, что A is B. Т.к. A is B это бинарное отношение.
DG>мне кажется, что ты запутался в абстракциях.
DG>это множество типов Ts и бинарное отношение is образует категорию C, где в качестве объектов берутся элементы множества Ts, а в качестве стрелок берутся true-шные строки из данной таблицы, что можно задать следующей таблицей:
DG>соответственно, каждая строка является отдельным морфизмом(и объекты a и b сответственно уникальны) — о чем и шла речь ранее.
Я уже понял о чем речь, но протестую против того что бы is называть стрелкой. Строки таблицы называть стрелками — это допустимо.
S>>Твое деление отличается от общепринятого, ты и доказывай его полезность. А я тебе растолковываю то что написано в википедии.
DG>полезность я уже показывал ранее. DG>что на уровне описания кода можно обойтись одним parametric polymorphism-ом + код уровня компиляции, а всё остальное может сгенерить компилятор.
Ты показал что на уровне языка ты используешь ad-hoc полиморфизм и называешь его параметрическим.
DG>это упрощает жизнь программиста, не теряя при этом общности и эффективности при исполнении.
Твоя конструкция понятна и что-то подобное вовсю используется в C++ (если считать что if(is_collection<T>()) выкинется компилятором при специализации в { return false;}).
Беда в том, что ты перепутывашь терминологию и выдаешь это за какую-то пользу и упрощение жизни программиста. Специализация кода под типы всегда будет специализацией, будь то специализация шаблона или compile-if.
Перепутаешь ты что-то или нет, жизнь программистов от этого глобально не изменится. Но нафига путаница И твой пример необходимость этой путаницы не объясняет.
Здравствуйте, DarkGray, Вы писали:
DG>необходимо было сказать: DG>есть множество типов, они связаны набором стрелок, которые продуцируются true-подмножеством операции is.
DG>так?
точно
S>Беда в том, что ты перепутывашь терминологию и выдаешь это за какую-то пользу и упрощение жизни программиста. Специализация кода под типы всегда будет специализацией, будь то специализация шаблона или compile-if.
а числа делящиеся на 7 всегда будут числами делящимися на 7. и что из этого?
Здравствуйте, DarkGray, Вы писали:
S>>Беда в том, что ты перепутывашь терминологию и выдаешь это за какую-то пользу и упрощение жизни программиста. Специализация кода под типы всегда будет специализацией, будь то специализация шаблона или compile-if.
DG>а числа делящиеся на 7 всегда будут числами делящимися на 7. и что из этого?
Ничего, если не делать утверждения что числа, делящиеся на 7 есть частный случай чисел, делящихся на 3.
если не понятен пример с делением на 7, то можно взять понятие "указатель": и утверждение, что указатель всегда остается указателем.
вот только в современных языках — никто понятие "указатель" уже не использует, а используется лишь одно общее понятие ссылка. а с поинтерами разбираются только теоретики, и компиляторы где-то у себя внутри.
Здравствуйте, DarkGray, Вы писали:
DG>если не понятен пример с делением на 7, то можно взять понятие "указатель": и утверждение, что указатель всегда остается указателем.
DG>вот только в современных языках — никто понятие "указатель" уже не использует, а используется лишь одно общее понятие ссылка. а с поинтерами разбираются только теоретики, и компиляторы где-то у себя внутри.
Ты всплыл в этой теме с каким-то нелепым утверждением, которое подтверждаешь примером, который говорит о том что ты совершенно по-другому трактуешь категории полиморфизма, основываясь на кодогенерации и машинном коде.
Я попытался навести порядок.
В ответ получаю, что это все нормально, т.к. понятие "указатель" уже не используют.
Не используют и не используют. Зачем надо было влезать и использовать не так как все?
Уж лучше пойду посплю.
S> Зачем надо было влезать и использовать не так как все?
психология утверждает, что человеческое мышление часто ограничивается теми символами с помощью которых происходит общение.
соответственно, если человеку сказать, что вот были введены (условно) три различных полиморфизма: parametric, subtype и ad-hoc, то большинство будет мыслить, исходя из того, что эти полиморфизмы и в действительности являются различными, хотя это и не так.
в частности, человек перестает рассматривать варианты, когда одно и тоже можно представить с помощью разных полиморфизмов — ранее же сказали, что они различны, а значит такое представление невозможно.
Здравствуйте, DarkGray, Вы писали:
S>> Зачем надо было влезать и использовать не так как все?
DG>психология утверждает, что человеческое мышление часто ограничивается теми символами с помощью которых происходит общение. DG>соответственно, если человеку сказать, что вот были введены (условно) три различных полиморфизма: parametric, subtype и ad-hoc, то большинство будет мыслить, исходя из того, что эти полиморфизмы и в действительности являются различными, хотя это и не так.
Они действительно являются различными в том плане что обладают разными свойствами, что и описано в определениях.
DG>в частности, человек перестает рассматривать варианты, когда одно и тоже можно представить с помощью разных полиморфизмов — ранее же сказали, что они различны, а значит такое представление невозможно.
Предложением выше ты сказал что полиморфизмы в действительности не различаются, а в этом они у тебя снова разные.
Здравствуйте, DarkGray, Вы писали:
DM>>Так речь же по идее должна идти об исходном коде, а не о том, что генерит компилятор. Он может хоть манную кашу генерить, на язык и систему типов это не влияет.
DG>что такое исходный код? и чем он отличается от не исходного?
Есть некий язык, назовем его А. Есть его спецификация, определение, включающая в себя описание грамматики и семантики. Есть в нем система типов. Все эти вещи описаны людьми для людей, компилятора для языка может и вообще не существовать. Так вот, текст на этом языке (принадлежащий этому языку грамматически как минимум) — исходный код. А то, что производит некоторая программа (пусть и называемая компилятором), если оно не принадлежит описанному языку А, — не исходный код (на этом языке).
DG>вот это исходный код? он один или его много? ...
Если язык этого куска текста нигде не описан, то это не исходный код, это просто набор букв.
DM>> на язык и систему типов это не влияет.
DG>на какой язык? уровня компиляции? байт кода? маш кода? процессора?
Язык, данный нам спецификацией. Например, С++, Haskell, Shakespeare, Intercal... Байткод, машкод и пр. принадлежат уже совсем другим языкам. У этих языков могут быть совсем другие системы типов. Поэтому они в общем случае не влияют на систему типов языка, который в них компилируется.
Здравствуйте, Eye of Hell, Вы писали:
EOH>Увы, программирование — достаточно молодая область, и хорошей, выверенной веками классификации у нас пока нема. Работаем с тем что есть (c).
У меня подозрение, что дело не только в молодости. Фактически каждый программист интенсивно манипулирует разного рода абстракциями, понятиями и концепциями в своей практике так что время между созданием нового понятия, воплощением и выбрасыванием за ненадобностью в программировании самое короткое среди остальных областей интеллектуальной деятельности. В таком прессинге выживают только самые общие математические концепции.
EOH>Мне кажется, что вы упускаете один важный нюанс. Программист не сразу идет бороть наследование в C++. Вначале у него стоит задача — есть какой-то код и есть разные объекты, один код должен оперировать этими объектами. Зная, что это задача для полиморфизма и что этого полиморфизма есть много разного, программист пырится на ассортимент и выбирает что ему лучше использовать в данном конкретном случае: перегрузку метода, или общий интерфейс для объектов сделать, или наследовать их от общего предка, или реализовать алгорим шаблоном. На мой взгляд, именно это понимаение "нафига полиморфизм нужен вообще" позволяет адекватно выбрать способ решения текущей задачи.
Естественно без знания технических примочек никуда по поедешь, а без теории никуда не доедешь. Но не стоит переоценивать роль математики. Люблю цитировать Непейводу: Хаотическое управление
• Теория неформализуемых понятий
– Каждое действительно сложное и важное понятие активно сопротивляется формализации, порождая новую альтернативу, не учтенную ею
– Тем не менее эффективная деятельность возможна лишь на базе формализации понятий
– Необходимо четко понимать. что мы в огромном числе случаев формализуем неформализуемое.
– Любая формализация заводит в тупик, и тем быстрее и основательнее, чем более эффективна она на первых порах.
– Тупик образуется еще тогда, когда отказаться от формализации нет сил.
– Тупик становится намного труднее для выхода и основательнее, если с самого начала не позаботиться о том, чтобы осознать альтернативы существующей успешной формализации.
– Тупика можно избежать, если одновременно поддерживаются несколько несовместимых альтернатив.
EOH>Баланс между чистой теорией определений и практикой реализаций тех или иных костылей в конкретных языках программирования — наше усе. Я за баланс — чтобы и теория была — общее так сказать понимание, и практика — где какие таблицы виртуальных функций используются и как виртуальная машина пеготает.
Всетаки кроме практики и теории есть еще третий уровень как мне кажется. Я уже указывал на открытие многих приемов мышления которые пока ни в математике ни в программировании не получили отражения. Считаю что программист не думает в терминах объектов, программист просто думает об объектах и не более того. Объекты надо проектировать как и полиморфизм как и любые другие принципы ООП. Все они проектируются программистом, но не составляют суть и способ рассуждений программита и не имеют отношения к его способу мышления. Объекты, полиморфизм и все остальное это конечный итог рассуждений в процессе которых происходит проектирование с учетом многих тонкостей и нюансов. Программист не реализует в своей программе "полиморфизм вообще", он реализует вполне конкретный вид полиморфизма при условии что компилятор его поддерживает и это не конфликтует с остальными принимаемыми программистом решениями. Потому полиморфизм для программист это не более чем проектное решение, а значит полиморфизм в Дельфи нужно отличать от полиморфзма в C# даже если речь идет только про перегрузку функций.
Здравствуйте, samius, Вы писали:
S>Я вообще не понял, откуда взялось предложение считать Ad-hoc разновидностью Subtype-а. Вроде как это твои фантазии. S>Странно, что ты это обсуждаешь сам с собой, цитируя при этом Eye of Hell-а.
Да я такой
Но он отвечает как будто такое говорил — значит виновен по всем статьям
Здравствуйте, Vaako, Вы писали:
V>Программист не реализует в своей программе "полиморфизм вообще", он реализует вполне конкретный вид полиморфизма при условии что компилятор его поддерживает и это не конфликтует с остальными принимаемыми программистом решениями.
Полиморфизм — фича языка. Потому обычному программисту, который не занимается разработкой языка, сталкиваться с реализацией полиморфизма не приходится. Программист лишь использует полиморфизм, комбинирует различные его категории.
V>Потому полиморфизм для программист это не более чем проектное решение, а значит полиморфизм в Дельфи нужно отличать от полиморфзма в C# даже если речь идет только про перегрузку функций.
И чем же полиморфизм Дельфи отличается от полиморфизма в C# в отношении перегрузки функций?
DM>Есть некий язык, назовем его А. Есть его спецификация, определение, включающая в себя описание грамматики и семантики. Есть в нем система типов. Все эти вещи описаны людьми для людей, компилятора для языка может и вообще не существовать. Так вот, текст на этом языке (принадлежащий этому языку грамматически как минимум) — исходный код. А то, что производит некоторая программа (пусть и называемая компилятором), если оно не принадлежит описанному языку А, — не исходный код (на этом языке).
возьмем, твое же определение и препроцессор языка C++, и некий код C1
код C1 после обработки препроцессором превращается в код C2.
и код C1, и код C2 — являются кодом на языке C++.
из твоего же определения, выходит, что и C1 исходный код, и C2 — это тоже исходный код.
тоже самое можно сделать (и делается) с шаблонами, можно взять раскрыть шаблоны и получить код C3, который опять же будет записан на подмножестве языка C++.
в C# это еще более выражено, из-за того, что в нем много синтаксического сахара.
например, в нем явно расскрываются yield, foreach, using, extension-ы и т.д.
в итоге, это образует матрешку: С++ > C++(без инклюдов) > C++ (без макросов) > C++ (без макросов и без шаблонов) > С++ (без макросов и без шаблонов, без невиртуальных классов) и т.д.
при этом редуцируются как языковые конструкции, так и типы.
на определенном этапе, произойдет упор: например, из C++ нельзя выкинуть понятие виртуального объекта и vtable-а.
можно выкинуть конструкции, которые облегчают формирование vtable, но нельзя выкинуть само понятие vtable.
вот это означает, что мы натолкнулись на понятие уровня runtime-а для C++.
ps
рассматриваются только переходы, которые не ухудшают вычислительную сложность самой программы.
DM>>> на язык и систему типов это не влияет.
DG>>на какой язык? уровня компиляции? байт кода? маш кода? процессора?
DM>Язык, данный нам спецификацией. Например, С++, Haskell, Shakespeare, Intercal... Байткод, машкод и пр. принадлежат уже совсем другим языкам. У этих языков могут быть совсем другие системы типов. Поэтому они в общем случае не влияют на систему типов языка, который в них компилируется.
это тоже теория, а на практике не бывает, чтобы, например, int или float сильно отличались от int и float-а процессора, если нас, конечно, интересует практика (и в частности, вычислительная эффективность)
и кстати ATS должен быть дать понимание, что часть типов это чисто фишка компилятора, а часть переходит и в runtime.
соответственно, каждый реальный язык имеет, как минимум, два набора типов: уровня компиляции и уровня runtime-а.
DM>Если язык этого куска текста нигде не описан, то это не исходный код, это просто набор букв.
корректнее это утверждение формулируется как:
язык является языком — если есть алгоритм исполнения или/и алгоритм трансляции в более простой набор примитивов.
рассказать как вот это можно отранслировать в c#?
TItem[] Concat<TCollection, T>(T[] items1, TCollection items2) where TCollection:IEnumerable<T>
{
var result = new List<T>();
compile-if (TCollection is ICollection<T>)
{
И твой пример необходимость этой путаницы не объясняет.
