Skip to content

Releases: dylanflynn477/ASPf-next

ASPf-next 0.2.0a2

ASPf-next 0.2.0a2 Pre-release
Pre-release

Choose a tag to compare

@dylanflynn477 dylanflynn477 released this 22 Aug 15:12
e57322f

ASPf-next 0.2.0a2

Release date: 2026-08-22

Experimental alpha research software.

ASPf-next 0.2.0a2 is a hardening release. It does not expand the released
ASP{f} syntax or expose the native research backend. The reference backend
remains the production/default implementation, and historical _v
non-Herbrand variables remain unsupported by the frontend.

Highlights

  • Added aspf --version and a clean-wheel installation smoke check.
  • Adversarially tested native research provenance, narrow clauses,
    backtracking, repeated solves, multi-model enumeration, and bounded
    multi-thread behavior.
  • Added a deterministic 144-case reference/native differential matrix and
    metamorphic rule/seed-order checks.
  • Corrected fallback-clause lifetime handling and made thread-local evaluation
    cache validity explicit through semantic generation tracking.
  • Added deterministic clause-audit records and conservative explanations for
    dynamically absent applications only when all grounded providers have
    justified failures.
  • Tightened conservative non-ground n-loop matching without broadening the
    documented exact fragment.
  • Recorded before/after native workloads and kept the prototype's
    substantially slower solve performance explicit.

Compatibility boundary

The supported-language specification, reference lowering, CLI backend, and
normalized output contract are unchanged from 0.2.0a1. In particular:

  • undefined is not zero, false, unequal, or a guessed value;
  • functionality does not imply totality;
  • arithmetic and n-atoms in aggregates, choices, disjunctions, and conditional
    literals remain unsupported;
  • _v remains rejected rather than translated into an ordinary Clingo
    variable; and
  • the native backend remains under research/, with a PARTIAL GO for further
    research and a NO-GO for production integration.

License transition

Beginning with this release, ASPf-next is distributed under the PolyForm
Noncommercial License 1.0.0. It is source available, not OSI-approved open
source. Commercial use requires prior written permission or a separate
commercial license from the copyright holder.

ASPf-next 0.2.0a1 was released under the MIT License. Rights granted under
that release remain governed by its accompanying MIT License. The transition
for later versions does not revoke or narrow those historical rights. See the
licensing guide.

Other repository revisions validly obtained with an MIT License before the
transition likewise retain the rights granted with those copies.

Known research limitations

  • Dynamic absence is explained only when every grounded provider has a proved
    failure; unassigned and cyclic providers deliberately remain unexplained.
  • Native closure evaluation is still Python-heavy and substantially slower
    than the relational reference backend on recorded workloads.
  • The exact typed n-loop fragment is variable-free; broader non-ground analysis
    remains conservative.
  • Two-thread behavior has bounded test evidence, not a production support
    claim.

Validation

The full quality, conformance, historical-compatibility, research,
package-build, and clean-install checks passed before publication. The
maintainer approved the licensing transition after its limitations and
non-retroactivity were documented.

ASPf-next 0.2.0a1

ASPf-next 0.2.0a1 Pre-release
Pre-release

Choose a tag to compare

@dylanflynn477 dylanflynn477 released this 08 Aug 14:24
adee495

ASPf-next 0.2.0a1

Release date: 2026-08-08

Experimental alpha research software.

ASPf-next is an independent clean-room modernization of Marcello Balduccini's ASP{f} language. This first published alpha provides an inspectable Python compatibility frontend and reference translation for Clingo 5.8. It does not modify Clingo, copy historical Clingo{f} implementation code, claim full compatibility, or reproduce the historical system's grounding efficiency.

Why 0.2.0a1?

The repository began with unpublished 0.1.0a1 metadata for a restricted reference frontend. The 0.2 line reflects three completed historical compatibility milestones: global #nherb. mode, historical non-Herbrand visibility directives, and historical seed-equality safety with ordinary value variables. The alpha suffix remains because the language boundary is narrow and the backend is still a correctness-oriented translation.

Highlights

  • Partial non-Herbrand applications: absence means undefined, while a global functionality constraint prevents conflicting values.
  • Explicit, application-style, and global declaration forms with exact name/arity handling.
  • #= assignments in facts and complete rule heads.
  • Defined-value #=, #!=, and integer-only #<, #<=, #>, #>= body comparisons, including application operands.
  • One-level default negation implemented as failure of positive satisfaction, including undefined operands.
  • Direct domain-safe ordinary key variables, scalar seed-equality safety, and restricted body value variables.
  • Historical assignment visibility controls that affect rendering only.
  • Stable human and JSON models with private __aspf_ predicates filtered.
  • An executable historical compatibility corpus and manifest-derived report.
  • A synthetic partial-indicator portfolio demo that demonstrates undefinedness without making a trading or predictive claim.

Historical compatibility status

The 39-case historical corpus has 35 passing cases and 4 strict expected unsupported cases. Within the full manifest classification, 7 passing cases carry a documented restriction, 2 passing cases reproduce historical rejection of invalid programs, 4 cases are intentionally deferred, and none are unresolved. Run:

pytest tests/historical_compat
python scripts/compatibility_report.py

The compatibility policy and case-level evidence are in the historical audit.
The release boundary also passed the documented 20-point adversarial semantic review.

Non-Herbrand variable decision

Historical _V n-variables remain deferred. The research probe found that an ordinary relational rewrite can reproduce simple copy models only by grounding over each candidate value, while treating _V as a constant is semantically wrong. The reference backend therefore fails the required grounder-inert and grounding-growth criteria. See the NO-GO analysis.

Known limitations

  • no arithmetic expressions inside n-atoms;
  • no n-atoms in aggregates, choices, disjunctions, or conditional literals;
  • no _V non-Herbrand variables;
  • no nested non-Herbrand application operands;
  • no ordered value variables or assignment-head value variables;
  • no native theory-atom backend or custom propagator; and
  • no claim of full ASP{f}/Clingo{f} compatibility or historical grounding efficiency.

Install and verify

Python 3.11 or 3.12 is supported.

python -m pip install .
aspf examples/01_basic_assignment.aspf
aspf examples/portfolio/technical_indicators.aspf

Attribution

Marcello Balduccini created ASP{f} and the historical Clingo{f} system.
ASPf-next is independently created and maintained by Dylan Flynn and is not affiliated with Balduccini, the historical project, Potassco, or Potassco's separate Flingo project. See the provenance policy.


Licensing note: ASPf-next 0.2.0a1 was released under the MIT License and remains governed by the MIT License included in this tag. Rights granted for this release are unchanged. Later ASPf-next versions may be distributed under different terms; consult the license accompanying the specific version you use.