Функции языка для реализации алгебры отношений
Понятия разлагаются в сочетании и дизъюнкции атомных ограничений посредством процесса, называемого нормализацией ограничений , описанного в temp.constr.normal .
Только:
- логический и
&&, - логический или
||, - Заключенное в скобки выражение
() - и id-выражение вида
C, где C именует концепт
, разложены , Все остальные выражения являются атомными ограничениями .
Таким образом, требование-выражение , в целом, является атомным ограничением. В понятии TS требование-выражение было разложено, а в C ++ 20 - нет. Насколько я помню, я только что прочитал все документы комитета по c ++, связанные с концепциями, причина была в том, что нормализация выражения требования может привести к взрыву сложности, который может снизить скорость компиляции.
Итак:
requires(T a, T b) {
requires requires(T a, T b){a.foo(b)}
|| requires(T a, T b){a.bar(b)}; // Req 1
{ a.baz() }; // Req 2
// and onward
};
является атомным ограничением . И
requires(T a, T b) {
{a.foo(b)}
{ a.baz() }; // Req 2
// and onward
}
|| requires(T a, T b) {
{a.bar(b)}
{ a.baz() }; // Req 2
// and onward
};
является дизъюнкцией двух атомных ограничений. (два требуют выражения )
И наконец:
( requires(T a, T b) { a.foo(b); } || requires (T a, T b) { a.bar(b); } )
&& requires(T a, T b) { a.baz(); /* and onward */};
- это соединение дизъюнкции с атомным ограничением.
5 ответов
Учебное руководство D почти так же просто, и, как тесно выровнено к реляционной теории язык может быть.
Что Ваша просьба о должна смочь структурно определить тип как различие двух других типов (исходное отношение и определение проекции). Я честно не могу думать ни о каком языке, который позволил бы Вам делать это. Типы могут быть структурно кумулятивными (A with B) с тех пор A with B структурный подтип обоих A и B. Однако, если Вы думаете об этом, операция типа A less B на самом деле был бы супертип A, вместо подтипа. Вы просите произвольное, контравариантное отношение ввода на естественно ковариантных типах. Не было даже доказано, что такая вещь звуковая с номинальными экзистенциальными типами, а тем более структурными типами места объявления.
Я работал над этим видом моделирования прежде, и маршрут, которым я следовал, был к ограничительным проекциям к одному из трех доменов: P == T, P == {F} where F in T, P == {$_1} where $_1 anonymous. Первое - то, где проекция эквивалентна входному типу, означая, что это не (SELECT *). Второе говорит, что проекция является единственным полем, содержавшим во входном типе. Третьим является хитрый. Это говорит разрешение объявления некоторого анонимного типа $_1 который не имеет никаких статических отношений к входному типу. По-видимому, это будет состоять из полей, которые делегируют к входному типу, но мы не можем осуществить это. Это - примерно стратегия, которую берет LINQ.
Извините я не мог быть более услужливым. Мне жаль, что не было возможно сделать то, что Вы спрашиваете, это открыло бы много очень аккуратных возможностей.
HaskellDB имеет некоторые идеи, как создать безопасную с точки зрения типов алгебру отношений DSL, можно найти это полезным.
Я думаю, что обосновался на просто использовании нормальных средств для отображения набора для части проекта. Клиент просто указывает функцию [T<:Tuple](t:T) => P
С некоторым обманом Java для получения до класса P я должен смочь использовать отражение для реализации логики запроса.
Для соединения я буду, вероятно, использовать DynamicProxy для реализации отображающейся функции.
В качестве награды я смог заставлять API быть применимым с Scalas, особенным для синтаксиса.
Может быть, отсюда вам что-нибудь пригодится: http://research.microsoft.com/en-us/um/people/simonpj/papers/list-comp/list-comp.pdf
показано, как добавить «группировать по» и «упорядочивать по "перечислить понимания.