Inspectability

[AdamSobieski]

Hello. I would like to broach, for discussion, providing developers with the capability to declare methods as inspectable, or transparent, meaning that lambda expressions of the methods' implementations would be available, e.g., for metaprogramming purposes.

Brainstorming, we can consider extending System.Reflection.MethodInfo with:

public partial class MethodInfo
{
    public bool IsInspectable { get; }
    public LambdaExpression? Expression { get; }
}

We can also consider the related topic of using metadata, attributes, to declare whether specific methods are intended to be inspectable, or transparent. For example:

public class Foo
{
    [Inspectable]
    public void Baz() { ... }
}

We can also consider providing developers with useful inspectable delegates. In these regards, a System.InspectableDelegate might extend System.Delegate to provide the functionality under discussion.

public abstract class InspectableDelegate : Delegate
{
    public LambdaExpression Expression { get; }
}

We can consider providing the useful feature of strongly-typed inspectable delegates.

public class InspectableFunc<T, TResult> : InspectableDelegate
{
    public new Expression<Func<T, TResult>> Expression { get; }
}

As envisioned, there would exist System.InspectableAction<...> and System.InspectableFunc<...> inspectable delegates, resembling each of those existing delegates, System.Action<...> and System.Func<...>.

If there is interest, I could write-up a lengthier proposal on these topics.

What do you think of these ideas?

[HaloFour]

I'd be more interested in understanding the types of problems that a proposal like this seeks to resolve.

Right now there is a serious problem with evolving expression trees alongside the languages and most language features since C# 6.0 can't be represented in expression trees, which would seemingly be a pretty big problem with the approach suggested here.

[AdamSobieski]

Thank you @HaloFour for your points about the evolution of LINQ expression trees alongside .NET languages, e.g., C#.

As for the uses of such a proposal, I am finding inspectability, or lambda transparency, to be useful for a number of scenarios in a computational narratology project including: constraints, rules, and preconditions and effects on automated planning actions.

In the sketches, in particular as developers are not supposed to manually extend System.Delegate, I use an interface, IInspectableMethod.

    public interface IInspectableMethod
    {
        public LambdaExpression Expression { get; }

        public object? Invoke(object?[]? args);
    }

    public interface IInspectableAction<T> : IInspectableMethod
    {
        public new Expression<Action<T>> Expression { get; }

        public void Invoke(T arg);
    }

    public interface IInspectableFunc<T, TResult> : IInspectableMethod
    {
        public new Expression<Func<T, TResult>> Expression { get; }

        public TResult Invoke(T arg);
    }

Firstly, let us consider constraints.

        public interface IConstraint : INamed, IInspectableMethod
        {
            public string GetMessage(IFormatProvider? formatProvider);

            public new bool Invoke(object?[]? args);
        }

        public interface IConstraint<T> : IConstraint, IInspectableFunc<T, bool> { }

Here, constraints can be provided using named inspectable delegates and can provide messages for developers of use when a particular constraint is not satisfied.

Secondly, let us consider rules.

        public interface IRule<TInput, TOutput> : INamed, IInspectableFunc<TInput, TOutput> { }

Here, rules can be provided using named inspectable delegates.

To clarify about constraints and rules, consider the following:

        public interface IReasoner
        {
            public IEnumerable<IConstraint<IQueryable<Statement>>> Constraints { get; }
            public IEnumerable<IRule<IQueryable<Statement>, IQueryable<Statement>>> Rules { get; }

            public IKnowledgebase Bind(IKnowledgebase source);
        }

where reasoners provide constraints and rules for knowledgebases, collections of statements.

Thirdly, let us consider preconditions and effects on automated planning actions.

        public interface IOperator : INamespaceNamed
        {
            public IDomain Domain { get; }

            public IEnumerable<IConstraint> Constraints { get; }

            public bool CanInvoke(object?[]? args, [NotNullWhen(false)] out Exception? reason);

            public IAction Invoke(object?[]? args);

            public IEnumerable<ILambdaGenerator>? Preconditions { get; }

            public IEnumerable<ILambdaGenerator>? Effects { get; }
        }

        public interface IAction
        {
            public IOperator Operator { get; }

            public IReadOnlyList<object?> Arguments { get; }

            public IEnumerable<IConstraint<IState>> Preconditions { get; }

            public IEnumerable<IInspectableAction<IState>> Effects { get; }
        }

