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

S>>Не соглашусь. Методы Sum и Add2 не могут работать для любого типа без специального кода.

DG>так же можешь рассказать, почему std::vector не работает в следующих случаях:

DG>ps
DG>а не работает оно всё по той же причине, нема для этих типов необходимо для вектора функционала

Это решается без вмешательства в код вектора и в том числе без специализации.

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

S>>Хорошо, не будем считать вектор образцом параметрического полиморфизма. Но вместе с ним и List<T>, И Tuple<T> и т.п.

DG>поэтому я и утверждаю, что твоя трактовка параметрического полиморфизма мало используемая, и не несет никакой полезной информации для практического использования.

Это не моя трактовка. Это общая трактовка. Вот когда твоя трактовка продержится в википедии пару лет, тогда поговорим о твоей.

S>Это не моя трактовка. Это общая трактовка. Вот когда твоя трактовка продержится в википедии пару лет, тогда поговорим о твоей.

угу, миллион мух не может ошибаться.

S>Это решается без вмешательства в код вектора и в том числе без специализации.

приведи код.

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

S>>Это не моя трактовка. Это общая трактовка. Вот когда твоя трактовка продержится в википедии пару лет, тогда поговорим о твоей.

DG>угу, миллион мух не может ошибаться.
Миллион мух называет некоторое явление некоторым словом. Тут находится одна муха, которая говорит что все ошибаются и этим словом нужно называть другое явление.

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


S>>Это решается без вмешательства в код вектора и в том числе без специализации.

DG>приведи код.
Лень. Но в Z надо будет открыть оператор присваивания, а для F уж придется делать специализацию. Соглашусь, вектор не лучший пример параметрического полиморфизма. Давай возьмем список в хаскеле.

S>Но в Z надо будет открыть оператор присваивания

это невозможно, если Z задекларирован в чужой либе.


S> Давай возьмем список в хаскеле.

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

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

S>>Но в Z надо будет открыть оператор присваивания

DG>это невозможно, если Z задекларирован в чужой либе.

Что-то помешает подсунуть свой аллокатор?


S>> Давай возьмем список в хаскеле.

DG>хаскель плохой пример — в нем искусственно оставлены только те типы, которые поддерживают операцию копирования по ссылке. все неудобные типы из хаскеля вырезаны.

Наоборот, я считаю его хорошим примером параметрического полиморфизма.

DG>>угу, миллион мух не может ошибаться.
S>Миллион мух называет некоторое явление некоторым словом. Тут находится одна муха, которая говорит что все ошибаются и этим словом нужно называть другое явление.

так именно поэтому в науке принято ссылаться на критерии, принципы и т.д. при выяснении какой вариант предпочтесть, а не на авторитеты.
ты же как только тебе не хватает аргументов ссылаешься на авторитет википедии.

зы
я предлагаю использовать критерий: какое определение дает большую пользу на практике. дает большую пользу, то определение — правильное и годное, дает меньшее (или вообще не дает) — значит плохое определение и должно быть заменено.

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


DG>>>угу, миллион мух не может ошибаться.
S>>Миллион мух называет некоторое явление некоторым словом. Тут находится одна муха, которая говорит что все ошибаются и этим словом нужно называть другое явление.

DG>так именно поэтому в науке принято ссылаться на критерии, принципы и т.д. при выяснении какой вариант предпочтесть, а не на авторитеты.
DG>ты же как только тебе не хватает аргументов ссылаешься на авторитет википедии.
ты ссылаешься на собственноперевыдуманные определения, используя известные термины. Это совсем край с моей точки зрения.

DG>зы
DG>я предлагаю использовать критерий: какое определение дает большую пользу на практике. дает большую пользу, то определение — правильное и годное, дает меньшее (или вообще не дает) — значит плохое определение и должно быть заменено.

А я тебе предлагаю подставлять штрихи к используемым тобой терминам, что бы было видно, что ты используешь их в экзотической трактовке.

DG>>это невозможно, если Z задекларирован в чужой либе.

S>Что-то помешает подсунуть свой аллокатор?

т.е. такое определение уже параметрический полиморфизм?

T Add<T, TAdd = operator +(T,T)>(T x1, T x2)
{
   return TAdd(x1, x2);
}

и соответственно, если для какого-то типа нет оператора +, то его можно подсунуть

var x = Add<T, operator &&>(true, false)

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


DG>>>это невозможно, если Z задекларирован в чужой либе.

S>>Что-то помешает подсунуть свой аллокатор?

DG>т.е. такое определение уже параметрический полиморфизм?

DG>

DG>T Add<T, TAdd = operator +(T,T)>(T x1, T x2)
DG>{
DG>   return TAdd(x1, x2);
DG>}
DG>

DG>и соответственно, если для какого-то типа нет оператора +, то его можно подсунуть

Если ты подсунул, то параметрический, т.к. код не пользуется специальным знанием о типе. Если не подсунул и заработал +, то тем самым замешивается ad-hoc.

S>Если ты подсунул, то параметрический, т.к. код не пользуется специальным знанием о типе. Если не подсунул и заработал +, то тем самым замешивается ad-hoc.

т.е. так:

T Add<T, TAdd>(T x1, T x2)
{
   return TAdd(x1, x2);
}

это параметрический полиморфизм?

а так уже не всегда?

T Add<T, TAdd=operator + (T,T)>(T x1, T x2)
{
   return TAdd(x1, x2);
}

