Look up for types in the assembly to be able to parse them from a string?

[WhiteBlackGoose]

For example, I've defined my own entity in the assembly:

record DoubleSin(Entity Arg) : FunctionEntity
{
    public string ParsableName { get; } = "double_sin";
    ...
}

Then, what if the parser could look up the types, inherited from FunctionEntity whose ParsableName equals the encountered string and if there exists one, create an instance of it? So that this

Entity expr = "double_sin(x) + x";

would be same as

Entity expr = new DoubleSin(x) + x;

[Rafael-SOWNet]

Three measured things, on master at a45a7256.

1. The type this is written against does not exist. There is no FunctionEntity anywhere in the source, and nothing by that name is on the public surface (PublicApi.txt has zero matches). So the example cannot be tried as written, and whatever the extension point is, it is not that.

2. A node is not an extension point today — it is an eleven-step change inside the repository. Docs/Contributing/AddingNode.cs lists them, and the parser is only step 8 of 11:

1	numerical evaluation, real then complex
2	the node as a nested record in Entity
3	the essential methods
4	pattern replacer
5	expose on MathS
6	derivation
7	compilation
8	parser
9	analytical solver
10	ToSympy

So making the parser discover a type by name would deliver one step of eleven. A double_sin(x) that parses but cannot be differentiated, compiled, simplified or printed to SymPy is arguably worse than one that does not parse, because the failure moves from "this is not a function" to a NotSufficientlySupportedException somewhere further along.

3. Runtime reflection is the mechanism #746 specifically rules out. Its constraint is that extensibility must not be bought with runtime reflection — assembly scanning at parse time is the paradigm case, and it costs startup time on every process, breaks under trimming and Native AOT (both of which this library targets — netstandard2.0;net8.0;net10.0 with AOT publishing tested), and makes what parses depend on which assemblies happen to be loaded.

There is now a precedent for the compile-time version of exactly this. #951 added a source generator that reads attributed methods and emits a registry, and it was chosen over the runtime alternative for this reason. The same shape would work here: an attribute on the custom node, a generator that emits its registration, everything resolved at build time, nothing scanned at run time, and AOT-safe. That is a real design, and it is a different and much larger issue than "look up types in the assembly" — it is closer to #495 (lambdas and functions as entities), which is Accepted and would give user-defined functions a first-class representation rather than a reflective back door.

My suggestion is to close this in favour of #495, or relabel it as "user-defined nodes, compile-time" if you want the narrower version tracked. Either way the reflective form should probably be declined explicitly, so it does not get proposed again.