Self-explaining and Self-arguing Software

[AdamSobieski]

Introduction

I would like to present, for discussion, some ideas involving source code transformations which output resultant methods which explain or argue for their provided results.

Following upon the successes of generators (yield return) and asynchronous programming (async/await), each of these language features involving source-code transformations and introduced keywords with which to make intuitive their utilizations, I present here that self-explaining, self-arguing software algorithms could be enabled by next-generation C# language enhancements.

Self-explaining and Self-arguing Software

While it would be intricate to do so, developers could manually design algorithms which construct explanations or arguments for their output return values. Perhaps such methods would return data structures resembling:

[Serializable]
[DebuggerTypeProxy(typeof(...))]
public sealed class ExplainedResult<T>
{
    public T Value { get; }
    public ICollection<IExplanation> Explanations { get; } 
}

or

[Serializable]
[DebuggerTypeProxy(typeof(...))]
public sealed class JustifiedResult<T>
{
    public T Value { get; }
    public ICollection<IJustification> Justifications { get; } 
}

or

[Serializable]
[DebuggerTypeProxy(typeof(...))]
public sealed class ExplainedResult<T>
{
    public T Result { get; }
    public MethodCallExpression Expression { get; }
    public ICollection<IExplanation> Explanations { get; } 
}

or other data structures to be determined.

While it is non-trivial to formalize “what is an explanation” or “what is an argument or justification”, we can theorize that supporting data structures would likely be recursive, tree-like or graph-like. That is, interfaces like IExplanation or IJustification, as sketched above, would probably make use of those same interfaces for substructures. In these regards, consider that an informal argument has one or more claims, and that these can each be supported and/or opposed by other claims which each, recursively, are interrelated to yet other claims.

As it is often the case that routines invoke subroutines, we can envision that explanations or arguments would often be procedurally constructed from explained or argued results returned by subroutines. That is, routines might collect (and potentially analyze) the explained or argued results from subroutines and assemble these into output return values.

While it is possible for developers to manually create such algorithms, it is argued, here, that developers would prefer to use new language features, e.g., keywords and to allow compilers to perform source-code transformations from simpler, more readable source code, into the more intricate self-explaining, self-arguing, source code.

Developer Access to and Utilization of Features

While static and runtime compiler-based transformations are desired for developer convenience, developers should also be able to access and utilize at least some of the functionalities utilized by the compiler and by compiler-generated source code, e.g., for AI-related software components which make explainable or justified decisions, explainable artificial intelligence.

Static Methods

A suite of static methods could be utilized by compiler-generated source code and could be accessed and utilized manually, by developers. For example:

public static class Explanation
{
    ...
    public static ExplainedResult<TResult> Invoke<T, TResult>(Func<T, TResult> method, T arg) { ... }
    ...
}

Proxy Types and Methods

Proxy types or methods could be created and specified by compilers and, perhaps, manually by developers.

public class foo
{
    [ExplainabilityProxy(typeof(OtherType), "MethodName")]
    public int baz(int x, int y)
    {
        ...
    }
}

Remote Procedure Calls

Data structures for self-explaining and self-arguing source code could be utilized by the interfaces of remote procedures or services. As envisioned, algorithms would be able to seamlessly interweave results from local and remote procedures while constructing their outputs.

Open Questions

These ideas are relatively new and there are many open questions including, but not limited to:

1. What would the requirements be for such explanation-related or argumentation-related models?
2. What about methods with ref or out parameters; would these, like the return values of methods, be replaced with ExplainedResult<>?
3. What about enumerable outputs; when would the transformed return value be an explained enumerable and when would it be an enumerable of explained items?
4. How would language-enhanced explainable or arguable computation interoperate with yet other features like generators and asynchronous programming?
5. Might these features under discussion be enhanced by new metadata attributes for methods, e.g., [Pure] or [Deterministic]?
6. Might these features under discussion be enhanced by yet other language features, e.g., the capability to use metadata attributes inline on expressions and statements in methods, e.g., upon if/then expressions or for loops?
7. How would these ideas, self-explaining or self-arguing source code, extend upon and interoperate with other features in the .NET ecosystem, e.g., those in the System.Diagnostics space?

Conclusion

Thank you. I am hoping to build on these preliminary ideas with your comments and feedback towards providing a fuller proposal.

[CyrusNajmabadi]

What are the definitions of IExplanation and IJustification?

[AdamSobieski]

@CyrusNajmabadi, those data-structure sketches are intended to stir the imagination. I am still exploring the requirements for them and sketching what, for that approach, IJustification and IExplanation might specifically resemble.

With respect to other approaches, it could be that there should be multiple interoperating types in a tree-based model. The above data structures might correspond to but one type of node, e.g., MethodCallExplanation, where multiple types of nodes would be constructed and utilized together, in compiler-generated code, forming tree-like explanations and arguments.

I am also thinking about whether and how semantics, e.g., URI-based or predicate-calculus-based, might fit into models, e.g., extensible tree-based models, of explanation and argument pertaining to the results of computations.

[CyrusNajmabadi]

those data-structure sketches are intended to stir the imagination.

But there's no use case to even stimulate the imagination. So, as per your other thread, I have the same question if: why not just do this with Roslyn analysis.

All if this already seems possible. So if you're arguing/suggesting that this is something to invest design time into, then it would be good to at least have some reason given to motivate that position.

[CyrusNajmabadi]

, where multiple types of nodes would be constructed and utilized together, in compiler-generated code,

What does it mean to be "utilized together, in compiler-generated code, "?

[AdamSobieski]

I meant how LINQ or Roslyn nodes are constructed, typed nodes utilized as arguments when constructing nodes.

[CyrusNajmabadi]

What would this be used for? Can you give an example of how you would use such an explanation or justification?

Can you give a sketch if what these would even contain? It's hard to exercise the imagination when absolutely nothing is provided. It's equivalent to saying that it would be great to at a Foo and Bar feature without saying at all what those are. There's just nothing to go off of.

[CyrusNajmabadi]

This discussion seems to lack an example of what you would use this for. When would you want this? What would it be valuable for?

[AdamSobieski]

what does that do?

Explained<T> and Argued<T> are two different topics, in these regards.

With Explained<T>, I'm still thinking about the best answer to that question. The hypothetical usage that seemed the most popular in the discussion, thus far, involved debugging. So, including while debugging, developers would be able to view a variable and get at: "Why (or how) is the result or value what it is?".

With Argued<T>, it would get at: "Is the result or value (provably) correct? Can the result or value be verified and validated?" (by a human or an argument-processing component).

I will put some thought into encapsulation in these regards. I am interested in enabling developers to be able to choose when to use explanation and argumentation in and across components, applications, and systems. My initial thoughts are that, with keyword-based or metadata-based approaches to opting into or out of these features, developers should be able to express intent with respect to methods on interfaces and classes.

Some relevant Wikipedia articles:

• Explanation § Explanations vs. Arguments
• Explanation § Explanation vs. Justification
• Argumentation theory
• Justification

[CyrusNajmabadi]

developers would be able to view a variable and get at: "Why (or how) is the result or value what it is?".

Why would this need a language feature though? Isn't this what time-travel-debugging does?

I am interested in enabling developers to be able to choose when to use explanation and argumentation in and across components, applications, and systems.

Honestly, this seems entirely outside of .net. You might want to just consider looking into proof systems and whatnot.

[Clockwork-Muse]

The hypothetical usage that seemed the most popular in the discussion, thus far, involved debugging.

If your intended use-case for debugging involves changing the signature of your code, that's a misfeature. The whole point of debugging is that you're working with the code you already have.

Further, that's not a use you originally suggested.

Argued<T>

1. This is the first time you're bringing this class up.
2. The description suggests code contracts, but...
3. Generally this kind of information isn't valuable as a return type, but instead during writing/compiling/jitting. If it is, you're (most likely) writing some sort of dynamic-code application, and your actual needs will be application/domain specific. These are rare applications, and especially in the larger code-contracts sense, usually research projects.

[AdamSobieski]

1. This is the first time you're bringing this class up.

With respect to Argued<T>, the claims that are argued for or against in such objects can be phrased as being expressions which can be evaluated to Boolean values. These expressions could be constructed using either the LINQ expressions or Roslyn model.

