[m-dev.] Aditi updates

Simon Taylor stayl at cs.mu.OZ.AU
Sat Dec 5 02:51:15 AEDT 1998


Hi,

> > :- 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?

Typo, they're meant to be output.
 
> Does the Aditi stuff in the Mercury compiler support functions?

Yes, I just ran a small test case. Functions and predicates are
basically identical by the time Aditi code generation runs anyway.

> 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.

Ok.

> 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.

Agreed. The current syntax for aggregates could use some sugar-coating
too (see /home/mercury1/stayl/mercury/test/agg.m for an example). Pred
expressions are a little heavy for this sort of thing because the modes
of the arguments are fixed so specifying them is a pain. Also, aggregate
closures have distinct groups of arguments (group-by and non group-by)
which need to be separated better than in the current syntax. I'll see
what I can come up with.

Simon.



More information about the developers mailing list