Design discussion

We have some number types in the Julia ecosystem that are "a bit special". The one's I have encountered most often are quantities (numbers with units), opaque/traced/symbolic numbers (value not accessible at all) and numbers that are "remote", i.e. that live on a separate compute-node/device/system (value accessible only with substantial latency).

Making such numbers subtypes of `Real` and `Integer` is tricky, dispatch wise, but also semantically not ideal - one might argue that a traced number with a real value is not actually a real number itself - I can operate on it, but I can't compare values and make a branching decision based on it (at least not during tracing). Likewise, a real number with a unit is clearly not a real number itself. On the other hand, user code often needs to restrict numerical type, both for semtantic and dispatch reasons - a function that will behave wrong for complex values should ideally not use `Number` at the argument type.

Also see https://github.com/EnzymeAD/Reactant.jl/issues/1570 and https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/38 for context.

NestedNumbers is an attempt to create a bridge here - a super-lightweight package that user code can depend on and use for dispatch, while only minimal changes are required for unit packages or packages that use traced numbers like Reactant.

See the [NestedNumbers demo](https://github.com/JuliaMath/NestedNumbers.jl/blob/main/examples/usage_demo.jl), which requires these draft PRs:

* https://github.com/JuliaPhysics/Unitful.jl/pull/837
* https://github.com/Deduction42/FlexUnits.jl/pull/52
* https://github.com/JuliaPhysics/DynamicQuantities.jl/pull/198
* https://github.com/EnzymeAD/Reactant.jl/pull/2434

The final approach should ideally involve [UnitsBase](https://github.com/JuliaAPlavin/UnitsBase.jl) as well.

(Note that Reactant doesn't seem to work with unitful numbers in general yet, so the demo doesn't show a combination of both. )

The basic approach is this: NestedNumbers defines

* Abstract types like `OpaqueNumber{T}` `RemoteNumber{T}` `QuantityNumber{T}` that packages that define number types can subtype.
* Union typedefs like `AReal`, `AInteger`, `AComplex`, `ABool` and `QReal`, `QInteger`, `QComplex`, `QBool` for user/downstream code to dispatch on.

It's all in [the single short source file](https://github.com/JuliaMath/NestedNumbers.jl/blob/main/src/NestedNumbers.jl).

Everyone involved/interested is more than welcome to comment and critique here, propose radical changes (feel free to open PRs), etc. NestedNumbers is not registered yet on purpose, everything is up for change including the package name. This is an attempt to see if this kind of approach can work and would be acceptable, and it's meant to involve the whole community.

Start with src/NestedNumbers.jl and examples/usage_demo.jl, then review the linked draft PRs and the Reactant and Discourse context. The issue is seeking community critique of the package name, type hierarchy, and overall approach rather than specifying a bounded change; done would require an agreed direction or a concrete follow-up proposal.

Escrito por el modelo de indexación a partir del texto del issue.