Язык(среду/код) можно представить в виде направленного графа, узлы которого это набор определённых термов(единиц языка) который использует программист для написания программы и/или новых термов. Наверху графа находятся самые сложные термы состоящие из множества других, внизу примитивные(например операторы и т.п. целевой платформы). Дуги графа это ссылки указывающие на используемые термы.
(Так можно представить практически любой язык, в Си например узлами будут функции/структуры и операторы/примитивные типы(нижний уровень).)
Каждый терм в мета языке фактически представляет собой правило описывающие конструкцию(из термов на которые ссылается данный) на которую будет заменён терм после "вызова". Компилирование мета кода это преобразование всех термов в примитивные.
Например программист написал код:
a1 b2 b4 с3 d2 c2
Правила для использованных не примитивных термов:
a1 => b2 b1
b2 => c1
b4 => c4 d3
с3 => d2 d3
c2 => d2 d1
b1 => c1
c1 => d1
c4 => d3
В результате получится:
d1 d1 d1 d3 d3 d2 d3 d2 d2 d1
Представление компилирования в виде графа:
Абстрактно можно представить что граф, во время компиляции, как бы "разрастается" сверху вниз.
Скажите я правильно понял концепцию?
Спасибо.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, hardcase, Вы писали: H>О какой концепции речь?
О совмещении функционального и метапрограммирования.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
но такие преобразования не умеют напрямую(то, что через ad-hoc полиморфизм описывается одним правилом, при таком описании может потребовать увеличение кол-ва уже имещихся правил в k-раз) описывать ad-hoc полиморфизм (оно же контекстно-зависимые термы)
Здравствуйте, AlexCab, Вы писали:
H>>О какой концепции речь? AC>О совмещении функционального и метапрограммирования.
Ничего не понял, как вы собираетесь совмещать и зачем так абстрактно? Все же гораздо интереснее говорить о конкретных вещах, встречающихся в реальном программировании, а не об абстрактных "a1", "b2" etc.
Могу сказать, что метапрограммирование проще всего воспринимать так. Есть несколько этапов компиляции. На первом этапе программа из исходного текста превращается в список токенов (лексический анализ), на втором — в синтаксическое дерево (AST). Это дерево ближе всего к тому, как программист представляет программу. Если у вас есть класс, в нем метод, в методе блок (например if), в блоке аргумент условия, то это и есть дерево, где корень — сама программа, дальше — пространства имен, классы, функции, блоки, выражения, части выражений и в конце концов листья дерева — переменные, константы.
Можно предположить, что на разных этапах с представлением программы можно что-то делать Некие "действия, определенные пользователем". Так, препроцессор Си обрабатывает программу как последовательность токенов, а более продвинутые системы метапрограммирования — на этапе AST. Соответственно, метапрограммирование — это написание кода, реализующего эти действия.
В простейшем случае такими действиями будет просто подстановка фрагмента представления программы вместо некоторого аргумента. Например, в некоторой системе метапрограммирования есть "шаблоны" — по сути специальные параметризированные заготовки кода.
В С++ система шаблонов построена чисто на подстановках, потому она такая монструозная. Если придумать другую систему метапрограммирования, в которой кроме подстановок будут разрешены другие — "активные" действия, определенные пользователем — то получим полноценные "плагины к компилятору", пользовательский код, который будет выполняться прямо внутри компилятора на различных этапах компиляции.
Ну а этот код может быть написан в любой парадигме — на ассемблере, в процедурном стиле, в фуникцональном или объектно-ориентированном, или на смеси всех стилей вместе взятых, или еще каким-то образом, неизвестным науке. Это вопрос того, какой интерфейс предоставляет компилятор для доступа к самому себе. Это может быть какой-нибудь скриптовый язык типа javascript, или тот же самый язык, на котором написана основная программа — не важно, главное что если такая возможность есть, то парадигма метапрограммирования реализована полностью.
Здравствуйте, DarkGray, Вы писали:
AC>>Скажите я правильно понял концепцию? DG>в первом приближении — да.
DG>но такие преобразования не умеют напрямую(то, что через ad-hoc полиморфизм описывается одним правилом, при таком описании может потребовать увеличение кол-ва уже имещихся правил в k-раз) описывать ad-hoc полиморфизм (оно же контекстно-зависимые термы)
Расскажите что такое ad-hoc полиморфизм (и в чем разница с параметрическим) и контекстно-зависимые термы? На википедии скомканная пара абзацев, да к тому же про haskell которого я не знаю
Здравствуйте, AlexCab, Вы писали:
AC>Язык(среду/код) можно представить в виде направленного графа, узлы которого это набор определённых термов(единиц языка) который использует программист для написания программы и/или новых термов. Наверху графа находятся самые сложные термы состоящие из множества других, внизу примитивные(например операторы и т.п. целевой платформы). Дуги графа это ссылки указывающие на используемые термы. AC> AC>(Так можно представить практически любой язык, в Си например узлами будут функции/структуры и операторы/примитивные типы(нижний уровень).)
Представить можно в виде графа, в виде сети петри, в виде пятерки.. Дело ж не в том.. Ради чего такое представление и какие выводы из этого можно сделать.. Т.е. какой смысл в таком представлении. Что это нам дает?
XC> Ничего не понял, как вы собираетесь совмещать и зачем так абстрактно?
формулировка, используемая AlexCab ближе к декларативному описанию, потому что она фокусируется на том, что происходит, что изменяется.
формулировка, используемая тобой ближе к императивному описанию, потому что она фокусируется на том, как это делается, а не что при этом происходит.
желательно в голове иметь оба представление: как это делается, и что при этом происходит. Формулировка AlexCab чуть более ценная, потому что меньшее кол-во людей умеет её формулировать и оперировать ей.
XC>Могу сказать, что метапрограммирование проще всего воспринимать так.
тогда проще сказать, что метапрограммирование — это функция, которая берет на входе код и выдает на выходе другое код F:код -> код.
вид представления кода: текст, бинарник, ast и т.д. — это уже больше задача удобства.
XC> Расскажите что такое ad-hoc полиморфизм (и в чем разница с параметрическим) и контекстно-зависимые термы?
ad-hoc полиморфизм — чаще всего реализуется через перегрузку функций. и отличается от параметрического полиморфизма тем, что для разных типов используется разный код.
вот это параметрический полиморфизм (Add определен через + с помощью одного варианта кода)
T Add<T>(T x1, T x2)
{
return x1 + x2;
}
а вот это ad-hoc полиморфизм (Add определен разными способами в зависимости от типа)
int Add(int x1, int x2)
{
return x1 + x2;
}
int[] Add(int[] x1, int[] x2)
{
return x1.Concat(x2).ToArray();
}
контекстно-зависимые термы:
var x = 5;
int var = 1;
в первом случае, var преобразуется в объявление переменной, во втором в название переменной.
Console.WriteLine(x * 3);
var x = 5;
Console.WriteLine(x * 3);
первая строка "Console.WriteLine(x * 3)" преобразуется в ошибку компиляции, что переменная x не используется,
ровно такая же третья строка преобразуется в несколько инструкций byte-кода
B> Т.е. какой смысл в таком представлении. Что это нам дает?
если преобразование удалось представить в виде приведенного графа, то это дает возможность построить автомат, который будет транслировать код линейно за O(длина исходного кода) (или если есть ограничения по памяти, то почти линейно O(длина исходного кода * log длина исходного кода))
если такой граф построить не удалось, то стоимость транслирующего алгоритма будет выше линейной (и скорее всего выше, чем O(nlogn)).
Если бы компилилось на С#, было бы типичным образчиком ad-hoc полиморфизма. Здесь фактически задается имя Add для оператора сложения, который полиморфен именно в ad-hoc смысле, т.к. невозможно складывать значения обобщенным образом, не имея специальной информации о типе. Класть их в кортеж — можно. Складывать — увы. Об этом тебе должен был сказать компилятор.
S>Если бы компилилось на С#, было бы типичным образчиком ad-hoc полиморфизма. Здесь фактически задается имя Add для оператора сложения, который полиморфен именно в ad-hoc смысле, т.к. невозможно складывать значения обобщенным образом, не имея специальной информации о типе. Класть их в кортеж — можно. Складывать — увы. Об этом тебе должен был сказать компилятор.
Ну то есть параметрический полиморфизм — это когда нам действительно пофиг, что там за типы — как на этапе компиляции, так и на этапе выполнения. Например, вызываем метод базового типа, который никак не переопределен в дочерних типах.
А ad-hoc — когда на этапе компиляции нам пофиг, а на этапе выполнения — уже нет. Например — вызываем метод, который переопределен в каждом дочернем типе как-то по своему.
Я прав?
S>Если бы компилилось на С#, было бы типичным образчиком ad-hoc полиморфизма. Здесь фактически задается имя Add для оператора сложения, который полиморфен именно в ad-hoc смысле, т.к. невозможно складывать значения обобщенным образом, не имея специальной информации о типе. Класть их в кортеж — можно. Складывать — увы. Об этом тебе должен был сказать компилятор.
про C# говорить сложно, потому что он не умеет использовать ad-hoc полиморфизм из параметрического полиморфизма
в следующем коде: Sum — параметрический полиморфизм, Add — ad-hoc полиморфизм, Add2 — можно трактовать и так, и так, в зависимости от того как делается деление по входу или по выходу.
template<typename T>
T Sum(typename std::vector<T>::iterator begin, typename std::vector<T>::iterator end)
{
T t;
for (typename std::vector<T>::const_iterator it = begin; it != end; ++it)
{
Add2(t, *it);
}
return t;
};
template<typename T>
void Add2(T& x, T value)
{
x = Add(x, value);
}
bool Add(int x, int value)
{
return x + value;
}
bool Add(bool x, bool value)
{
return x || value;
}
S> т.к. невозможно складывать значения обобщенным образом, не имея специальной информации о типе. Класть их в кортеж — можно.
по такому определению даже вектор не является параметрическим полиморфизмом, потому что при хранении типа в векторе требуется специальная информация от типа, как именно данный тип копируется, и соответственно компилятор должен был бы сказать "бла-бла, то что ты там утверждаешь".
Здравствуйте, x-code, Вы писали:
XC>Здравствуйте, samius, Вы писали:
DG>>>вот это параметрический полиморфизм (Add определен через + с помощью одного варианта кода) DG>>>
S>>Если бы компилилось на С#, было бы типичным образчиком ad-hoc полиморфизма. Здесь фактически задается имя Add для оператора сложения, который полиморфен именно в ad-hoc смысле, т.к. невозможно складывать значения обобщенным образом, не имея специальной информации о типе. Класть их в кортеж — можно. Складывать — увы. Об этом тебе должен был сказать компилятор.
XC>Ну то есть параметрический полиморфизм — это когда нам действительно пофиг, что там за типы — как на этапе компиляции, так и на этапе выполнения. Например, вызываем метод базового типа, который никак не переопределен в дочерних типах.
Время компиляции/выполнения не имеет значения. Параметрический полиморфизм не требует специальных знаний о типе и позволяет писать код, который будет работать для всех типов. Как правило это обобщенные контейнеры (но не требующие сравнения, hashcode и т.п.), кортежи, в том числе старые необобщенные контейнеры типа ArrayList, методы по работе с ними. И вообще все, что можно сделать для заранее неизвестного типа.
XC>А ad-hoc — когда на этапе компиляции нам пофиг, а на этапе выполнения — уже нет. Например — вызываем метод, который переопределен в каждом дочернем типе как-то по своему. XC>Я прав?
Ad-hoc — это все, что связано со специальными знаниями о типе. Прежде всего — операторы, которые определены для множества типов. Например, складывать можем целые, плавающие, строки. Для каждого случая ищется специальный способ сложения. Вывод в консоль значения требует специального знания о том, как это значение преобразовать в строку. Перегрузка (overload) методов, операторов — типичный пример ad-hoc полиморфизма.
Отдельной категорией идет subtype полиморфизм. Прежде всего он родственен с параметрическим, потому как позволяет вызывать код единым образом для всех подтипов (но не позволяет для неродственных типов). Отдельный смысл у subtype полиморфизма в ООП программировании подразумевается в возможности переопределять (override) методы для подтипов. Это роднит его с ad-hoc полиморфизмом, т.к. позволяет указывать специальные методы для отдельных ветвей подтипов.
В жизни это все здорово перемешивается. Например, Dictionary<K,V> — вроде как пример параметрически полиморфного контейнера. Пока мы параметризуем его создание специальным объектом, который учит контейнер считать хэшкод и сравнивать элементы, — все впорядке. Однако, сам компарер — образец subtype полиморфизма. Если мы его не подадим, будет подан EqualityComparer<K>.Default, который зная о типе K может подсунуть специальный компарер для K. Это уже ad-hoc (причем времени выполнения, а не компиляции).
Здравствуйте, DarkGray, Вы писали:
B>> Т.е. какой смысл в таком представлении. Что это нам дает?
DG>если преобразование удалось представить в виде приведенного графа, то это дает возможность построить автомат, который будет транслировать код линейно за O(длина исходного кода) (или если есть ограничения по памяти, то почти линейно O(длина исходного кода * log длина исходного кода)) DG>если такой граф построить не удалось, то стоимость транслирующего алгоритма будет выше линейной (и скорее всего выше, чем O(nlogn)).
Во первых какой такой "приведенный граф"? .
Во-вторых речь шла цитирую "Язык(среду/код) можно представить в виде направленного графа, узлы которого это набор определённых термов(единиц языка) который использует программист для написания программы и/или новых термов. Наверху графа находятся самые сложные термы состоящие из множества других, внизу примитивные(например операторы и т.п. целевой платформы). Дуги графа это ссылки указывающие на используемые термы". Вам не кажется что "представить преобразование" и "представить язык" это разные вещи?
В-третьих, совсем не очевидно если можно представить (и что представить язык или преобразования) в (я так и не понял какие такие особые свойства у данного графа) таком виде то компиляция будет линейна.
В-четвертых, я не усмотрел там рекурсии. И в языке и в преобразовании она обычно присутствует. Собственно, это именна та фишка которая позволяет генерировать довольно мощные языки из грамматики. Без рекурсивности в определения грамматик нам пришлось бы сложновато. Отсюда следует любопытная штука.. Что преобразование выглядит вроде простым, а реально там будет рекурсия в разборе.. а вместе с рекурсией возникает не линейность в разборе.. не со всякой рекурсией, конечно, но в общем случае возникает..
И в пятых. Язык сам по себе являющимся линейным.. в том смысле, что там одна буква следует за другой, может иметь иерархическое содержание которое влечет за собой рекурсию. Классический пример: "У попа была собака он ее любил, потом убил и закопал и надпись написал "у попа бывла собака он ее любил...". Или вызов рекурсивной функции..
И... хотя этого достаточно.. не хочется сюда вопросы философии лепить..
S>>Если бы компилилось на С#, было бы типичным образчиком ad-hoc полиморфизма. Здесь фактически задается имя Add для оператора сложения, который полиморфен именно в ad-hoc смысле, т.к. невозможно складывать значения обобщенным образом, не имея специальной информации о типе. Класть их в кортеж — можно. Складывать — увы. Об этом тебе должен был сказать компилятор.
DG>про C# говорить сложно, потому что он не умеет использовать ad-hoc полиморфизм из параметрического полиморфизма
Вот пример EqualityComparer<T>.Default
DG>в следующем коде: Sum — параметрический полиморфизм, Add — ad-hoc полиморфизм, Add2 — можно трактовать и так, и так, в зависимости от того как делается деление по входу или по выходу. DG>
Не соглашусь. Методы Sum и Add2 не могут работать для любого типа без специального кода.
S>> т.к. невозможно складывать значения обобщенным образом, не имея специальной информации о типе. Класть их в кортеж — можно.
DG>по такому определению даже вектор не является параметрическим полиморфизмом, потому что при хранении типа в векторе требуется специальная информация от типа, как именно данный тип копируется, и соответственно компилятор должен был бы сказать "бла-бла, то что ты там утверждаешь".
Как бы эта информация берется из типа элемента, потому сам вектор ни в каких дописываниях для элементов некоторого типа не нуждается. Можем смело считать вектор образцом параметрического полиморфизма, задвинув под ковер его специализацию для bool-ов.
B>В-четвертых, я не усмотрел там рекурсии. И в языке и в преобразовании она обычно присутствует.
в большинстве случаев от рекурсии лучше переходить к итерированию по дереву.
для такого итерирования достаточно тривиально доказывается конечность алгоритма, в отличии от рекурсии.
Здравствуйте, DarkGray, Вы писали:
S>>Как бы эта информация берется из типа элемента, потому сам вектор ни в каких дописываниях для элементов некоторого типа не нуждается.
DG>ню-ню DG>расскажи, пожалуйста, с каких пор ссылка на тип перестала быть типом? и с каких пор можно определить вектор для типа int& (std::vector<int&>)?
Хорошо, не будем считать вектор образцом параметрического полиморфизма. Но вместе с ним и List<T>, И Tuple<T> и т.п.
S>Хорошо, не будем считать вектор образцом параметрического полиморфизма. Но вместе с ним и List<T>, И Tuple<T> и т.п.
поэтому я и утверждаю, что твоя трактовка параметрического полиморфизма мало используемая, и не несет никакой полезной информации для практического использования.
Здравствуйте, DarkGray, Вы писали:
S>>Не соглашусь. Методы Sum и Add2 не могут работать для любого типа без специального кода.
DG>так же можешь рассказать, почему std::vector не работает в следующих случаях:
DG>ps DG>а не работает оно всё по той же причине, нема для этих типов необходимо для вектора функционала
Это решается без вмешательства в код вектора и в том числе без специализации.
Здравствуйте, DarkGray, Вы писали:
S>>Хорошо, не будем считать вектор образцом параметрического полиморфизма. Но вместе с ним и List<T>, И Tuple<T> и т.п.
DG>поэтому я и утверждаю, что твоя трактовка параметрического полиморфизма мало используемая, и не несет никакой полезной информации для практического использования.
Это не моя трактовка. Это общая трактовка. Вот когда твоя трактовка продержится в википедии пару лет, тогда поговорим о твоей.
Здравствуйте, DarkGray, Вы писали:
S>>Это не моя трактовка. Это общая трактовка. Вот когда твоя трактовка продержится в википедии пару лет, тогда поговорим о твоей.
DG>угу, миллион мух не может ошибаться.
Миллион мух называет некоторое явление некоторым словом. Тут находится одна муха, которая говорит что все ошибаются и этим словом нужно называть другое явление.
S>>Это решается без вмешательства в код вектора и в том числе без специализации.
DG>приведи код.
Лень. Но в Z надо будет открыть оператор присваивания, а для F уж придется делать специализацию. Соглашусь, вектор не лучший пример параметрического полиморфизма. Давай возьмем список в хаскеле.
это невозможно, если Z задекларирован в чужой либе.
S> Давай возьмем список в хаскеле.
хаскель плохой пример — в нем искусственно оставлены только те типы, которые поддерживают операцию копирования по ссылке. все неудобные типы из хаскеля вырезаны.
Здравствуйте, DarkGray, Вы писали:
S>>Но в Z надо будет открыть оператор присваивания
DG>это невозможно, если Z задекларирован в чужой либе.
Что-то помешает подсунуть свой аллокатор?
S>> Давай возьмем список в хаскеле.
DG>хаскель плохой пример — в нем искусственно оставлены только те типы, которые поддерживают операцию копирования по ссылке. все неудобные типы из хаскеля вырезаны.
Наоборот, я считаю его хорошим примером параметрического полиморфизма.
DG>>угу, миллион мух не может ошибаться. S>Миллион мух называет некоторое явление некоторым словом. Тут находится одна муха, которая говорит что все ошибаются и этим словом нужно называть другое явление.
так именно поэтому в науке принято ссылаться на критерии, принципы и т.д. при выяснении какой вариант предпочтесть, а не на авторитеты.
ты же как только тебе не хватает аргументов ссылаешься на авторитет википедии.
зы
я предлагаю использовать критерий: какое определение дает большую пользу на практике. дает большую пользу, то определение — правильное и годное, дает меньшее (или вообще не дает) — значит плохое определение и должно быть заменено.
DG>>>угу, миллион мух не может ошибаться. S>>Миллион мух называет некоторое явление некоторым словом. Тут находится одна муха, которая говорит что все ошибаются и этим словом нужно называть другое явление.
DG>так именно поэтому в науке принято ссылаться на критерии, принципы и т.д. при выяснении какой вариант предпочтесть, а не на авторитеты. DG>ты же как только тебе не хватает аргументов ссылаешься на авторитет википедии.
ты ссылаешься на собственноперевыдуманные определения, используя известные термины. Это совсем край с моей точки зрения.
DG>зы DG>я предлагаю использовать критерий: какое определение дает большую пользу на практике. дает большую пользу, то определение — правильное и годное, дает меньшее (или вообще не дает) — значит плохое определение и должно быть заменено.
А я тебе предлагаю подставлять штрихи к используемым тобой терминам, что бы было видно, что ты используешь их в экзотической трактовке.
DG>>>это невозможно, если Z задекларирован в чужой либе.
S>>Что-то помешает подсунуть свой аллокатор?
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>
А так уже зависит от того, раскроется ли это определение в
T Add<T>(T x1, T x2)
{
return operator+(x1, x2);
}
DG>причем во всех случаях мы говорим про свойства самой функции Add, а не про свойства TAdd
Да. В одном случае Add параметризована знанием о том как обращаться с параметрами, а в другом она использует специальные знания об этом, которые не могут быть применены к другим типам без явного указания сумматора.
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>В С++ система шаблонов построена чисто на подстановках, потому она такая монструозная. Если придумать другую систему метапрограммирования, в которой кроме подстановок будут разрешены другие — "активные" действия, определенные пользователем — то получим полноценные "плагины к компилятору", пользовательский код, который будет выполняться прямо внутри компилятора на различных этапах компиляции.
На сколько я понял, команда Немерле как раз эти и занимается, они пошли по пути совмещения функционального и мета программирования, то есть у каждого терма(макроса/шаблона) есть тип(система типов в мета языке, полиморфизм), аргументы (через которые он может принимать другие термы) и т.п. вобщем с темами можно делать всё тоже что со значениями в просто ФП.
Абстрактно можно представить что эти возможности, во время компиляции, как бы управляют ростом графа(из второй картинки первого сообщения).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, 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 полиморфно.
DG>>при чем здесь вообще язык? ты хочешь сказать, что понятие ad hoc/parametric-полиморфизма зависит от языка? S>Нет, не хочу. На каком бы языке ты не записывал полиморфное сложение, это будет ad-hoc.
функция сложения от трех параметров, определенная через сложение от двух параметров — имеет полиморфизм параметрический или ad-hoc?
DG>>и сооответственно, Add — параметрически-полиморфен, а Operation<T>.Plus — ad-hoc полиморфна S>По каким признакам ты судишь?
тело функции зависит от типа аргументов — ad-hoc, иначе — parametric(есть if от типов или нет)
S>Определи вид полиморфизма следующих функций: S>
S>object OpPlus(object a, object b)
S>{
S> if(a is int && b is int)
S> return (int)a + (int)b;
S> throw new ArgumentException();
S>}
ad-hoc полиморфизм (без статической проверки). тело функции зависит от типов аргументов
S>object Add1(objecta a, object b)
S>{
S> return OpPlus(a, b);
S>}
parametric полиморфизм (без статической проверки). тело функции не зависит от типа аргументов
S>T Add<T>(T a, T b)
S>{
S> return OpPlus(a, b);
S>}
S>
parametric полиморфизм (со статической проверкой). тело функции не зависит от типа аргументов
S>>>Вобщем, как бы ты не записывал операцию сложения в исходном ее смысле, ты не сможешь складывать числа, строки, матрицы и многочлены одним способом.
DG>>это утверждение противоречит принципу инкапсуляции, ты утверждаешь, что свойства одной функции Add(T,T)->T зависят от реализации совсем другой функции operator +(T,T)->T S>Что за принцип инкапсуляции? Да, я утверждаю что свойства функции Add1 зависят от реализации совсем другой функции OpPlus. И еще утверждаю что сложение всегда ad-hoc полиморфно.
функции Swap_and_B и Swap_and_B2 какой полиморфизм имеют?
class B1<T>
{
T Swap_and_B(T x, T y)
{
return B(y, x);
}
public Func<T,T,T> B;
static T Swap_and_B2(T x, T y)
{
return B2(y, x);
}
public static Func<T,T,T> B2;
}
S> И еще утверждаю что сложение всегда ad-hoc полиморфно.
вот это есть карго-культовое мышление. ты когда-то где-то от какого-то авторитета узнал, что сложение ad-hoc полиморфно.
и теперь это утверждение пихаешь всюду где видишь сложение — не разбираясь о чем говорил тот самый авторитет, и как связана текущая ситуация с исходным утверждением.
Здравствуйте, DarkGray, Вы писали:
DG>функция сложения от трех параметров, определенная через сложение от двух параметров — имеет полиморфизм параметрический или ad-hoc?
ad-hoc
S>>По каким признакам ты судишь?
DG>тело функции зависит от типа аргументов — ad-hoc, иначе — parametric(есть if от типов или нет)
Очевидно что ты используешь своё определение, в котором имеет значение тело. В то время как я говорю о классическом определении.
DG>ad-hoc полиморфизм (без статической проверки). тело функции зависит от типов аргументов DG>parametric полиморфизм (без статической проверки). тело функции не зависит от типа аргументов DG>parametric полиморфизм (со статической проверкой). тело функции не зависит от типа аргументов
Я не подписывался обсуждать фантазии.
DG>функции Swap_and_B и Swap_and_B2 какой полиморфизм имеют? DG>
DG>class B1<T>
DG>{
DG> T Swap_and_B(T x, T y)
DG> {
DG> return B(y, x);
DG> }
DG> public Func<T,T,T> B;
DG> static T Swap_and_B2(T x, T y)
DG> {
DG> return B2(y, x);
DG> }
DG> public static Func<T,T,T> B2;
DG>}
DG>
Здравствуйте, DarkGray, Вы писали:
S>> И еще утверждаю что сложение всегда ad-hoc полиморфно.
DG>вот это есть карго-культовое мышление. ты когда-то где-то от какого-то авторитета узнал, что сложение ad-hoc полиморфно.
DG>и теперь это утверждение пихаешь всюду где видишь сложение — не разбираясь о чем говорил тот самый авторитет, и как связана текущая ситуация с исходным утверждением.
Ты ведь вообще не разбираешься, о чем кто говорит. Ты подменяешь понятия и говоришь о чем-то своем, даже не уведомляя что ты что-то подменил. Выясняется в конце разговора, если собеседник докопался.
проблема в том, что невозможно придумать миллион слов для миллиона оттенков, и поэтому используются другие подходы, в частности — fuzzy concepts.
зы
может быть тебе понятнее будет на примере цветов, как выглядит дисскусия в моих глазах.
обычно дискуссия выглядит так:
я прихожу и говорю, что rgb(220, 20, 60) — это красный, ты лезешь в вики и выясняешь, что там написано, что красный — это (255, 0, 0). и начинаешь меня критиковать за то, что я неправильно использую термины.
дальше я начинаю тебя пытать, а каким словом можно назвать цвет (254, 0, 0), (253, 0, 0), (252, 0, 0), (255, 0, 1) и т.д. — ты скрепя сердцем говоришь, что это тоже красный (хотя в вики это напрямую и не написано).
когда я пытаюсь тебе указать на разрыв в логике:
что цвет (250, 0, 0) — ты себе позволяешь называть красным, хотя это и некоторый отход от того определения, которое написано в вики,
а цвет (220, 20, 60) — ты мне называть красным уже не позволяешь, хотя это такой же отход от того определения, которое написано в вики;
и спрашиваю о твоей аргументации, как ты решаешь до какого предела цвет можно называть красным, а после какого нельзя — ты переходишь на последнюю линию обороны:
цвет (220, 20, 60) — нельзя называть красным, потому что (220, 20, 60) никогда не может быть красным.
DG>>>функции Swap_and_B и Swap_and_B2 какой полиморфизм имеют? DG>>>
DG>>>class B1<T>
DG>>>{
DG>>> T Swap_and_B(T x, T y)
DG>>> {
DG>>> return B(y, x);
DG>>> }
DG>>> public Func<T,T,T> B;
DG>>>}
DG>>>
S>>В классическом понимании — параметрический
DG>а если Swap_And_B переименовать в Add, B переименовать в Plus и убрать перевертывание параметров, то сразу станет ad-hoc? DG>я правильно тебя понял?
Нет, неправильно. Суть метода Swap_And_B заключается в вызове делегата с измененным порядком аргументов. Это полиморфное параметрически действие, как бы ты его не называл и что бы не подсвовывал в качестве делегата. Как обертка этот метод полиморфен параметрически. Но если смотреть на него с абсолютной точки зрения, не зная его реализации, то его свойства зависят от того, что ты подсунул в делегат. Очевидно, что подменяя делегат ты будешь менять свойства оборачивающего метода. Можно сделать его ad-hoc или нет, можно сделать его чистым, или нечистым. И в этом ничего удивительного нет.
Если ты в коробку из под телевизора сунешь картошку — получишь коробку картошки.
DG>
DG>class Operation<T>
DG>{
DG> static T Add(T x, T y)
DG> {
DG> return B2(x, y);
DG> }
DG> public static Func<T,T,T> Plus;
DG>}
DG>
DG>вот здесь уже ad-hoc? неисповедимы твои пути, господи...
С такой-то кашей в голове
Читай что пишут люди, а не выдумывай. В первую очередь это касается определений. Если ты что-то выдумал, то базис у тебя уже отличный от базиса людей, которые прочитали и поняли определение. Ты в другой системе понятий! Слова вроде те же, а смысл не тот!
S>>Ты подменяешь понятия и говоришь о чем-то своем
DG>проблема в том, что невозможно придумать миллион слов для миллиона оттенков, и поэтому используются другие подходы, в частности — fuzzy concepts.
DG>зы DG>может быть тебе понятнее будет на примере цветов, как выглядит дисскусия в моих глазах.
DG>обычно дискуссия выглядит так: DG>я прихожу и говорю, что rgb(220, 20, 60) — это красный, ты лезешь в вики и выясняешь, что там написано, что красный — это (255, 0, 0). и начинаешь меня критиковать за то, что я неправильно использую термины.
Ох уж эти сказочники...
Ты делаешь качественную подмену понятий а потом на примере легкой подмены цвета (количественной характеристики) показываешь свою позицию? Ну-ну.
S>Нет, неправильно. Суть метода Swap_And_B заключается в вызове делегата с измененным порядком аргументов.
А суть метода Zzz(T x, T y){return xx(x, y);} заключается в том, что он дает еще одно имя для произвольного действия. и эта суть параметрически-полиморфна, она не зависит от того, чем является xx.
S> Но если смотреть на него с абсолютной точки зрения, не зная его реализации, то его свойства зависят от того, что ты подсунул в делегат. Очевидно, что подменяя делегат ты будешь менять свойства оборачивающего метода. Можно сделать его ad-hoc или нет, можно сделать его чистым, или нечистым. И в этом ничего удивительного нет. S>Если ты в коробку из под телевизора сунешь картошку — получишь коробку картошки.
так никто тебя и не спрашивает каким свойством обладает коробка + содержимое, а спрашивают каким свойством обладает сама коробка в независимости от содержимого?
S>>Нет, неправильно. Суть метода Swap_And_B заключается в вызове делегата с измененным порядком аргументов.
DG>А суть метода Zzz(T x, T y){return xx(x, y);} заключается в том, что он дает еще одно имя для произвольного действия. и эта суть параметрически-полиморфна, она не зависит от того, чем является xx.
Вижу, что ты не отличаешь суть "являться именем произвольного действия" от сути "являться именем сложения".
DG>так никто тебя и не спрашивает каким свойством обладает коробка + содержимое, а спрашивают каким свойством обладает сама коробка в независимости от содержимого?
Я ответил на оба вопроса. А ты не ответил, почему у тебя одинаковые функции обладают разными свойствами. Только не надо мне отвечать про ТВОЙ полиморфизм, основанный на телах.
Здравствуйте, DarkGray, Вы писали:
S>>Ты делаешь качественную подмену понятий а потом на примере легкой подмены цвета (количественной характеристики) показываешь свою позицию? Ну-ну.
DG>так (220, 20, 60) можно называть красным или нельзя?
Можно. Можно называть зеленым, но не рассчитывай на понимание.
Здравствуйте, DarkGray, Вы писали:
B>>Глобальная.. От языка разметки, создания сайтов, до обычного программирования. Как императивного так и декларативных. В том числе и логических типа Пролога. Работает одновременно и в режиме интерпретации и компиляции.. В то же время может описывать грамматики.. Т.е является метааязыком. В частности создает сам себя.. Вообщем единый синтаксис во всем.. Ну и море других плюсов и плюсиков..
DG>есть что-то на нем уже написанное? насколько большое? DG>во что компилируется?
Нет. Пока все только в документации. И транслятор-демка. Вообще это не транслятор. Нет такого вообще. Это редактор концептов, он заменяет вообще все. И транслтор и редактор и браузер..Приложений нет как таковых..
B>>Из минусов с виндой не гармонирует..
DG>в смысле? как может язык с ОС не гармонировать?
Ну, так.. Даже расширений файлов нет. Все в едином формате.. И своя виртуальная машина..
B>> Даже алфавит строится по другому как частный случай перечислимых концептов. Да.. Я назвал это концептной парадигмой.. Можно и субъектной.. Потому как операторы (и вообще все понятия) создаются из концептов как объекты из классов..
DG>что такое концепт?
Концепт это наше все А без шуток, это единица с которой может работать компьютер. Теперь зададим вопрос, а что должно быть известно компьютеру для того что б он с этим "нечто" сомг работать. Оказывается необходимы всего две вещи :
1. Размер.
2. Программа запускаемая для реализации этого "нечто".
Добавим к этому "нечто" правила конструирования новых концептов и синтаксис, и назовем это концептом. Конечно, необходимы базовые концепты что бы мы могли создать все что угодно. Базовых концептов всего 5 Это сам концепт (Сoncept), Byte (определяющий размер), Property (определяет свойства концепта), Selector (формирующий адрес) и Document как загрузочная единица. К этим базовым концептам добавлены правила их объединения — группы. В тексте объединение концептов происходит с помощью скобок, каждая их которых соотвествует концептам -группам. Т.е. еще одной частью являются правила объединения или правила применения скобок или, как я назвал, правила группирования. Вкратце это все. К этому добавлю что программа реализующая концепт находится в обязательном свойстве Child.
DG>>так никто тебя и не спрашивает каким свойством обладает коробка + содержимое, а спрашивают каким свойством обладает сама коробка в независимости от содержимого? S>Я ответил на оба вопроса. А ты не ответил, почему у тебя одинаковые функции обладают разными свойствами. Только не надо мне отвечать про ТВОЙ полиморфизм, основанный на телах.
попробуй убрать эмоции, и написать автоматическую функцию, которая на вход берет код(например, в виде Ast-а), а на выходе выдает enum Polymorphism{ad-hoc, parametric, subtype, none}.
гарантирую, что с твоей трактовой полиморфизма такую функцию написать нельзя (а значит твое определение — магия, не имеющая алгоритмической основы).
зы
лучше, кстати, скажи — полиморфизм, кроме parametric, ad-hoc и subtype на твой взгляд еще какой-нибудь бывает?
Здравствуйте, DarkGray, Вы писали:
S>>Я ответил на оба вопроса. А ты не ответил, почему у тебя одинаковые функции обладают разными свойствами. Только не надо мне отвечать про ТВОЙ полиморфизм, основанный на телах.
Ты опять ушел от ответа.
DG>попробуй убрать эмоции, и написать автоматическую функцию, которая на вход берет код(например, в виде Ast-а), а на выходе выдает enum Polymorphism{ad-hoc, parametric, subtype, none}. DG>гарантирую, что с твоей трактовой полиморфизма такую функцию написать нельзя (а значит твое определение — магия, не имеющая алгоритмической основы).
Твоя гарантия, наверное, связана с тем, что задача некорректно поставлена. Легко написать функцию, обладающую признаками проявлений всех форм полиморфизма в одном теле, так что твой enum Polymorphism просто не сможет описать результат. Написать функцию, которая принимает AST и возвращает набор флагов не так уж и сложно. Никаких препятствий я не наблюдаю, но заниматься этим, разумеется тоже не собираюсь.
Далее, я не считаю саму невозможность написать такую функцию угрозой для определения полиморфизма из википедии. И конечно же, ты зря приписываешь мне это определение. Тут только ты выдумываешь определения для вещей, определения которым даны до тебя.
Твои определения (каждое в отдельности) страдают как минимум тем недостатком, что их формулировку никто кроме тебя не знает и соответственно, не понимает. На что ты рассчитываешь при общении с людьми — мне не понятно.
DG>зы DG>лучше, кстати, скажи — полиморфизм, кроме parametric, ad-hoc и subtype на твой взгляд еще какой-нибудь бывает?
Это зависит от способа классификации. Видишь ли, если я скажу что не бывает, ты вставишь что полиморфизм бывает еще и статический и динамический. И что мне, потом спорить с тобой что это не отдельная форма? Нет уж.
А вообще у полиморфизма много проявлений. Можно, например, вилкой в ухе ковырять. Не параметрический, не ad-hoc, не subtype, но определенно полиморфизм. А можно известным терминам выдумывать новые смыслы, что бы потроллить на форуме. Тоже полиморфизм.
S>Я ответил на оба вопроса. А ты не ответил, почему у тебя одинаковые функции обладают разными свойствами. Только не надо мне отвечать про ТВОЙ полиморфизм, основанный на телах.
одинаковые они только тем, что они делают одно и тоже.
строение у них при этом разное — одна есть надстройка над другой, при этом надстройка является параметрически-полиморфной, не зависящей от типа.
Здравствуйте, DarkGray, Вы писали:
S>>Я ответил на оба вопроса. А ты не ответил, почему у тебя одинаковые функции обладают разными свойствами. Только не надо мне отвечать про ТВОЙ полиморфизм, основанный на телах.
DG>одинаковые они только тем, что они делают одно и тоже. DG>строение у них при этом разное — одна есть надстройка над другой, при этом надстройка является параметрически-полиморфной, не зависящей от типа.
Это как это одна зависит от типа, другая нет, а делают одно и то же одним и тем же способом... Что-то темнишь.
S>Это как это одна зависит от типа, другая нет, а делают одно и то же одним и тем же способом... Что-то темнишь.
первая функция лишь перенаправляет входные данные во вторую функцию, а полученный ответ от второй функции перенаправляет как свой ответ.
и эту работу она делает параметрически полиморфно, не делая различий по типу.
S>>Это как это одна зависит от типа, другая нет, а делают одно и то же одним и тем же способом... Что-то темнишь.
DG>первая функция лишь перенаправляет входные данные во вторую функцию, а полученный ответ от второй функции перенаправляет как свой ответ. DG>и эту работу она делает параметрически полиморфно, не делая различий по типу.
И какая по-твоему польза от мнимой параметричности первой функции? Может она стала типобезопасной? Где бенефит?
S>И какая по-твоему польза от мнимой параметричности первой функции? Может она стала типобезопасной? Где бенефит?
Эта функция инкапсулирует внутри себя ad-hoc полиморфизм, позволяя записывать более сложные параметрические полиморфизмы простым образом.
Например, Сnk можно записать так
T Cnk<T>(T n, T k)
{
return Div(Factorial(n, k), Factorial(n - k));
}
T Factorial(T n, T k = One<T>())
{
T result = One<T>();
for (T i = k; Lte(i, n); Add(i, One<T>()))
{
result = Mul(result, i);
}
return result;
}
T Add<T>(T x, T y)
{
return Operation<T>.Plus;
}
T Div<T>(T x, T y)
{
return Operation<T>.Divide;
}
[...]
B>Нет. Пока все только в документации. И транслятор-демка. Вообще это не транслятор. Нет такого вообще. Это редактор концептов, он заменяет вообще все. И транслтор и редактор и браузер..Приложений нет как таковых..
что умеет демка?
на чем сейчас застопорился переход к следующему шагу?
Здравствуйте, DarkGray, Вы писали:
B>>Нет. Пока все только в документации. И транслятор-демка. Вообще это не транслятор. Нет такого вообще. Это редактор концептов, он заменяет вообще все. И транслтор и редактор и браузер..Приложений нет как таковых..
DG>что умеет демка?
DG>на чем сейчас застопорился переход к следующему шагу?
У меня кроме языка высокого уровня есть теговый язык. Там взаимнооднозначное соответствие. Вот транслятор с тегового сделан.. И отлажено система редактирования.. Там же нет приложений. Все в одном редакторе и транслторы и редакторы и графический редактор и теговое представление и базы данных.. (просмотр и редактирование таблиц) и проектирование типа UML. Вообщем понятно что делать.. Осталось только сделать.. Сам не могу по трем причинам..
1. Много. Сам не справлюсь.
2. Лучше с кем-нибудь.. Хотя б пару человек оппонировать должны.. Что б объективные решения принимать..
3. Потом надо что б на этом денег заработать.. И что толку сделать.. Надо внедрять.. А это бабки..
Хотя есть и область применения где можно быстро подняться.. Но это по любому бабки.. так что есть только документация да и то. Много ж.. Одно отредактируешь, другое забылось.. Ото что я тебе отослал было года два написано.. В синтаксисе с тех пор кое-что изменилось.. Мелочь, но выглядит то по другому.. Вот такое..
Т.е. толку с того что я знаю что бомба.. Вот с ней и живу.. Пока у власти были нормальные люди то была помощь на хорошем уровне.. А сейчас вообще одни бандюки.. Оно им не надо.. Да и я с ними работать не хочу.. Проект курировал губернатор.. и с деканом мех-мата в качестве советника.. Но все в жопе.. у нас на Украине.. Уже с год проект буксует.. Бумаги писать надоело.. Пора делать..
Здравствуйте, DarkGray, Вы писали:
S>>И какая по-твоему польза от мнимой параметричности первой функции? Может она стала типобезопасной? Где бенефит?
DG>Эта функция инкапсулирует внутри себя ad-hoc полиморфизм, позволяя записывать более сложные параметрические полиморфизмы простым образом.
DG>Например, Сnk можно записать так
Записать можно. Но это не параметрическое решение. Параметрический полиморфизм должен работать для всех типов. А единственное, на что годится это "параметрическое" решение — на поставку данных для ad-hoc-а. Т.е. назвать это решение параметрическим решением Cnk — нельзя.
Хочешь избавиться от ad-hoc — вынеси любое проявление диспетчеризации из кода. Например, так:
T Cnk<T>(T n, T k, T one, Func<T,T,T> add, Func<T,T,T> mul, Func<T,T,T> div, Func<T,T,bool> lte)
Можно собрать все операции в один класс, но тогда получишь тоже не чистое параметрическое решение, а замес либо с subtype либо с bounded полиморфизмами.
Я не утверждаю что твой Cnk никуда не годный. Просто это не параметрически полиморфное решение. И прийти к нему тебе позволила не инкапсуляция ad-hoc полиморфизма, а переход от early bound ad-hoc-а к late bound ad-hoc.
