[m-dev.] Aditi updates

[Fergus Henderson]

On 04-Dec-1998, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> I'm looking at adding Aditi updates to the compiler, and there's
> a few things I want to run past the group.
> 
> 'Database transactions in a purely declarative logic programming language'
> (tech report 96/45) gives the interface for update predicates.
> 
> For example, for a base relation with declaration:
> :- pred edge(aditi:state::ui, int::out, int::out) is nondet.
> :- pragma base_relation(edge/3).
> 
> the compiler automatically defines:
> 
> :- pred edge_insert(int::in, int::in,
> 		aditi__state::di, aditi__state::uo) is det.
> 
> :- pred edge_delete(int::in, int::in,
> 		aditi__state::di, aditi__state::uo) is det.

Having the compiler automatically define predicates with special names
like this is not as elegant as one might hope for.  But I guess it
would do the job.

> :- pred edge_bulk_insert(pred(int::in, int::in, aditi__state::ui) is nondet, 
> 		aditi__state::di, aditi__state::uo) is det.
>
> :- pred edge_bulk_delete(pred(int::in, int::in, aditi__state::ui) is nondet, 
> 		aditi__state::di, aditi__state::uo) is det.

They look wrong to me.  What's the intended semantics of these predicates?
What's the intended semantics of their higher-order argument? 
How can the higher-order argument be nondet if its arguments are all input?

> 1) Handling of the input query for the bulk insert and delete operations.
> -------------------------------------------------------------------------
> 
> This must be executed bottom-up on the Aditi side of the connection.
> The closure must be compiled to Aditi-RL bytecode.
> 
> The way I propose to handle this is to add a new higher-order predicate type
> `aditi_query/N'. The differences from normal `pred/N' types are:

Does the Aditi stuff in the Mercury compiler support functions?
If not, then it probably ought to.
If/when it does, it should probably support higher-order functions too.
I think the type should thus be named `aditi_pred' or `aditi pred'
(with `aditi' as a prefix operator) rather than `aditi_query',
so that you can have `aditi_func' or `aditi func' for functions.

Internally, the difference should be represented as a new field,
a bit like the is_func_or_pred field, in the representation of
higher-order types.  This field could be named the "calling convention"
and could have the values `aditi' or `mercury' (other calling conventions
may be possible in future, e.g. for bytecode).

> 2) Specification of primary keys for deletion/modification.
> -------------------------------------------------------------------------
> 
> Some of the Aditi documentation suggests doing this by adding
> semidet/det modes for base relations.
> For example 
> :- pred edge(aditi__state::ui, int::in, int::out) is semidet.
> 
> The deletion/modification operations would specify which key to use by
> listing the input attributes after the predicate name, separated by
> underscores as for edge_delete_1 above. This could cause problems with
> name clashes.
>
> 3) Specification of modification closures.
> -------------------------------------------------------------------------
> 
> A modification closure takes the primary key and non-primary key attributes
> and returns new non-primary key attributes. The closure is executed top-down. 
> 
> The closure is split into two parts for execution by Aditi.
...
> For this, I propose adding another higher-order predicate type
> `aditi_update/N'. The representation would contain the owner and module name
> and expression numbers of both the index and update parts of the update
> closure stored in the RL code in the database. Only predicates with a
> `:- pragma aditi_update(...)' declaration may have their address taken
> in this way.

I think that maybe there should be special syntax for insertions,
deletions, and updates, which hides all the automatically-generated
predicate names ("edge_insert", "edge_insert_1", etc.),
and which hides the aditi_update type.  What you describe sounds
like a fine way to implement these things, but I think it would be
nicer if the user interface for this stuff was a bit more high level.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh at 128.250.37.3        |     -- leaked Microsoft memo.