I'm finding these concepts to be useful in the aforementioned computational narratology project and, above, are indicated some of the AI-related uses for inspectable methods or metaprogramming capabilities. I hope that these examples show that this or another similar, related solution for .NET would be useful.

[svick]

It sounds like you were able to build what you needed out of the tools provided currently by C# and .Net. So why should anything change? Are there any shortcomings of your current approach that this proposal would solve? And how would that apply to the whole ecosystem, not just your single project?

[AdamSobieski]

Yes, I was able to build what I needed from the tools provided currently by C# and .NET. I am broaching these topics from a place of considering that these features could be useful to others rather than a place of needing a feature to complete a project. I think that inspectable constraints and inspectable rules, for instances, could be generally useful and that inspectable preconditions and effects could also be useful for some projects.

Also, the interfaces-based approach that I'm using, thus far, could be considered as being a "workaround" compared to classes-based approaches, or, more specifically, to delegates-based approaches indicated above. The interfaces-based approach cannot guarantee that the method invoked by Invoke(...) is the compiled version of the lambda expression made inspectable with Expression but, by using classes, one could.

With respect to the larger ecosystem, I am presently thinking about inspectable constraints and rules and how these could be utilized in others' projects. I will continue to think about other, broader uses of these features.

[AdamSobieski]

Hello. I just thought of another, broader, use of these features. From the domain of metaprogramming, I'm thinking about, beyond self-describing, self-explaining or self-arguing software systems and functionalities.

One can envision a complex transformation on LINQ or Roslyn trees such that resultant functionalities would be able to explain or to argue for their results.

There would be: (1) an ExplainedResult<T> struct or ArguedResult<T> struct which would be returned by transformed methods, (2) a potential need for enhanced annotation capabilities, capabilities to put attributes on expressions, statements, conditional logic, and so forth, (3) some static helper methods which would be utilized by transformed source code.

With respect to point 2, enhanced annotation capabilities, a language feature, other uses for this functionality would include being able to manually provide hints for branch prediction. There are a number of common language runtime implementational possibilities for such a language feature.

public int foo(int x, int y)
{
    ...
    [BranchPrediction(true)]
    if(x > y)
    {
        ...
    }
    else
    {
        ...
    }
}

With respect to point 3, instead of calling Invoke on methods or delegates, transformed functionalities would call static methods like Explainability.Invoke(...) or Argumentation.Invoke(...), passing methods or delegates as arguments. This method would return a ExplainedResult<T> or ArguedResult<T> structure which would, as envisioned, include a T Value { get; } property accessor and other functionality for processing and analyzing a useful explaination, argument, or narration regarding that output value, pertaining to its verification and validation, and, in general, its correctness.

In particular in this language-related forum, it is possible that a new modifier keyword could, like generators, indicate for compilers to modify their outputs for thusly decorated methods, producing the self-explaining, self-arguing, functionalities under discussion.

Beyond self-describing software, beyond verification and validation scenarios, there are the capabilities of transforming LINQ or Roslyn trees into self-explaining, self-arguing source code. These features are but parts of one other, broader, use for inspectability and, if there is interest, I could write up a fuller discussion post on these new topics (including points 1, 2, and 3, above) for this forum.

[CyrusNajmabadi]

if there is interest, I could write up a fuller discussion post on these new topics (including points 1, 2, and 3, above) for this forum.

Sure, go ahead.

However, is unclear why you need any new language features for thos. Why not simply use Roslyn as-is to do this analysis and return whatever it is you want?

[bernd5]

Why you don't use roslyn to "inspect" the delegates? It is much more powerful (and easier to use) than the old runtime Expression API....
For rules or conditions you could write an analyzer...

[AdamSobieski]

Inspectable methods or delegates can be described as storing, e.g., with a field, a cached, potentially weakly referenced, version of a compiled lambda expression or of a decompiled method -- essentially providing both invocation and inspection capabilities for the same methods.

With respect to inspectable constraints and rules, a longer-term vision is to be able to optimize the processing of sets or sequences of them. It could be that there are more tools for analyzing and optimizing Roslyn's models than for working with the Expression API though there might exist tools to map between the two models.

If they haven't already, perhaps someone will prototype a "RoslynLINQ" with IRoslynQueryable<T> which utilizes the Roslyn model and its runtime compiler.

Considering using Roslyn for inspectability, I suppose that, for starters, a matter would be looking at precisely which classes or interfaces would be provided where LambdaExpression and Expression<...> are utilized on the interfaces, above.