Stability: [beta] Most of the functionality is there but it is still missing some testing and/or verification.
This file contains the definiteness abstract domain and abstract unctions for CLP languages.
The abstract constraint is kept as a(Ground,Set) in which:
Usage:call_to_entry(Sv,Sg,Hv,Head,K,Fv,Proj,Entry,BothEntry)
It obtains the abstract constraint (Entry) which results from adding the abstraction of the constraint Sg = Head to Proj, later projecting the resulting constraint onto Hv. This is done as follows:
Usage:exit_to_prime(Sg,Hv,Head,Sv,Exit,BothEntry,Prime)
It computes the prime abstract constraint Prime, i.e. the result of going from the abstract constraint over the head variables (Exit), to the abstract constraint over the variables in the subgoal. If Exit is $bottom, Prime will be also $bottom. Otherwise Prime is the result of projecting Exit onto Hv obtaining BPrime, then adding the information in BPrime to the BothEntry (the abstract constraint obtained during the call to entry over all variables in Sg and Head and later projecting onto Sv.
Usage:project(Sg,Vars,HvFv_u,Constr,Projected)
It projects the ordered abstract subtitution given in the first argument on the ordered list of variables Vars in the second argument. All the variables in the second argument are assumed to appear also in the abstract constraint.
Usage:project_vars(Vars1,Set,Vars2,PSet)
It will project the list of (X,SS) in Set onto Vars2 obtaining PSet. This will be done in the following way, for each (X,SS) in Set:
Usage:compute_lub(ListConstr,Lub)
It obtains the lub between all abstract constraints which are elements of the list given in the first argument. We assume that the abstract constraints are ordered and defined over the same set of variables. It will be computed recursively by obtaining the lub of 2 abstract constraints in each iteration in the following way:
Usage:glb(Constr1,Constr2,Constr)
Usage 1:abs_sort(Constr,SortedConstr)
It sorts the abstract constraint a(Ground,Set) received as first argument. In doing this it will:
Usage 2:abs_sort(Set1,Set2)
Usage:extend(Sg,Prime,Sv,Call,Succ)
It extends the information given by the new abstract constraint on the subgoal Prime (first argument) to the original information about all the clause variables which is contained in Call, obtaining Succ.
Usage:call_to_success_fact(Sg,Hv,Head,K,Sv,Call,Proj,Prime,Succ)
It obtains the prime and success constraint for a fact. However, since the program are assumed to be normilised, a fact should have all their arguments as voids, and therefore Prime = Proj, and Succ = Call.
Usage:special_builtin(SgKey,Sg,Subgoal,Type,Condvars)
The predicate succeeds if the Sgkey indicates a builtin or a constraint Type indicates the kind of builtin and Condvars contains the info needed for their abstraction.
Usage:success_builtin(Type,Sv_uns,Term,HvFv_u,Call,Succ)
By now, it is tricky since it assumes the following things:
Usage:input_user_interface(InputUser,Qv,ASub,Sg,MaybeCallASub)
It translate the query mode given by the user into the internal structure.
Usage:asub_to_native(ASub,Qv,OutFlag,ASub_user,Comps)
It translates an internal abstract constraint into something friendly for the user.
Usage:unknown_call(Sg,Vars,Call,Succ)
Gives the top value for the variables Vars involved in a literal whose definition is not present, and adds this top value to Call (it is like conjunting the information in Call with the top for a subset of variables) In the definiteness analyser, nothing needs to be done.
Usage:unknown_entry(Sg,Vars,Call)
Gives the top value for a given set of variables, resulting in the abstract constraint Call. In the definiteeness domain the top abstraction for a set of variables Vars is T = a({},{}).
Usage:empty_entry(Sg,Vars,Entry)
Usage:less_or_equal(ASub0,ASub1)
Succeeds if ASub0 = (G0,T0,R0) is less or equal than ASub1 = a(G1,T1,R1) i.e. if ASub0 is more concrete or equal than ASub1. This will be true if either ASub0 is bottom or: