Package-level declarations
Types
Base class for test suites exercising a BaseLogicProgrammingScope subtype S (e.g. MinimalLogicProgrammingScope, LogicProgrammingScopeWithOperators, or any richer mixin combination assembled downstream, such as LogicProgrammingScopeWithUnification in :dsl-unify or LogicProgrammingScopeWithTheories in :dsl-theory): concrete subclasses only need to implement createLogicProgrammingScope and then write @Test methods using the helpers below to build and assert on DSL expressions.
Base class for test suites exercising a Termificator implementation, such as Termificator.default or Termificator.legacy: concrete subclasses implement createTermificator and then write @Test methods using assertTermificationWorks/assertTermificationFails to check how individual values get converted.
Expected Numeric results, per Kotlin platform, for a handful of numeric literals whose termification (Termificator.termify) is not platform-independent: the JVM and JS backends don't always agree on the exact decimal digits a floating-point value round-trips to, nor on whether a mathematically-integral Double/Int ends up as an it.unibo.tuprolog.core.Integer or a it.unibo.tuprolog.core.Real — see the JVM and JS actual declarations for the concrete values, and TestLegacyTermifier/TestMinimalLogicProgrammingScope (in :test-dsl's own test suite) for how they are used.
JS values (see PlatformSpecificValues for what each property means): the JS DefaultTermificator decides between Integer and Real via NumberTypeTester, which classifies a Number by matching its toString() against a digits-only pattern, rather than by its static Kotlin type (JS has no separate Int/Double representation). Two JS-specific quirks fall out of that: JS's own Number.toString() renders a whole-valued Double like 1.0 as "1" (no decimal point), so it matches the pattern and termifies to an Integer — see ONE_POINT_ZERO
JVM values (see PlatformSpecificValues for what each property means): the JVM DefaultTermificator always converts a Float/Double via Real.of(value.toString()), so THREE_POINT_ONE_FLOAT carries the exact decimal digits of the 32-bit float closest to 3.1 (not "3.1" itself, since Float.toString on the JVM would round-trip to the shorter form), while an Int always becomes an Integer regardless of its value, hence MINUS_THREE.