coli-saar/alto

Bug in apply set computation

Closed this issue · 1 comments

I had my doubts how we check apply reachability. Here's the case where it goes wrong:

ApplyModifyGraphAlgebra.Type t1 = new ApplyModifyGraphAlgebra.Type("(o(),s())");
ApplyModifyGraphAlgebra.Type t2 = new ApplyModifyGraphAlgebra.Type("(o(s_UNIFY_s))");
ApplyModifyGraphAlgebra.Type t3 = new ApplyModifyGraphAlgebra.Type("(x)");

System.err.println(t1); // output (s(), o())
System.err.println(t2); // output (o(s()))

System.err.println(t3.getApplySet(t1)); // output null, means there is no apply set, CORRECT

System.err.println(t2.getApplySet(t1)); // output [], means that using NO apply operation we can get from t2 to t1, WRONG!

I changed the python implementation to do this:

def get_apply_set(self, target : "AMType") -> Optional[Set[str]]:
    """
    Returns the set of source names such that if we call apply for all those
    source names on this type (self), the given type target remains. Returns None if
    no such list of source names exists.
    """
    if self.is_bot:
        if target.is_bot:
            return set()
        return None
    
    if not isinstance(target, AMType) or not target.is_compatible_with(self):
        return None
    
    #return value is all sources in this type that are not in target
    ret = set(self.nodes()) - set(target.nodes())
    
    changed = True
    term_type = self.copy()
    while changed:
        changed = False
        for o in term_type.origins & ret:
            term_type.remove_node(o)
            changed = True
            
    if term_type != target:
        return None
        
    return ret

I think, we should use a similar implementation in Java.

Is this issue still relevant? What needs to be done to close it?