Re: [Xsb-development] Abolishing tables with conditional answers

[<gon...@gm...>]

Hi Terry,

That certainly looks like the expected and desirable behavior, and I
certainly agree with the options flag for dealing with dependencies.

This situation kind of reminds me once again of the database scenario
where you have dangling functional dependencies between tables,
meaning that if you want to drop the table, you either cascade
removals through the transitivity graph, or the system will forbid you
from dropping the table.

Both of these also make sense for XSB tables, but on DBMS' the default
is to forbid dropping tables with dangling dependencies. I understand
that the default for XSB tables should probably be abolishing
dependent tables, since that's usually the expected behavior, but
there may be someone out there who would disagree. Any default you
assume is fine, as long as you can set the handling mechanism in some
way.

Thanks for the support and best regards,

Gon=E7alo

On 5/23/07, Terrance Swift <ts...@cs...> wrote:
>
> All:
>
> With the help of a student, Dao Tran Minh, I'm exploring altering
> the behavior of the table abolish routines when the tables
> contain conditional answers.  This won't affect most users, but
> will affect those who inspect the residual program (like the UNL
> group) and possibly may affect some Flora users.
>
> Recall that conditional answers contain numerous cross table
> pointers in their delay lists and delay elements.  So if you have
> a conditional answer
>
> p(a):- q(a),r|
>
> the conditional answer information for the answer p(a) contains a
> pointer to the answer q(a) and the subgoal r, and each of these
> elements contain backpointer to the answer p(a).  The forward
> pointers are useful for introspecting the residual program, while
> the back pointers are useful for simplification.
>
> One issue we have is if abolish_table_subgoal(r) were called, the
> pointer to r in the conditional answer above would be dangling,
> and if get_residual(p(a),X) were later called, we'd get a core
> dump.  This situation has happened in the past.
>
> So a fix to this is, whenever we abolish a tabled subgoal (S) we
> transitively abolish all subgoals containing an answer that
> depends on S (or a transitively abolished subgoal) or an answer
> to S (or a transitively abolished subgoal).  Also whenever we
> abolish a tabled predicate, we abolish all tabled predicates just
> as we did tabled subgoals above.  Of course, if the subgoal, or
> predicate did not have a conditinoal answer, the behavior would
> be unchanged.
>
> My proposal is to represent the default behavior of
> abolish_table_subgoal or abolish_table_pred (and perhaps some of
> the other table abolishing routines) in a flag indicating whether
> to abolish depending tables or not, and to make the default
> behavior that of abolishing depending tables.  If needed, we
> could also put options lists into the table abolishing routines.
>
> Please let me know if you have any comments or suggestions.  If I
> don't hear anything, I'll go ahead and make my changes.
>
> Terry
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Xsb-development mailing list
> Xsb...@li...
> https://lists.sourceforge.net/lists/listinfo/xsb-development
>