причем во всех случаях мы говорим про свойства самой функции Add, а не про свойства TAdd

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

S>>Если ты подсунул, то параметрический, т.к. код не пользуется специальным знанием о типе. Если не подсунул и заработал +, то тем самым замешивается ad-hoc.

DG>т.е. так:
DG>

DG>T Add<T, TAdd>(T x1, T x2)
DG>{
DG>   return TAdd(x1, x2);
DG>}
DG>

DG>это параметрический полиморфизм?
Да

DG>а так уже не всегда?
DG>

DG>T Add<T, TAdd=operator + (T,T)>(T x1, T x2)
DG>{
DG>   return TAdd(x1, x2);
DG>}
DG>

А так уже зависит от того, раскроется ли это определение в

T Add<T>(T x1, T x2)
{
    return operator+(x1, x2);
}

DG>причем во всех случаях мы говорим про свойства самой функции Add, а не про свойства TAdd
Да. В одном случае Add параметризована знанием о том как обращаться с параметрами, а в другом она использует специальные знания об этом, которые не могут быть применены к другим типам без явного указания сумматора.

DG>>т.е. так:
DG>>

DG>>T Add<T, TAdd>(T x1, T x2)
DG>>{
DG>>   return TAdd(x1, x2);
DG>>}
DG>>

DG>>это параметрический полиморфизм?
S>Да

даже в независимости от того, как этот Add вызывается?

T Add3<T>(T x1, T x2)
{
  return Add<T, operator + (T, T)>(x1, x2);
}

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

DG>>>

DG>>>T Add<T, TAdd>(T x1, T x2)
DG>>>{
DG>>>   return TAdd(x1, x2);
DG>>>}
DG>>>

DG>>>это параметрический полиморфизм?
S>>Да

DG>даже в независимости от того, как этот Add вызывается?
DG>

DG>  return Add<T, operator + (T, T)>(x1, x2);
DG>

даже. А почему оно должно зависеть от того, как вызывается?

S>даже. А почему оно должно зависеть от того, как вызывается?

потому что вот этот код

T Add<T, TAdd=operator+(T,T)>(T x1, T x2)
{
   return TAdd(x1, x2);
}

после преобразования в AST дает код

T Add<T, TAdd>(T x1, T x2)
{
   return TAdd(x1, x2);
}

T Add'<T>(T x1, x2)
{
  return Add<T, operator+(T,T)>(x1, x2);
}

при этом второй код ты называешь полиморфным всегда, а первый полиморфным не всегда.

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


S>>даже. А почему оно должно зависеть от того, как вызывается?

DG>потому что вот этот код
DG>после преобразования в AST дает код
DG>

DG>T Add<T, TAdd>(T x1, T x2)
DG>{
DG>   return TAdd(x1, x2);
DG>}

DG>T Add'<T>(T x1, x2)
DG>{
DG>  return Add<T, operator+(T,T)>(x1, x2);
DG>}

DG>

DG>при этом второй код ты называешь полиморфным всегда, а первый полиморфным не всегда.
Тут нет неполиморфного кода. Наверное ты про параметричность полиморфизма?
После преобразования Add параметрически полиморфен, а Add' — ad-hoc.

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

B>>В-четвертых, я не усмотрел там рекурсии. И в языке и в преобразовании она обычно присутствует.

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

Здравствуйте, x-code, Вы писали:
XC>Ничего не понял, как вы собираетесь совмещать...
Эт я читал о Немерле, букв там много но поясняющих картинок нету(я не встретил), потому постарался привести это к компактному абстрактно-графическому представлению с которым мне будет привычно и удобно работать.
XC>...и зачем так абстрактно?
Абстрактное представление даёт понимание основной идеи/концепции(сути), владея этим представлением будет легко разобраться в любом частном случае основном на это идеи/концепции. Как-то так, для меня.

XC>Могу сказать, что метапрограммирование проще всего воспринимать так. Есть несколько этапов компиляции. На первом этапе программа из исходного текста превращается в список токенов (лексический анализ), на втором — в синтаксическое дерево (AST). Это дерево ближе всего к тому, как программист представляет программу...
Это(на первой картинке первого сообщения) и есть(наверно) AST только очень урезанный(абстрактный) и показывающий только среду(например язык + библиотеки),
то есть например программист решил написать программу для чего определил главную функцию(использующую b3,e1,e2) и две дополнительных функции e1(использующую a1,b2) и e2(использующую b4,a3)
тогда граф(тепрь уже дерево) будет выглядеть так:

(красным часть создания программистом)
после компиляции(например для Си, который не мета) останется:


XC>В С++ система шаблонов построена чисто на подстановках, потому она такая монструозная. Если придумать другую систему метапрограммирования, в которой кроме подстановок будут разрешены другие — "активные" действия, определенные пользователем — то получим полноценные "плагины к компилятору", пользовательский код, который будет выполняться прямо внутри компилятора на различных этапах компиляции.
На сколько я понял, команда Немерле как раз эти и занимается, они пошли по пути совмещения функционального и мета программирования, то есть у каждого терма(макроса/шаблона) есть тип(система типов в мета языке, полиморфизм), аргументы (через которые он может принимать другие термы) и т.п. вобщем с темами можно делать всё тоже что со значениями в просто ФП.
Абстрактно можно представить что эти возможности, во время компиляции, как бы управляют ростом графа(из второй картинки первого сообщения).