G3Kappa
commented
2 years ago Considerations
-
Implemented a static AbstractTermCache. In the future it should be refactored to be non-static. This cache also stores whether a term is not of a specific type, to improve lookup times.
-
If an abstract type implements the static method
Maybe<T> FromCanonical(ITerm canonical), then it will be used to attempt to convert terms to their abstract form whenever applicable.
Also, some results of unification could be represented more efficiently than they currently are: for instance, sub-lists could be represented as slices of a parent list.
This remains an open point.
Abstract types are working, but it's clear that they're still not a definitive improvement over the previous system.
Specifically, it seems that terms that are obtained via unification are not always converted back to their abstract form because either operand is not recognized as an abstract term. Also, terms that are written directly in canonical form have the same issue.
Extending the abstract parsers to consider canonical forms is not guaranteed to work in scenarios where unification is the culprit, although it would solve some problems.
The previous system, and to a degree the current one, made extensive use of term unfolding, i.e. manually unwrapping the AST in order to reconstruct the abstract form. This is fine if it's guaranteed to happen once per term because terms are immutable, but there's currently no cache to keep track of these things and therefore it's a very expensive operation. Still, a cache feels like a band-aid. A better solution could be lurking in the shadows.
Also, some results of unification could be represented more efficiently than they currently are: for instance, sub-lists could be represented as slices of a parent list.