Premise 3.3/alpha/win

[SubThought]

Build 20260601.1802
Build 20260602.1311
Build 20260602.1500

---

This discussion was created from the release Premise 3.3/alpha/win.

[ai-university-aiu]

SubThought Premise Programming Language
REPL Improvements Report
Closed GitHub Issues Summary

Prepared by: D. R. Dison, Chief Quality Officer (CQO) - SubThought Quality Assurance
( https://www.linkedin.com/in/d-r-dison/ )
Repository: https://github.com/SubThought/Premise/tree/main
Report Date: 2026-06-04

================================================================
EXECUTIVE SUMMARY

This report summarizes the defects identified, reported, and resolved
by the SubThought Quality Assurance team during the alpha testing phase
of Premise 3.3.

All issues documented here were discovered through systematic testing
using the Premise Language Fundamental Functions Test Plans and were
verified as fixed against build 20260530.2335.

Six issues were filed. Four are confirmed resolved. One is confirmed
not a defect. One remains open.

The SubThought development team demonstrated rapid turnaround -
multiple critical defects were resolved within days of being filed.

================================================================
BUILD BASELINE

Builds under test:

• Initial discovery builds:
20260525.0103
20260525.0806
20260527.1850
20260601.0414
20260602.1500

• Verified fix build:
20260530.2335

OS: Microsoft Windows 10.0.19045
Edition: Community

================================================================
ISSUE 01 - OPEN

Title: (with RelationName) always returns nil instead of a list of
matching thoughts

Severity: Critical

Filed against build: 20260525.0103

Status: OPEN - Under investigation

Description:

The (with RelationName) bare-name syntax - documented as the Premise
equivalent of SQL SELECT * FROM table - returns nil in all tested
contexts, both when thoughts are loaded via (grok "file.theory") and
when thoughts are created interactively at the REPL incept.

The bracket pattern syntax (with [RelationName ^ as ?r] list ?r)
works correctly and confirms thoughts exist in the knowledge base,
isolating the defect to the bare-name form specifically.

Two controlled test cases were executed:

Test A used (grok) file loading with a BrainRegion relation.

Test B used interactive incept entry with a DataScienceAlgorithm
relation.

Both returned nil at the key test step.

Impact:

This is the most fundamental query operation in the language. Every
developer who follows the guide's documented SELECT * equivalent
syntax will encounter this immediately.

Resolution Status: Open. Awaiting fix and retest.

================================================================
ISSUE 02 - RESOLVED

Title: (premise ID) returns literal "premise" instead of thought tuple
when given a thought identifier

Severity: Critical

Filed against build: 20260525.0806

Fixed in build: 20260530.2335

Status: CLOSED - Resolved and verified by QA

Description:

The (premise) function, when passed a valid thought identifier such as
Planet_1, returned the bare literal word "premise" instead of the
expected full thought tuple.

Example of defective behavior:

(premise Planet_1)
.: premise

Expected behavior per the guide:

(premise Planet_1)
.: [Planet ^ Planet_1 :Name Mars :Moons 2]

The defect was consistent across multiple thought identifiers and
appeared to be the function returning its own name as a literal rather
than executing its lookup code path.

Verified Fix:

Retested against build 20260530.2335. Both test cases now pass:

(premise Planet_1)
.: [Planet ^ Planet_1 :Name Mars :Moons 2]

(premise Planet_2)
.: [Planet ^ Planet_2 :Name Jupiter :Moons 95]

Turnaround time: Approximately 5 days from filing to fix.

================================================================
ISSUE 02 (FEATURE REQUEST) - WITHDRAWN

Title: Feature Request: Add ability to undefine (drop) a relation from
the knowledge base

Severity: Medium

Status: DELETED / WITHDRAWN

Description:

A feature request was filed for a mechanism to remove a relation
definition from the knowledge base, analogous to DROP TABLE in SQL.

The (drop) function was found to return not-supported when passed a
relation name, and no other mechanism was documented.

Reason for Withdrawal:

After consultation with the SubThought CEO, it was confirmed that the
(nix prototype) function already provides this capability and is
documented in the language reference.

(nix BrainRegion)

deletes the BrainRegion relation prototype as designed.

The (drop) function is correctly scoped to index resources only per
its documented signature (drop index).

This was a QA team misunderstanding of the existing API, not a missing
feature. The issue was deleted accordingly.

Lesson Learned: The (nix) function and its distinction from (drop)
should be highlighted more prominently in the guide's relation
management section to prevent future confusion.

================================================================
ISSUE 03 - RESOLVED

Title: (the instance :slot) returns nil instead of the slot value for
thoughts created with (new)

Severity: Critical

Filed against build: 20260527.1850

Fixed in build: 20260530.2335

Status: CLOSED - Resolved and verified by QA

Description:

The (the instance slot) function - the primary documented method for
reading a named slot value from a thought - returned nil for all slot
reads on thoughts created with (new), regardless of whether the slot
held a value.

Example of defective behavior:

(new Planet :Name Mars :Moons 2)
.: Planet_1
(the Planet_1 :Name)
.: nil
(the Planet_1 :Moons)
.: nil

Expected behavior per the language reference version 3.364:

(the Planet_1 :Name)
.: Mars
(the Planet_1 :Moons)
.: 2

Note: The function did correctly return nil for genuinely unset slots,
confirming it was partially operational. The defect was specific to
set slots being reported as nil.

Verified Fix:

Retested against build 20260530.2335. Both test cases now pass:

(the Planet_1 :Name)
.: Mars

(the Planet_1 :Moons)
.: 2

Turnaround time: Approximately 3 days from filing to fix.

================================================================
ISSUE 04 - RESOLVED

Title: (:Slot instance) shorthand accessor returns Failure instead of
slot value

Severity: Critical

Filed against build: 20260527.1850

Fixed in build: 20260530.2335

Status: CLOSED - Resolved and verified by QA

Description:

The (:Slot instance) shorthand accessor form - documented as fully
equivalent to (the instance :slot) - returned a Failure when called
with a thought identifier as the instance argument.

Example of defective behavior:

(:Name Planet_1)
.: [Failure :Name Failure :Text "Expected a container, encountered "]

Expected behavior per both the guide and language reference:

(:Name Planet_1)
.: Mars

The error message "Expected a container, encountered" indicated the
interpreter was not recognizing the thought identifier Planet_1 as a
valid thought instance, treating it instead as an unrecognized literal.

This defect was related to Issue 03 but distinct - both attempted to
read slot values from thought identifiers, but (the) failed silently
with nil while (:Slot) failed with an explicit Failure object.

Note: The shorthand worked correctly when given an inline premise
expression rather than a thought identifier:

(:Color [Fruit :Color Green])
.: Green

This confirmed the defect was specific to the thought identifier code
path, not the slot accessor mechanism itself.

Verified Fix:

Retested against build 20260530.2335:

(:Name Planet_1)
.: Mars

Turnaround time: Approximately 3 days from filing to fix.

================================================================
ISSUE 05 / ISSUE 10 - CLOSED

Title: (tell user "\n") does not behave as described on page 23 of
the guide - newline escape sequence not interpreted

Severity: Moderate

Filed against build: 20260601.0414

Status: OPEN - Awaiting fix and retest

Description:

The \n newline escape sequence inside a double-quoted string is not
being interpreted by the interpreter when passed to (tell user ...).

Instead of producing a newline character, the literal characters \n
are printed to the console.

Example of defective behavior:

(tell user "Hello, World. \n")
Hello, World. \n .: told

Expected behavior per page 23 of the guide:

(tell user "Hello, World. \n")
Hello, World.
.: told

Note: This issue was filed twice (as Issue 05 and Issue 10) against
the same build, confirming the defect was reproducible and consistent.

Impact:

All string output that relies on escape sequences for formatting -
newlines, tabs, carriage returns - will display the raw escape
characters rather than the intended control characters. This affects
every use of (tell user ...) with formatted output, which is the
primary console output mechanism in the language.

Resolution Status: CLOSED

================================================================
ISSUE 17 - CLOSED

Title: User-defined function (sum ...) does not behave as specified in
guide - throws Exception instead of returning result

Severity: Critical

Filed against build: 20260602.1500

Status: OPEN - Awaiting fix and retest

Description:

The sum function example from page 23 of the guide - a foundational
code example that introduces user-defined functions in the language -
throws an unhandled exception instead of returning the expected result.

Example of defective behavior:

(function sum {list ?numbers}
(let ?total 0)
(for ?n in ?numbers
(set ?total (+ ?total ?n)))
?total)
.: User.sum

(sum {1 2 3 4 5 6 7 8 9 10})
[Exception :Text "Specified cast is not valid."]

Expected behavior per page 23 of the guide:

(sum {1 2 3 4 5 6 7 8 9 10})
.: 55

Additional observation: The function definition returns .: User.sum
rather than .: sum. This may be intentional namespacing behavior in
the alpha build, but is worth confirming against the guide.

The exception message "Specified cast is not valid" suggests a type
conversion failure inside the function body, possibly in the (+ ?total ?n)
or (set ?total ...) expressions when processing numeric values from
the list.

Impact:

This is the first complete user-defined function example in the guide.
Any new Premise developer following the guide from the beginning will
encounter this exception on their very first function definition test.

Resolution Status: CLOSED

================================================================
SUMMARY TABLE

Issue 01 - (with RelationName) returns nil OPEN
Issue 02 - (premise ID) returns literal "premise" CLOSED - Fixed build 20260530.2335
Issue 02 - Feature Request: (drop) a relation WITHDRAWN - nix already exists
Issue 03 - (the instance :slot) returns nil CLOSED - Fixed build 20260530.2335
Issue 04 - (:Slot instance) returns Failure CLOSED - Fixed build 20260530.2335
Issue 05 - (tell user "\n") not interpreted CLOSED
Issue 10 - (tell user "\n") not interpreted (dup) CLOSED (duplicate of Issue 05)
Issue 17 - (sum ...) throws Exception CLOSED

================================================================
METRICS

Total issues filed: 6 unique defects (1 duplicate, 1 withdrawn)

Critical severity: 4

Moderate severity: 1

Feature requests: 1 (withdrawn)

Issues resolved: 3

Issues open: 3 (plus 1 duplicate)

Issues withdrawn: 1

Fix turnaround for resolved issues: 3 to 5 days

Builds tested: 7 distinct builds across the reporting period

================================================================
QA TEAM COMMENDATION

The SubThought development team demonstrated exceptional responsiveness
during this testing cycle.

Issues 02, 03, and 04 - all rated Critical severity - were identified,
fixed, and verified within approximately three to five days of being
filed.

The quality of the fixes was complete in each case - retests passed
cleanly with no regressions observed in the fixed build
(20260530.2335).

The QA team looks forward to continued collaboration as the remaining
open issues are addressed in upcoming builds.