[m-dev.] for review: Aditi update doc extract
Simon Taylor
stayl at cs.mu.OZ.AU
Tue Jul 6 15:50:13 AEST 1999
> > There must be a `:- pragma base_relation' declaration for any
> > relation to be updated.
> >
> > It is currently up to the application to ensure that any
> > modifications do not change the determinism of a base relation. Updates
> > of relations with unique B-tree indexes are checked to ensure that a
> > key is not given multiple values. The transaction will abort if this
> > occurs.
>
> Perhaps you should say "do not violate the declared determinism of the
> base relation" rather than "do not change the determinism ...".
OK.
> If I have a `det' base relation, does it make any sense to do insertions
> or deletions on it? Modifications make sense, but I think any insertions
> (except perhaps inserting tuples that are already present) or deletions
> will always violate the declared determinism, won't they?
Yes.
> > aditi_insert(PREDNAME(VAR1, VAR2, ...), DB0, DB).
> >
> > aditi_insert(FUNCNAME(VAR1, VAR2, ...) = RETVAR, DB0, DB).
> >
> You should state here what `PREDNAME', `FUNCNAME', `VAR1', `VAR2', ...,
> `RETVAR', `DB0', and `DB' are.
I've added a list of naming conventions to the "Aditi update notes" section.
> > Examples:
> > insert_example_1(DB0, DB) :-
> > aditi_insert(p(_, 1, 2), DB0, DB).
> >
> > insert_example_2(DB0, DB) :-
> > aditi_insert(f(_, 1) = 2, DB0, DB).
>
> The examples are inconsistent with the documentation, which implies that
> the arguments here must be variables.
I've changed `Var' to `Arg'.
> > aditi_modify(
> > ((FUNCNAME(VAR1, VAR2, ...) = RETVAR0) ==>
> > (PREDNAME(VAR3, VAR4, ...) = RETVAR) :-
> > GOAL
> > ),
>
> Shouldn't `PREDNAME' here be `FUNCNAME'?
Yes.
> Also, I suggest using the names
> OLDVAR1, OLDVAR2, ..., OLDRETVAR, NEWVAR1, NEWVAR2, ..., NEWRETVAR.
> or
> OLDARG1, OLDARG2, ..., OLDRETVAL, NEWARG1, NEWARG2, ..., NEWRETVAL.
Done.
Thanks,
Simon.
File: mercury_ref.info, Node: Aditi update syntax, Next: Aditi glossary, Prev: Aditi pragma declarations, Up: Aditi deductive database interface
Aditi update syntax
@@ -37,12 +543,36 @@
relation to be updated.
It is currently up to the application to ensure that any
-modifications do not change the determinism of a base relation. Updates
-of relations with unique B-tree indexes are checked to ensure that a
-key is not given multiple values. The transaction will abort if this
-occurs.
+modifications do not violate the determinism of a base relation.
+Updates of relations with unique B-tree indexes are checked to ensure
+that a key is not given multiple values. The transaction will abort if
+this occurs.
+
+ The following naming conventions are used in the specification of
+the Aditi update syntax:
+ * `PREDNAME' is the name of a predicate.
+
+ * `FUNCNAME' is the name of a function.
+
+ * `NAME' is the name of a predicate or a function.
+
+ * `PREDORFUNC' is either `pred' or `func', depending on whether a
+ predicate or function is being updated.
+
+ * `ARITY' is the arity of the predicate or function being updated.
+
+ * `GOAL' is any Mercury goal.
+
+ * `CLOSURE' is a term which has a higher-order type.
- The examples make use of the following declarations.
+ * Variables named `DBN' are `aditi__state' variables. When occuring
+ as a pair at the end of an argument list, they have mode
+ `aditi_di, aditi_uo'.
+
+ Predicate and function names in Aditi update goals may be module
+qualified.
+
+ The examples make use of the following declarations:
:- pred p(aditi__state::aditi_ui, int::out, int::out) is nondet.
:- pragma base_relation(p/3).
@@ -52,26 +582,19 @@
:- pred ancestor(aditi__state::aditi_ui, int::out, int::out) is nondet.
:- pragma aditi(ancestor/3).
- Variables named `DBN' are `aditi__state' variables. When occuring as
-a pair at the end of an argument list, they have mode
-`aditi_di, aditi_uo'.
-
- Predicate and function names in Aditi update goals may be module
-qualified.
-
Insertion
.........
- aditi_insert(PREDNAME(VAR1, VAR2, ...), DB0, DB).
+ aditi_insert(PREDNAME(ARG1, ARG2, ...), DB0, DB).
- aditi_insert(FUNCNAME(VAR1, VAR2, ...) = RETVAR, DB0, DB).
+ aditi_insert(FUNCNAME(ARG1, ARG2, ...) = RETVAL, DB0, DB).
Insert the specified tuple into a relation. The tuple to be inserted
must have the same type signature as the relation. All the arguments of
the tuple have mode `in', except the `aditi__state' argument which has
mode `unused'.
- Note that `PREDNAME(VAR1, VAR2, ...)' in a call to `aditi_insert' is
+ Note that `PREDNAME(ARG1, ARG2, ...)' in an `aditi_insert' goal is
not a higher-order term.
`Pred = p(DB0, X, Y), aditi_insert(Pred, DB0, DB)' is a syntax error.
@@ -85,18 +608,15 @@
Deletion
........
- aditi_delete((PREDNAME(VAR1, VAR2, ...) :- GOAL), DB0, DB).
+ aditi_delete((PREDNAME(ARG1, ARG2, ...) :- GOAL), DB0, DB).
- aditi_delete((FUNCNAME(VAR1, VAR2, ...) = RETVAR :- GOAL), DB0, DB).
+ aditi_delete((FUNCNAME(ARG1, ARG2, ...) = RETVAL :- GOAL), DB0, DB).
aditi_delete(PREDORFUNC NAME/ARITY, CLOSURE, DB0, DB).
Delete all tuples for which `GOAL' or `CLOSURE' succeeds from the
named base relation.
- For the third alternative `PREDORFUNC' must be either `pred' or
-`func'.
-
When deleting from a predicate with type declaration
`:- pred p(aditi__state, TYPE1, ...)', `CLOSURE' must have type
`aditi_top_down pred(aditi__state, TYPE1, ...)', and inst
@@ -141,7 +661,7 @@
aditi_delete(func f/2, DeleteQ, DB0, DB).
delete_example_5 -->
- aditi_delete((p(_, X, Y) :- X = 2, Y = 2)).
+ aditi_delete((p(_, X, Y) :- X = 2, Y = 2)).
The type of `DeleteP' is
`aditi_top_down pred(aditi__state, int, int)'. Its inst is
@@ -149,10 +669,8 @@
Note that in `delete_example_5' the extra set of parentheses around
the goal are needed, otherwise the second goal in the conjunction in
-the deletion goal is parsed as an argument of the `aditi_delete' call.
-This behaviour is inconsistent with ISO Prolog syntax. An ISO Prolog
-implementation would report a syntax error without the extra set of
-parentheses.
+the deletion goal would be parsed as an extra argument of the
+`aditi_delete' call, resulting in a syntax error.
Bulk insertion
..............
@@ -160,15 +678,13 @@
aditi_bulk_insert(PREDORFUNC NAME/ARITY, CLOSURE, DB0, DB).
Insert all solutions of `CLOSURE' into the named relation.
-`PREDORFUNC' must be either `pred' or `func'.
- The closure for producing the tuples to insert must have the same
-type signature as the base relation, with all arguments except the
-`aditi__state' output. It must also be evaluable bottom-up by the Aditi
-system. This means the predicate passed must have a
-`:- pragma aditi(...)' declaration. Lambda expressions can be marked as
-evaluable by Aditi using an `aditi_bottom_up' annotation on the lambda
-expression.
+ `CLOSURE' must have the same type signature as the base relation to
+be inserted into, with all arguments except the `aditi__state' output.
+It must also be evaluable bottom-up by the Aditi system -- the
+predicate or function passed must have a `:- pragma aditi' declaration.
+Lambda expressions can be marked as evaluable by Aditi using an
+`aditi_bottom_up' annotation on the lambda expression.
Examples:
bulk_insert_example_1(DB0, DB) :-
@@ -198,7 +714,6 @@
aditi_bulk_delete(PREDORFUNC NAME/ARITY, CLOSURE, DB0, DB).
Delete all solutions of `CLOSURE' from the named relation.
-`PREDORFUNC' must be either `pred' or `func'.
The restrictions on the closure passed to `aditi_bulk_insert' also
apply to `aditi_bulk_delete'.
@@ -207,14 +722,15 @@
............
aditi_modify(
- (PREDNAME(VAR1, VAR2, ...) ==> PREDNAME(VAR3, VAR4, ...) :-
+ (PREDNAME(OLDARG1, OLDARG2, ...) ==>
+ PREDNAME(NEWARG1, NEWARG2, ...) :-
GOAL
),
DB0, DB).
aditi_modify(
- ((FUNCNAME(VAR1, VAR2, ...) = RETVAR0) ==>
- (PREDNAME(VAR3, VAR4, ...) = RETVAR) :-
+ ((FUNCNAME(OLDARG1, OLDARG2, ...) = OLDRETVAL) ==>
+ (FUNCNAME(NEWARG1, NEWARG2, ...) = NEWRETVAL) :-
GOAL
),
DB0, DB).
@@ -226,9 +742,6 @@
tuple is given by the first set of arguments, the updated tuple is
given by the second set.
- For the third alternative `PREDORFUNC' must be either `pred' or
-`func'.
-
When modifying a predicate with type declaration
`:- pred p(aditi__state, TYPE1, ...)', `CLOSURE' must have type
`aditi_top_down pred(aditi__state, TYPE1, ..., aditi__state, TYPE1,
@@ -282,11 +795,181 @@
Note that in `modify_example_5' the extra set of parentheses around
the goal are needed, otherwise the second and third goals in the
-conjunction in the modification goal are parsed as arguments of the
-`aditi_modify' call. This behaviour is inconsistent with ISO Prolog
-syntax. An ISO Prolog implementation would report a syntax error
-without the extra set of parentheses.
+conjunction in the modification goal would be parsed as extra arguments
+of the `aditi_modify' call, resulting in a syntax error.
--- reference_manual.texi 1999/07/05 02:00:43 1.6
+++ reference_manual.texi 1999/07/06 05:44:15
@@ -5023,13 +5341,13 @@
be stratified (@pxref{Aditi glossary}) and must not be mutually recursive
with predicates in other modules.
-Every predicate with a @samp{:- pragma aditi(...)} or
- at samp{:- pragma base_relation(...)} declaration must have an input
+Every predicate with a @samp{:- pragma aditi} or
+ at samp{:- pragma base_relation} declaration must have an input
argument of type @samp{aditi__state}. This ensures that Aditi predicates
are only called from within transactions and that updates and database
calls are ordered correctly, in the same way that @samp{io__state} arguments
are used to ensure ordering of I/O operations. Within the clauses for
-predicates with a @samp{:- pragma aditi(...)} declaration variables with
+predicates with a @samp{:- pragma aditi} declaration variables with
type @samp{aditi__state} may only be passed to other database predicates --
they may not be packaged into terms or passed to top-down Mercury predicates.
This allows the compiler to remove all instances of @samp{aditi__state}
@@ -5098,7 +5416,7 @@
The predicate is owned by the named user. A predicate in the database
is identified by owner, module name, predicate name and arity. The owner
-field is used for security checks. If no @samp{:- pragma owner(...)}
+field is used for security checks. If no @samp{:- pragma owner}
declaration is given, the owner is taken from the @samp{--aditi-user}
option, which defaults to the value of the environment variable @samp{USER},
or ``guest'' if that is not set.
@@ -5145,11 +5463,46 @@
any relation to be updated.
It is currently up to the application to ensure that any modifications
-do not change the determinism of a base relation. Updates of relations
+do not violate the determinism of a base relation. Updates of relations
with unique B-tree indexes are checked to ensure that a key is not
given multiple values. The transaction will abort if this occurs.
-The examples make use of the following declarations.
+The following naming conventions are used in the specification
+of the Aditi update syntax:
+ at itemize @bullet
+ at item
+ at samp{@var{PredName}} is the name of a predicate.
+
+ at item
+ at samp{@var{FuncName}} is the name of a function.
+
+ at item
+ at samp{@var{Name}} is the name of a predicate or a function.
+
+ at item
+ at samp{@var{PredOrFunc}} is either @samp{pred} or @samp{func},
+depending on whether a predicate or function is being updated.
+
+ at item
+ at samp{@var{Arity}} is the arity of the predicate or function
+being updated.
+
+ at item
+ at samp{@var{Goal}} is any Mercury goal.
+
+ at item
+ at samp{@var{Closure}} is a term which has a higher-order type.
+
+ at item
+Variables named @samp{DB at var{N}} are @samp{aditi__state} variables.
+When occuring as a pair at the end of an argument list, they have
+mode @w{@samp{aditi_di, aditi_uo}}.
+
+ at end itemize
+
+Predicate and function names in Aditi update goals may be module qualified.
+
+The examples make use of the following declarations:
@example
:- pred p(aditi__state::aditi_ui, int::out, int::out) is nondet.
:- pragma base_relation(p/3).
@@ -5161,19 +5514,13 @@
:- pragma aditi(ancestor/3).
@end example
-Variables named @samp{DB at var{N}} are
- at samp{aditi__state} variables. When occuring as a pair at the end
-of an argument list, they have mode @w{@samp{aditi_di, aditi_uo}}.
-
-Predicate and function names in Aditi update goals may be module qualified.
-
@c @node Insertion
@subsubheading Insertion
@example
-aditi_insert(@var{PredName}(@var{Var1}, @var{Var2}, @dots{}), @var{DB0}, @var{DB}).
+aditi_insert(@var{PredName}(@var{Arg1}, @var{Arg2}, @dots{}), @var{DB0}, @var{DB}).
-aditi_insert(@var{FuncName}(@var{Var1}, @var{Var2}, @dots{}) = @var{RetVar}, @var{DB0}, @var{DB}).
+aditi_insert(@var{FuncName}(@var{Arg1}, @var{Arg2}, @dots{}) = @var{RetVal}, @var{DB0}, @var{DB}).
@end example
Insert the specified tuple into a relation. The tuple to be inserted
@@ -5181,8 +5528,8 @@
of the tuple have mode @samp{in}, except the @samp{aditi__state} argument
which has mode @samp{unused}.
-Note that @w{@samp{@var{PredName}(@var{Var1}, @var{Var2}, @dots{})}}
-in a call to @samp{aditi_insert} is not a higher-order term.
+Note that @w{@samp{@var{PredName}(@var{Arg1}, @var{Arg2}, @dots{})}}
+in an @samp{aditi_insert} goal is not a higher-order term.
@w{@samp{Pred = p(DB0, X, Y), aditi_insert(Pred, DB0, DB)}}
is a syntax error.
@@ -5199,9 +5546,9 @@
@subsubheading Deletion
@example
-aditi_delete((@var{PredName}(@var{Var1}, @var{Var2}, @dots{}) :- @var{Goal}), @var{DB0}, @var{DB}).
+aditi_delete((@var{PredName}(@var{Arg1}, @var{Arg2}, @dots{}) :- @var{Goal}), @var{DB0}, @var{DB}).
-aditi_delete((@var{FuncName}(@var{Var1}, @var{Var2}, @dots{}) = @var{RetVar} :- @var{Goal}), @var{DB0}, @var{DB}).
+aditi_delete((@var{FuncName}(@var{Arg1}, @var{Arg2}, @dots{}) = @var{RetVal} :- @var{Goal}), @var{DB0}, @var{DB}).
aditi_delete(@var{PredOrFunc} @var{Name}/@var{Arity}, @var{Closure}, @var{DB0}, @var{DB}).
@end example
@@ -5209,9 +5556,6 @@
Delete all tuples for which @samp{@var{Goal}} or @samp{@var{Closure}}
succeeds from the named base relation.
-For the third alternative @samp{@var{PredOrFunc}} must be either
- at samp{pred} or @samp{func}.
-
When deleting from a predicate with type declaration
@w{@samp{:- pred p(aditi__state, @var{Type1}, @dots{})}},
@samp{@var{Closure}} must have type
@@ -5260,8 +5604,8 @@
aditi_delete(func f/2, DeleteQ, DB0, DB).
delete_example_5 -->
- aditi_delete((p(_, X, Y) :- X = 2, Y = 2)).
-
+ aditi_delete((p(_, X, Y) :- X = 2, Y = 2)).
+
@end example
The type of @samp{DeleteP} is
@@ -5271,10 +5615,8 @@
Note that in @samp{delete_example_5} the extra set of parentheses around
the goal are needed, otherwise the second goal in the conjunction
-in the deletion goal is parsed as an argument of the `aditi_delete' call.
-This behaviour is inconsistent with ISO Prolog syntax. An ISO Prolog
-implementation would report a syntax error without the extra set of
-parentheses.
+in the deletion goal would be parsed as an extra argument of the
+`aditi_delete' call, resulting in a syntax error.
@c @node Bulk insertion
@subsubheading Bulk insertion
@@ -5284,15 +5626,13 @@
@end example
Insert all solutions of @samp{@var{Closure}} into the named relation.
- at samp{@var{PredOrFunc}} must be either @samp{pred} or @samp{func}.
-The closure for producing the tuples to insert must have the same
-type signature as the base relation, with all arguments except
-the @samp{aditi__state} output. It must also be evaluable bottom-up
-by the Aditi system. This means the predicate passed must have a
- at w{@samp{:- pragma aditi(@dots{})}} declaration. Lambda expressions can
-be marked as evaluable by Aditi using an @samp{aditi_bottom_up} annotation
-on the lambda expression.
+ at samp{@var{Closure}} must have the same type signature as the base relation to
+be inserted into, with all arguments except the @samp{aditi__state} output.
+It must also be evaluable bottom-up by the Aditi system --- the predicate or
+function passed must have a @w{@samp{:- pragma aditi}} declaration.
+Lambda expressions can be marked as evaluable by Aditi using an
+ at samp{aditi_bottom_up} annotation on the lambda expression.
Examples:
@example
@@ -5327,7 +5667,6 @@
@end example
Delete all solutions of @samp{@var{Closure}} from the named relation.
- at samp{@var{PredOrFunc}} must be either @samp{pred} or @samp{func}.
The restrictions on the closure passed to @samp{aditi_bulk_insert} also
apply to @samp{aditi_bulk_delete}.
@@ -5337,14 +5676,15 @@
@example
aditi_modify(
- (@var{PredName}(@var{Var1}, @var{Var2}, @dots{}) ==> @var{Predname}(@var{Var3}, @var{Var4}, @dots{}) :-
+ (@var{PredName}(@var{OldArg1}, @var{OldArg2}, @dots{}) ==>
+ @var{PredName}(@var{NewArg1}, @var{NewArg2}, @dots{}) :-
@var{Goal}
),
@var{DB0}, @var{DB}).
aditi_modify(
- ((@var{FuncName}(@var{Var1}, @var{Var2}, @dots{}) = @var{RetVar0}) ==>
- (@var{Predname}(@var{Var3}, @var{Var4}, @dots{}) = @var{RetVar}) :-
+ ((@var{FuncName}(@var{OldArg1}, @var{OldArg2}, @dots{}) = @var{OldRetVal}) ==>
+ (@var{FuncName}(@var{NewArg1}, @var{NewArg2}, @dots{}) = @var{NewRetVal}) :-
@var{Goal}
),
@var{DB0}, @var{DB}).
@@ -5358,9 +5698,6 @@
The original tuple is given by the first set of arguments, the
updated tuple is given by the second set.
-For the third alternative @samp{@var{PredOrFunc}} must be either @samp{pred}
-or @samp{func}.
-
When modifying a predicate with type declaration
@w{@samp{:- pred p(aditi__state, @var{Type1}, @dots{})}}, @samp{@var{Closure}}
must have type
@@ -5419,10 +5756,8 @@
Note that in @samp{modify_example_5} the extra set of parentheses around
the goal are needed, otherwise the second and third goals in
-the conjunction in the modification goal are parsed as arguments
-of the `aditi_modify' call. This behaviour is inconsistent with
-ISO Prolog syntax. An ISO Prolog implementation would report a
-syntax error without the extra set of parentheses.
+the conjunction in the modification goal would be parsed as extra arguments
+of the `aditi_modify' call, resulting in a syntax error.
@node Aditi glossary
@subsubsection Aditi glossary
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to: mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions: mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------
More information about the developers
mailing list