Здравствуйте, batu, Вы писали: B>Ради чего такое представление и какие выводы из этого можно сделать.. Т.е. какой смысл в таком представлении. Что это нам дает?
Что вам не знаю, но мне интересны всякие потоки данных/инструкций, сложные структуры данных(навроде гипертекста), для работы с подобных вещей я использую инструмент "теория графов" из набора "математических инструментов" , потому такое представление удобно и привычно для меня.
B>В-четвертых, я не усмотрел там рекурсии...
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Здравствуйте, batu, Вы писали: B>>Ради чего такое представление и какие выводы из этого можно сделать.. Т.е. какой смысл в таком представлении. Что это нам дает? AC>Что вам не знаю, но мне интересны всякие потоки данных/инструкций, сложные структуры данных(навроде гипертекста), для работы с подобных вещей я использую инструмент "теория графов" из набора "математических инструментов" , потому такое представление удобно и привычно для меня.
Интерес дело святое. Это, правда мало отвечает на вопрос зачем. Могу привести свои соображения по поводу структур. По большому счету существует единственная структура последовательные байты. Ну, и возможно с прямым доступом. Но это мало что меняет. Иерархия, графы и прочее это уже наше представление этой структуры. Так не существует иерархических баз данных. Это наша придумка. Т.е. наше отношение к этим последовательным данным. И, отнюдь не единственное. Так что каталоги файлов это частный случай иерархии. Вполне реально (и даже весьма полезно) создать несколько иерархий (отношений) на эти данные. Т.е. несколько каталогов.
Весьма полезным представлением считаю сети Петри. Но это слишком общий случай. Я тут изобрел свои сети, не такие общие, но они точнее и полно моделируют архитектуру компа. Могу скинуть свои заметки. Прорабатывать их более плотно просто нет возможности и интереса. Но если есть интерес.. можем пообщаться.
B>>В-четвертых, я не усмотрел там рекурсии... AC>
Да, извини.. Не заметил. Кстати, такую рекурсию можно развернуть в цикл. Это не самый сложный из возможных вариант..
Здравствуйте, AlexCab, Вы писали:
Я тут вкратце скинул определение сетей. Назвал комплектами. За слова "событие" не очень зацикливайся. В, общем случае, за событие можно принять поступление инструкции для выполнения. У меня это типа "умное прерывание", которое возникает при выполнении условия. Извини, рисунки пришлю если будет интересно
Событие в языке Lada состоит из условия (Condition) и двух таблиц. Одна со списком входящих другая со списком выходящих связей. В терминах сетей Петри две таблицы представляют собой переход с входящими и выходящими дугами. Наличие мест (или позиций) не предусмотрено. Предполагается, что фишек в каждой позиции столько, сколько необходимо для срабатывания данной входной дуги. Наличие позиций и фишек в сети Петри придает некое семантическое содержание конкретной входной дуге, разрешая или запрещая влияние этой дуги на судьбу перехода. Удалив позиции, мы лишаемся возможности в этом смысле управлять семантикой входной дуги, упрощая ее до непосредственного влияния дуги на переход. Однако это влияние заключается только во включении-выключении дуги. Своим наличием место разделяет переход от перехода-источника, а непосредственная связь между переходами может быть гораздо информативней в смысле семантики. Механизм включения-выключения можно организовать двумя типами переходов переход-И, и переход-ИЛИ. Переход-И срабатывает тогда когда срабатывают все входящие в него дуги. Переход-ИЛИ срабатывает тогда когда срабатывает хотя бы одна дуга, входящая в переход. Переход-И и переход-Или с единственной входной дугой срабатывает одинаково. Переходы И/Или определенные вместе с условиями (Condition) образуют комплекты И/Или. Логика работы комплекта следующая. Сначала срабатывает переход, после этого проверяется условие. Если условие истинно или отсутствует, то комплект срабатывает.
Обозначим комплекты как принято в сетях Петри черточками. Только комплект-Или с треугольником над или под чертой вершиной к черте, а комплект-И треугольником у которого на черте основание. Комплекты с единственной входной дугой могут обозначаться чертой без треугольника, так как тип перехода для них не имеет значения. Комплекты, порождаемые объектом или оператором, могут обозначаться чертой под порождающим оператором или объектом.
Дуги будем обозначать, как и принято, стрелками в сторону входа в комплект. Сеть, образованную комплектами и связанную дугами, будем называть сетью комплектов.
Определение сети комплектов представляет собой множество комплектов K, где к каждому элементу kj этого множества соответствуют два подмножества I и O множества К без kj. Множество I определяет входные дуги, а множество O выходные. Отсутствие в них элемента kj говорит об отсутствии входных и выходных дуг в себя.
Такое определение может показаться избыточным. Так как достаточно определить только входные или только выходные дуги. И по одному из этих вариантов построить недостающее множество. Однако есть семантическая разница, и мы ее позже покажем. Сейчас определим еще два класса сетей комплектов, сети комплектов с подпиской и сети комплектов с посылкой. Сети комплектов с подпиской определяются только множеством входных дуг, а выходные дуги строятся по так называемой подписке. Подпиской на комплект ki назовем определение входной дуги в комплекте kj исходящей из комплекта ki. Сеть комплектов с посылкой определяется только множеством выходных дуг. В этом случае множество входных дуг строится по посылке. Посылкой на комплект ki назовем определение выходной дуги в комплекте kj входящей в комплект ki. Метод построения сетей комплектов с подпиской будем называть построением по правилу подписки, а метод построения комплектов с посылкой назовем построением комплектов по правилу посылки.
Срабатывание комплекта назовем событием. Событие влечет за собой запуск процедуры обработки события и срабатывание исходящих дуг. Процедура обработки события представляет собой функциональную часть, которую необходимо выполнить при возникновении события. Выполнение процедуры обработки события может занять некоторое время и ресурсы. Назовем это ценой комплекта. Цена комплекта если она необходима для анализа сети пишется в треугольнике.
Каждый комплект связан с другими комплектами входными и выходными дугами, определяя соответственно входные и выходные комплекты.
Под чертой можно написать имя комплекта, второй строкой условие и далее операторы процедуры обработки события.
Здравствуйте, batu, Вы писали:
B>Могу скинуть свои заметки.
Буду примного благодарен. => cabsoftbox<собака>gmail<точкаком>
B>Событие в языке Lada состоит из условия (Condition) и двух таблиц. Одна со списком входящих другая со списком выходящих связей. В терминах сетей Петри две таблицы представляют собой переход с входящими и выходящими дугами. Наличие мест (или позиций) не предусмотрено. Предполагается, что фишек в каждой позиции столько, сколько необходимо для срабатывания данной входной дуги. Наличие позиций и фишек в сети Петри придает некое семантическое содержание конкретной входной дуге, разрешая или запрещая влияние этой дуги на судьбу перехода...
Это похоже на Dataflow programming, это оно?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Здравствуйте, batu, Вы писали:
B>>Могу скинуть свои заметки. AC>Буду примного благодарен. => cabsoftbox<собака>gmail<точкаком>
B>>Событие в языке Lada состоит из условия (Condition) и двух таблиц. Одна со списком входящих другая со списком выходящих связей. В терминах сетей Петри две таблицы представляют собой переход с входящими и выходящими дугами. Наличие мест (или позиций) не предусмотрено. Предполагается, что фишек в каждой позиции столько, сколько необходимо для срабатывания данной входной дуги. Наличие позиций и фишек в сети Петри придает некое семантическое содержание конкретной входной дуге, разрешая или запрещая влияние этой дуги на судьбу перехода... AC>Это похоже на Dataflow programming, это оно?
Нет. Это я сам сочинил для своего языка.. Дело в том, что такое представление легко ложится сразу на мой язык программирования.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
B>Но я не понял почему из итерирования по дереву следует тривиальность доказательтва конечности алгоритмя.
если дерево конечное, и мы на каждой итерации обследуем другой узел, то алгоритм заведомо остановится после того как обработает все узлы.
B> И в чем отличие от рекурсии.
для конечности рекурсии необходимо сначала придумать нетривиальное доказательство, что, например, она подобна обходу конечного дерева, или что на каждом шаге уменьшается некое число или еще что-нибудь. основная загвоздка именно в нетривиальности.
B> И о каком алгоритме идет речь. Алгоритме разбора или алгоритме выполнения? Моя твоя не понимаит соасем..
речь зашла о задачах метапрограммирования F:код->код, соответственно это алгоритмы разбора, трансляции, статической проверки и т.д.
в целом, в том же C/C++ рекурсии нет, ее, конечно, можно притянуть за уши и сказать, что для построения Ast, его обработки и преобразования в маш.код нужна рекурсия, но это из пушки по воробьям, потому что для всего этого достаточно понятия дерева, возможности его построения, обхода и преобразования в другое дерево.
Здравствуйте, DarkGray, Вы писали:
B>>Но я не понял почему из итерирования по дереву следует тривиальность доказательтва конечности алгоритмя.
DG>если дерево конечное, и мы на каждой итерации обследуем другой узел, то алгоритм заведомо остановится после того как обработает все узлы.
Понял
B>> И в чем отличие от рекурсии.
DG>для конечности рекурсии необходимо сначала придумать нетривиальное доказательство, что, например, она подобна обходу конечного дерева, или что на каждом шаге уменьшается некое число или еще что-нибудь. основная загвоздка именно в нетривиальности.
Ну, это само собой..
B>> И о каком алгоритме идет речь. Алгоритме разбора или алгоритме выполнения? Моя твоя не понимаит соасем..
DG>речь зашла о задачах метапрограммирования F:код->код, соответственно это алгоритмы разбора, трансляции, статической проверки и т.д.
DG>в целом, в том же C/C++ рекурсии нет, ее, конечно, можно притянуть за уши и сказать, что для построения Ast, его обработки и преобразования в маш.код нужна рекурсия, но это из пушки по воробьям, потому что для всего этого достаточно понятия дерева, возможности его построения, обхода и преобразования в другое дерево.
Могу подкинуть весьма продуктивную идею, которую применил в своем языке. Но, это применимо и в других. У меня общий синтаксис со следующейграмматикой.
Концепт = "имя класса концепта" "имя концепта" "Особенности класса" "Реализация".
Получается в разборе идет общая часть с именем класса концепта и с именем концепта, потом дерево в зависимости от особенностей класса, а потом ветки дерева сходятся в общую часть (Реализация). И я сделал оператор Swith который создает перечислимую переменную S от имени класса (заносим в стек, конечно) затем идет имя, потом оператор Execute Swith по значению S (типа оператора select) который выполняет ветвление по значению переменной после которого опять общая часть. Я, надеюсь, понял. Получается дерево с объединенными ветками на каком то этапе. Иначе пришлось бы рекурсию запускать.. Вот..
DG>>при этом второй код ты называешь полиморфным всегда, а первый полиморфным не всегда. S>Тут нет неполиморфного кода. Наверное ты про параметричность полиморфизма? S>После преобразования Add параметрически полиморфен, а Add' — ad-hoc.
вообще мне в твоей трактовке не нравится то, что значение свойства (параметрический полиморфизм или ad-hoc) меняется при переходе от синтаксического сахара к семантике
вот этот код есть синтаксический сахар:
T Add<T>(T x1, T x2)
{
return x1 + x2;
}
компилятор автоматически выводит шаблонные-параметры: вынося в параметры все используемые функции, которые принимают на вход хотя бы один из уже зафиксированных шаблонных типов.
и получает код вида:
T Add<T, TAdd=operator + (T, T)>(T x1, T x2)
{
return TAdd(x1, x2);
}
данный код есть синтаксический сахар для семантического представления ниже (или если описательно: когда в коде встречается вызов Add с одним шаблонным параметром, то он преобразуется в вызов с двумя параметрами и в качестве значения второго параметра берется значение указанное после '=')
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);
}
в обоих преобразования исходная функция Add переходит в соответствующую функцию Add из результирующего представления.
но при этом в первом коде ты функцию Add называешь имеющей ad-hoc полиморфизм, а в последнем представлении — уже имеющей параметрический полиморфизм.
я же считаю, что во всех представлениях сама функция Add имеет параметрический полиморфизм, а вот используемый ей operator + имеет ad-hoc полиморфизм.
B>>У меня общий синтаксис со следующейграмматикой. B>>Концепт = "имя класса концепта" "имя концепта" "Особенности класса" "Реализация".
DG>пример кода для этого описания приведи, пожалуйста.
Не вопрос..
1. For I=1 To N {A:=I+A} For -имя класса концепта I — имя концепта "To N " — особенности класса концепта и в фигурных скобках реализация
2. Form I {Size =20;140} Form -имя класса I-Имя, без особенностей. и в скобках реализация..
Здравствуйте, DarkGray, Вы писали:
S>>После преобразования Add параметрически полиморфен, а Add' — ad-hoc.
DG>вообще мне в твоей трактовке не нравится то, что значение свойства (параметрический полиморфизм или ad-hoc) меняется при переходе от синтаксического сахара к семантике
Давай попробуем разобраться.
DG>вот этот код есть синтаксический сахар: DG>
Этот код есть синтаксический мусор. По сути здесь написано
Add = (+) // (1)
только чуть более строго с явным указанием типов.
DG>компилятор автоматически выводит шаблонные-параметры: вынося в параметры все используемые функции, которые принимают на вход хотя бы один из уже зафиксированных шаблонных типов. DG>и получает код вида: DG>
Какой шустрый компилятор. Фактически из (1) он вывел еще одну функцию, которая с (+) уже не имеет ничего общего (2):
Add<TAdd> = TAdd // (2)
Add = Add<(+)> // (3)
Т.е. ты пишешь код на каком-то неизвестном мне языке (это не C#), твой неизвестный компилятор делает нетривиальные преобразования кода, при этом ты предъявляешь ко мне претензию что твой компилятор переходит от одного полиморфизма к другому. Извини, я не брался отвечать за некий неизвестный мне компилятор. Могу лишь предположить, где какой полиморфизм используется.
DG>данный код есть синтаксический сахар для семантического представления ниже (или если описательно: когда в коде встречается вызов Add с одним шаблонным параметром, то он преобразуется в вызов с двумя параметрами и в качестве значения второго параметра берется значение указанное после '=') DG>
DG>в обоих преобразования исходная функция Add переходит в соответствующую функцию Add из результирующего представления. DG>но при этом в первом коде ты функцию Add называешь имеющей ad-hoc полиморфизм, а в последнем представлении — уже имеющей параметрический полиморфизм.
первый твой код (1) это в точности оператор +, снабженный новым именем Add и ограниченный в типах аргумента и результата. Говорить о том что он из ad-hoc полиморфизма вдруг превратился во что-то другое — абсурд.
второй твой код (2) — это в точности та функция, которой параметризовали функцию Add. Кроме параметрического полиморфизма здесь больше не о чем говорить, т.к. никаких специальных знаний эта запись не несет.
третий кусок кода (3) — это вызов кода (2), параметризованный оператором (+). При том что (2) параметрически параметризован, запись (3) является замусоренной версией вызова оператора (+), который ad-hoc. Очевидно, что запись (3) не сможет работать с типами, с которыми не сможет работать оператор (+), т.к. это в точности он и есть.
DG>я же считаю, что во всех представлениях сама функция Add имеет параметрический полиморфизм, а вот используемый ей operator + имеет ad-hoc полиморфизм.
Объясни мне с твоей точки зрения, как так получается что
у объектов если классы, а есть интерфейсы: первое содержат реализацию, вторые — только декларацию входов/выходов.
для функций всё тоже самое: функцию можно рассматривать вместе с телом (назовем, это класс' функции), а можно только как декларацию (назовем интерфейс' функции).
operator + есть функция.
запись + (а также operator +(T,T)->T и т.д.) одновременно обозначает как класс' функции operator +, так и интерфейс' функции operator +
при этом спецификация интерфейса' функции operator +, как спецификация всякой сложной функции, говорит, что переданные два параметра одного типа — либо будут сложены и возвращены, либо будет возвращена ошибка, если по каким-то причинам это не получилось.
для однозначности дальше класс' функции operator + будем обозначать, как +[c], а интерфейс' функции operator +, как +[i]
если взять Add и расскрыть неоднозначность записи operator +, то получим:
T Add<T>(T x1, T x2)
{
return x1 +[i] x2;
}
или описательно: для функции operator+(T,T) задаем ей эквивалентную Add(T,T), тело которой задаем через интерфейс функции operator +(T,T)->T.
соответственно такое задание параметрически полиморфное, потому что тело задано как код, который не зависит от T
задает operator+[c] для общего типа T: T operator+[c] (T x, T y){..}, при этом для неуказанных типов используется поведение по умолчанию — формирование ошибки, что данная функция для данного типа не поддерживается.
данная функция имеет ad-hoc полиморфизм, потому что ее тело зависит от значения типа T
при сборке программы в единое целое, в функцию Add в качестве реализации +[i](T,T)->T подставляется адрес вышеуказанной функции +[c](T,T)->T
Здравствуйте, DarkGray, Вы писали:
S>>Давай попробуем разобраться.
DG>у объектов если классы, а есть интерфейсы: первое содержат реализацию, вторые — только декларацию входов/выходов. DG>для функций всё тоже самое: функцию можно рассматривать вместе с телом (назовем, это класс' функции), а можно только как декларацию (назовем интерфейс' функции). DG>operator + есть функция.
Пусть так
DG>запись + (а также operator +(T,T)->T и т.д.) одновременно обозначает как класс' функции operator +, так и интерфейс' функции operator + DG>при этом спецификация интерфейса' функции operator +, как спецификация всякой сложной функции, говорит, что переданные два параметра одного типа — либо будут сложены и возвращены, либо будет возвращена ошибка, если по каким-то причинам это не получилось.
Я все понять не мог, что за язык ты используешь. Обычно для языков со статической типизацией + не определяется как (T,T)->T, а куда более прозаичен: (int,int)->int, (float,float)->float и т.п., не исключая (Foo,int)->Foo
Давай я напишу соответствующий метод на С#, а ты скажешь, понял я тебя или нет?
T Add<T>(T a, T b)
{
return ((dynamic)a) + b;
}
class Foo {}
void Main()
{
Console.WriteLine(Add(1, 2.5)); // 3,5
Console.WriteLine(Add(new Foo(), new Foo())); // RuntimeBinderException
}
Но даже этот метод Add ad-hoc полиморфен. Вызвать ты его сможешь для любого типа, но его реализация использует специальные знания о типах. Проблема в том, что ad-hoc полиморфно само сложение. Перейти к параметрическому полиморфизму можно лишь изменив смысл операции. Например:
T AddV1(T a, T b) { return a/*+b*/; }
T AddV2(T a, T b) { throw new Exception(); }
Вобщем, как бы ты не записывал операцию сложения в исходном ее смысле, ты не сможешь складывать числа, строки, матрицы и многочлены одним способом.
DG>для однозначности дальше класс' функции operator + будем обозначать, как +[c], а интерфейс' функции operator +, как +[i]
Не возражаю. С замечанием о том, что ты не сможешь обеспечить одну реализацию сложения для любого T.
DG>если взять Add и расскрыть неоднозначность записи operator +, то получим: DG>
DG>или описательно: для функции operator+(T,T) задаем ей эквивалентную Add(T,T), тело которой задаем через интерфейс функции operator +(T,T)->T. DG>соответственно такое задание параметрически полиморфное, потому что тело задано как код, который не зависит от T
Есть возражения. Операция сложения ad-hoc полиморфна по своему смыслу. Как только ты обеспечил более одного варианта реализации, так сразу попал в ad-hoc.
DG>задание функций operator + для частных типов DG>задает operator+[c] для общего типа T: T operator+[c] (T x, T y){..}, при этом для неуказанных типов используется поведение по умолчанию — формирование ошибки, что данная функция для данного типа не поддерживается. DG>данная функция имеет ad-hoc полиморфизм, потому что ее тело зависит от значения типа T
DG>при сборке программы в единое целое, в функцию Add в качестве реализации +[i](T,T)->T подставляется адрес вышеуказанной функции +[c](T,T)->T
B>>которую применил в своем языке.
DG>у языка какая цель?
Глобальная.. От языка разметки, создания сайтов, до обычного программирования. Как императивного так и декларативных. В том числе и логических типа Пролога. Работает одновременно и в режиме интерпретации и компиляции.. В то же время может описывать грамматики.. Т.е является метааязыком. В частности создает сам себя.. Вообщем единый синтаксис во всем.. Ну и море других плюсов и плюсиков.. Из минусов с виндой не гармонирует.. Даже алфавит строится по другому как частный случай перечислимых концептов. Да.. Я назвал это концептной парадигмой.. Можно и субъектной.. Потому как операторы (и вообще все понятия) создаются из концептов как объекты из классов..
S>Я все понять не мог, что за язык ты используешь. Обычно для языков со статической типизацией + не определяется как (T,T)->T, а куда более прозаичен: (int,int)->int, (float,float)->float и т.п., не исключая (Foo,int)->Foo
при чем здесь вообще язык? ты хочешь сказать, что понятие ad hoc/parametric-полиморфизма зависит от языка?
S>Давай я напишу соответствующий метод на С#, а ты скажешь, понял я тебя или нет?
скорее нет.
ближайший код на c#:
T Add<T>(T x, T y)
{
return Operation<T>.Plus(x, y);
}
static class Operation<T>
{
public readonly static Func<T,T,T> Plus = GeneratePolymorphicPlus();
}
и сооответственно, Add — параметрически-полиморфен, а Operation<T>.Plus — ad-hoc полиморфна
S>Вобщем, как бы ты не записывал операцию сложения в исходном ее смысле, ты не сможешь складывать числа, строки, матрицы и многочлены одним способом.
это утверждение противоречит принципу инкапсуляции, ты утверждаешь, что свойства одной функции Add(T,T)->T зависят от реализации совсем другой функции operator +(T,T)->T
B>Глобальная.. От языка разметки, создания сайтов, до обычного программирования. Как императивного так и декларативных. В том числе и логических типа Пролога. Работает одновременно и в режиме интерпретации и компиляции.. В то же время может описывать грамматики.. Т.е является метааязыком. В частности создает сам себя.. Вообщем единый синтаксис во всем.. Ну и море других плюсов и плюсиков..
есть что-то на нем уже написанное? насколько большое?
во что компилируется?
B>Из минусов с виндой не гармонирует..
в смысле? как может язык с ОС не гармонировать?
B> Даже алфавит строится по другому как частный случай перечислимых концептов. Да.. Я назвал это концептной парадигмой.. Можно и субъектной.. Потому как операторы (и вообще все понятия) создаются из концептов как объекты из классов..
Здравствуйте, DarkGray, Вы писали:
S>>Я все понять не мог, что за язык ты используешь. Обычно для языков со статической типизацией + не определяется как (T,T)->T, а куда более прозаичен: (int,int)->int, (float,float)->float и т.п., не исключая (Foo,int)->Foo
DG>при чем здесь вообще язык? ты хочешь сказать, что понятие ad hoc/parametric-полиморфизма зависит от языка?
Нет, не хочу. На каком бы языке ты не записывал полиморфное сложение, это будет ad-hoc.
DG>и сооответственно, Add — параметрически-полиморфен, а Operation<T>.Plus — ad-hoc полиморфна
По каким признакам ты судишь?
Определи вид полиморфизма следующих функций:
object OpPlus(object a, object b)
{
if(a is int && b is int)
return (int)a + (int)b;
throw new ArgumentException();
}
object Add1(objecta a, object b)
{
return OpPlus(a, b);
}
T Add<T>(T a, T b)
{
return OpPlus(a, b);
}
желательно с аргументами.
S>>Вобщем, как бы ты не записывал операцию сложения в исходном ее смысле, ты не сможешь складывать числа, строки, матрицы и многочлены одним способом.
DG>это утверждение противоречит принципу инкапсуляции, ты утверждаешь, что свойства одной функции Add(T,T)->T зависят от реализации совсем другой функции operator +(T,T)->T
Что за принцип инкапсуляции? Да, я утверждаю что свойства функции Add1 зависят от реализации совсем другой функции OpPlus. И еще утверждаю что сложение всегда ad-hoc полиморфно.
, потому такое представление удобно и привычно для меня.
