[m-dev.] Aditi updates
Fergus Henderson
fjh at cs.mu.OZ.AU
Sat Dec 5 13:05:31 AEDT 1998
On 04-Dec-1998, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
>
> [Peter Schachte wrote:]
> > Why should any extra relations be generated for tables with indices?
> > Can't you use the same predicate name?
>
> It's not a matter of different code for different modes - the deletion
> predicate needs to specify which key is being used. The different deletion
> predicates for different keys may have different type signatures since
> only the key attributes are passed in.
Well, the interface could be much more high level.
For example, it could be
Syntax:
Inside a DCG:
(a) delete <relation>(<attributes>)
(b) delete <relation>(<attributes>) where <condition>
Outside of a DCG:
(a) delete(<relation>(<attributes>), <state_var>, <state_var>)
(b) delete((<relation>(<attributes>) where <condition>),
<state_var>, <state_var>)
Semantics:
(a) Deletes all matching tuples for the specified relation.
(b) Deletes all matching tuples for the specified relation
for which <condition> is true.
Examples:
delete foo(_, _, _)
Deletes all tuples for foo/3.
delete foo(bar(_), _, _)
Deletes all typles for foo/3 for which the
first argument matches `bar(_)'.
delete baz(Key1, _Key2, Data) where Key1 > 10, Data > 20.
Deletes all typles for baz/3 for which the
first argument is > 10 and for which the
third argument is > 20.
For the purpose of scope rules, type-correctness, mode-correctness, etc.
the first argument to `delete' would be treated as a lambda expression:
delete foo(<args>) where <condition>
==>
'delete foo'( (pred(<args>::in) is semidet :- <condition>) )
Implementing this so that it makes use of indices then becomes just
an optimization issue; i.e. something that the compiler can worry about,
rather than something that the user has to worry about.
--
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.
More information about the developers
mailing list