Unexpected runtime behavior with CLASSIFY

[stefjoosten]

Situation

I am running a prototype on ampersandtarski/prototype-framework:v1.17, which runs Ampersand vs. 4.7.6.

CONTEXT Issue151

CLASSIFY A ISA C

RELATION r[A*B]
    = [("A1", "B1")]

INTERFACE Try : "_SESSION"[SESSION] BOX
  [ "from C" : V[SESSION*C] BOX<TABLE>
     [ "C" : I
     , "r[A*B]" : r[A*B]
     ]
  , "from A" : V[SESSION*A] BOX<TABLE>
     [ "A" : I
     , "r[A*B]" : r[A*B]
     ]
  ]

ENDCONTEXT

When running this prototype, what I see is exactly what I expected:

Obviously, I can insert the pair ("A1", "B2") in r[A*B] by means of interface from A.

However, I cannot insert the pair ("A1", "B2") in r[A*B] by means of interface from C:

This is weird because in both cases I am inserting exactly the same tuple in exactly the same relation.

What I expected

This error message is surprising because I'm merely inserting a pair of type A*B into the relation r[A*B]. I expected this to work.

Steps to reproduce

1. Run the above script as a prototype
2. Try to insert the pair ("A1", "B2") in r[A*B] by means of interface from A. This will work.
3. Try to insert the pair ("A1", "B2") in r[A*B] by means of interface from C. This does not work.

[stefjoosten]

Analysis

It seems that the concept C gets in the way when I use the interface from C. I suspect that this error is in the back-end code. The error message comes from line 45 of the file src/Ampersand/Core/Link.php, in the repository Prototype. It is produced by a call of function __construct of class Link.

In interface from C, the software assumes that the source atom is a C, even though it is registered as an A (as well as a C). But even if it were not registered as an A (and only as C), we would still be inserting the pair ("A1", "B2") in r[A*B]. The insertion implies that A1 is not just a C but in fact an A. This is an implicit specialization of the atom A1 to the concept A. Implicit specialization must be implemented too, by updating the concept table of A to maintain the system invariant that every concept in a relation is registered in the associated concept table.

[stefjoosten]

Is this script a candidate for an automated regression test of the back end? Why?