Feature request: objectives of nested rules

[martin-danhier]

Hello,

While I'm at it, I will also address one last issue i had while implementing Sigh.
It's not really a bug, more like a feature request concerning nested rules.

I often had to use nested rules in my implementations.

For example in binary expressions:

// Find the types of operands
R.rule()
    .using(node.left.attr("type"), node.right.attr("type"))
    .by(r -> {
        // Retrieve their declarations
        DeclarationNode leftDecl  = ((Type) r.get(0)).decl();
        DeclarationNode rightDecl = ((Type) r.get(1)).decl();

        // Retrieve their scopes
        R.rule()
            .using(leftDecl.attr("scope"), rightDecl.attr("scope"))
            .by(r2 -> {
                Scope leftScope  = r2.get(0);
                Scope rightScope = r2.get(1);

                // Lookup the operator in the scopes
                FunOverrideList leftOverloads  = leftScope .lookupLocalFun(node.operator.toString());
                FunOverrideList rightOverloads = rightScope.lookupLocalFun(node.operator.toString());

                // Get dependencies (types of all functions in both overload lists)
                // [...]

                // Get the types of the dependencies
                R.rule(node.attr("opType"), node.attr("type"))
                    .using(dependencies)
                    .by(r -> {
                        // Check overloads to find one that matches the types of the arguments
                        // [...]

                        // Only then, we can set the type of the binary operation
                        r.set(0, funType);
                        r.set(1, funType.getReturnType());
                    });
            });
    });

Here, the first two rules are declared without any exports because they don't set any attribute. Trying to add an attribute in the rule() call will create an error because the attributes are not actually set in the rule itself, which only creates a new rule for later.
Thus, only the third one knows it wants to compute the type of the operation.

However, if one of the dependencies of the first rules cannot be provided, for example the type of one of the operands, Uranium will report a missing attribute error because it doesn't know that the rule aims to compute that particular attribute.

For example:

return 5 + x

Would return two errors:

1. Could not resolve 'x'
2. missing attribute (BinaryExpression(5 + x) :: type)

The way to prevent this would be to add the binary expression in the errorFor call that reports the resolution error on x. However, this requires each node to take its parents into account when reporting an error, which is not ideal.

Would it be possible to add a new feature to Uranium that adds the ability to "tell" a rule that an attribute will be computed by a nested rule ? This way, when the type attribute is missing on the operand, it won't report an error on the operation since it knows that it requires the operand to be computed.

R.rule()
    .using(node.left.attr("type"), node.right.attr("type"))
    .objective(node.attr("type"))
    .by(r -> {
        // [...] Nested rules
    })

Please note that if you agree with the idea of such a feature, I would be glad to help implementing it.

Thank you for your time,

Martin Danhier

[norswap]

There's something about the premise of this I don't get: if you don't derive an attribute that you need somewhere else, that's an error right? So it seems like it's working as intended. It doesn't matter which rule failed to fire to supply it, in the end it's still missing.

In fact, if I remember correctly (but it's been a long time), errors for missing attributes are only computed at the very end, when the reactor is "stuck" with no rules that it can execute.

Am I misunderstanding you somewhere?

Or maybe your point is about better tracing the cause of the error? Normally Uranium should be able to chain errors to link missing attributes with the rules that failed to fire and could have provided them. But in your 5 + x example, the inner rules are never even enqueued, hence Uranium does not know that that's why the attribute wasn't computed. If that's your point, then I get it, and I do think it could make sense to specify attributes computed by nested rules as a way to ease debugging.

[martin-danhier]

Hello, thank you for your answer.

In simple cases, if a rule that exports something cannot run because of missing dependencies, Uranium will not trigger a missing attribute error on that export because it is normal that it couldn't get it:

private void parenthesized(ParenthesizedNode node) {
    R.rule(node, "type")
        .using(node.expression, "type")
        .by(Rule::copyFirst);
}

For example, with the above code and the input (x) where x couldn't be resolved, no error is produced for the parenthesized expression because Uranium knows that the reason is the lack of the dependency.

To do this, when no rule is solvable anymore, the reactor currently saves the untriggered exports in a set, and will not throw semantic errors for them:

List<Rule> untriggeredRules = dependencies.values().stream()
    .flatMap(Collection::stream)
    .filter(rule -> rule.unsatisfied > 0) // haven't run
    .filter(rule -> Arrays.stream(rule.dependencies)
        // exclude rules with error as dependencies
        .noneMatch(dep -> attributes.get(dep) instanceof SemanticError))
    .collect(Collectors.toList());

Set<Attribute> untriggeredExports = untriggeredRules.stream()
    .flatMap(rule -> Arrays.stream(rule.exports))
    .collect(Collectors.toSet());

untriggeredRules.stream()
    .flatMap(rule -> Arrays.stream(rule.dependencies))
    // get missing dependencies that cannot be obtained indirectly via an untriggered rule
    .filter(dep -> attributes.get(dep) == null && !untriggeredExports.contains(dep))
    .forEach(dep -> setValue(dep,
        new SemanticError("missing attribute " + dep, null, dep.node)));

However, this does not work for nested rules. For example, let's imagine that for some reason, we now need to fetch the scope of the declaration of the type of the value:

private void parenthesized(ParenthesizedNode node) {
    R.rule()
        .using(node.expression, "type")
        .by(r -> {
            Type type = r.get(0);
            
            R.rule(node, "type")
                .using(type.decl(), "scope"))
                .by(/* ... */)
        });
}

Here, if the type of the child is missing, since there is no export in the first level rule, the type of the parenthesized expression will not be added in the untriggeredExports set, and a missing attribute: ParenthesizedNode :: type will be created.

With the feature I suggest, the "objective attribute" could be added in the untriggeredExports set even if it is not derived instantly in the rule but later, for instance by a nested rule.

[norswap]

Re-reading this, I agree it would be great to have this.

We could make it a clause like using. I'm tinking of shadows(Attribute...) meaning that if the rule doesn't execute, it "shadows" (hides) the computation of the specified attributes.

Don't have the bandwidth to implement it right now though!