For instance, x == 123 or f(100, 23) == 123 could be claims, or, for some logic-programming cases (and capturing other runtime objects into the expressions), statements.Contains(expr(x == 123)) or statements.Contains(expr(f(100, 23) == 123)) could be claims, where statements could be intended to be, beyond some arbitrary set of expressions or predicate-calculus statements, a set of true expressions or predicate-calculus statements.

As presently envisioned, Argued<T> also would involve the "(parts of) code as extra data" approach.

2. The description suggests code contracts, but...

I will take a look at code contracts and Roslyn.

Hopefully, self-explaining and self-arguing software will pan out to have a general usefulness beyond the realms of logic programming and proof systems. Any interested others are welcome to explore these topics. I'll also be developing models of explanation and argumentation for these scenarios. I see which subtopics to shore up for a next version of proposal/discussion.

[AdamSobieski]

Quick update: a better sketch is forming here.

It appears that it is possible, using ICSharpCode.Decompiler and Microsoft.CodeAnalysis.CSharp, to implement a runtime decompiler and compiler combination with which to transform methods at runtime. So, prototyping these features for developers to explore doesn’t need any language or runtime features.

Prototypes for developers to explore these features could use extension methods on methods and delegates:

public partial static class Explainable
{
    public static Func<T1, T2, Explained<TResult>> ToExplainable<T1, T2, TResult>(this Func<T1, T2, TResult> method) { ... }
}

The questions that I’m still thinking about are: what are the applications of these technologies and what uses might developers find, beyond debugging, for accessing previously development-related, compiler-related, JIT-related, analyses of methods placed as explanations on the outputs of transformed methods.

As forming in the sketch here, Roslyn analyses of methods will be utilized, directly or indirectly, to produce the explanations on the Explained<T> data structures. As envisioned, each return statement, yield statement, and throw statement in the input methods would have a causal explanation. It may be the case that what I’m referring to as “causal flow analysis” is already a feature of an existing Roslyn analyzer.

Thanks, again, for recommending the use of Roslyn and its analyzers for this and a related project (see also: inspectable delegates here).

[CyrusNajmabadi]

Remote Procedure Calls

I'm not getting at all how anything brought up so far has anything to do with an rpc system. Can you explain how the domains are related?

[AdamSobieski]

Models for explanation and argument should work with .NET remoting, remote procedure calls, Web services, and so forth. As developers could invoke methods in a manner so as to obtain explanations for their outputs, they would, similarly, be able to implement this for remoting, RPCs, WSs, and so forth, serializing and deserializing the explanations or arguments.

[CyrusNajmabadi]

I don't understand what these domains have to do with each other. Why is it important for the domains you mentioned here?

It would be like you saying that it's important to have this for .net xml api, me asking "why?", And you reiterating that it's important.

The why part is what is missing.

[CyrusNajmabadi]

So, not to be snarky :-). But it's a bit ironic that a part asking for a system of explanations and justifications to be built, is both lacking in explanations and justifications for why it should be built.

For all your discussions there seem to be a complete lack of motivating examples that show an existing problem, how existing solutions are inadequate for it, and how the proposal elegantly addresses that problem.

[CyrusNajmabadi]

I don't see any actual suggestion for what you want changed in the language here @AdamSobieski .

[CyrusNajmabadi]

Moving to runtime as no examples of actual language requests were provided, despite several requests for exactly that. This appears to then be a request for some new API pattern.

[AdamSobieski]

Thanks @CyrusNajmabadi. I was thinking on the topics of C# language features that this feature set (and the related source code transformations) might eventually involve, e.g., perhaps resembling the async / await keywords for methods' signatures and invocations, about new metadata attributes which might be compiler-generated and/or potentially utilized manually by developers, and about how new keywords would interplay with new metadata attributes.

I think that more concrete answers to those programming-language-related questions will be available after further analyses into what developers would have to do to conveniently utilize these kinds of features (and to interoperate with source-code transformers). Looking forward to any discussion on self-explaining and self-arguing software in the runtime context!

[En3Tho]

Years go.
Walls of text come.
Still issue at hand,
Nobody understands.