Changes to FormalAmpersand

[stefjoosten]

This issue is under construction...

Problem

When you change code in the FormalAmpersand codebase, the Haskell compiler will most certainly produce errors. That is because the meatgrinder code needs to remain in sync with the FormalAmpersand code. This issue investigates which Haskell code you must change to keep things working.

Describe the solution you'd like We want to make clear to the users what to do when a change to FormalAmpersand is made. Steps to do:

1. change a relation in FormalAmpersand
2. change the transformer in src>Ampersand>FSpec>Transformers.hs
3. Test it on a .adl-file of your linking with --build-recipe Grind, so you can see the result (for example in JSON format), by using the command:

   ampersand population testing/Travis/testcases/prototype/shouldSucceed/InterfaceTest1.adl --build-recipe Grind --verbose --output-format JSON

   Example

   Let's do this with an example. The problem is that FormalAmpersand does not contain ConceptDefs yet. So let us introduce a relation that links Concept to ConceptDef in FormalAmpersand. In Haskell, this is a function acdcpt :: Concept->ConceptDef, so let's call this relation acdcpt to match the names in FormalAmpersand and Haskell.

   REPRESENT ConceptDef TYPE BIGALPHANUMERIC
   RELATION acdcpt[Concept*ConceptDef] [UNI]
   RULE delUnusedConceptDef : I[ConceptDef] |- acdcpt~;acdcpt
   MEANING "A ConceptDef without Concept will be removed."
   ROLE User MAINTAINS delUnusedConceptDef

   Obviously, a ConceptDef without a Concept makes no sense, so the user gets to resolve that.

So much for the FormalAmpersand part. Now we must match the relation acdcpt[Concept*ConceptDef] by a relation in the meatgrinder and tell the compiler how to populate metamodels with this information.

      ( "acdcpt",
        "Concept",
        "ConceptDef",
        Set.fromList [Uni],
        [ (dirtyId cpt, (PopAlphaNumeric . acdcpt) cpt)
          | cpt :: AConceptDef <- instanceList fSpec,
            (not . T.null . acdcpt) cpt
        ]
      ),

[hanjoosten]

What is the purpose of a ConceptDef in formal ampersand (and thus in the A-structure?)

In the code we now see:

      --    RELATION acddef2[ConceptDef*Meaning] [UNI]  -- ^ The textual definition of this concept.
      ( "acddef2",
        "ConceptDef",
        "Meaning",
        Set.fromList [Uni],
        [ (dirtyId cdf, dirtyId mean)
          | cdf :: AConceptDef <- instanceList fSpec,
            mean :: Meaning <- acdmean cdf
        ]
      ),
      --    RELATION acdcpt[ConceptDef*Text] [UNI]  -- ^ The definition given for the defined concept
      ( "acdcpt",
        "Concept",
        "ConceptDef",
        Set.fromList [Uni],
        [ (dirtyId cdef, PopAlphaNumeric . acdcpt $ cdef)
          | cdef :: AConceptDef <- instanceList fSpec,
            (not . T.null . acdcpt) cdef
        ]
      ),

These two relations contradict each other.

So the definition could refer to the textual description of a Concept. In that case the definition can be seen as a scalar to Concept (it has no dirtyId of its own). OR the ConceptDef has a dirtyId of its own, but then there needs to be a relation between the ConceptDef and the Text that holds the textual representation.

[hanjoosten]

This issue is fixed: When the abovementioned command is issued, ampersand will throw a fatal error if the set of relations defined in formalampersand differs from the set of relations in transformers.hs. As a bonus, warnings are issued for relations that are in sync, but have a different set of properties defined.

[hanjoosten]

There still are quite some relations not in sync. These must be dealt with before we can close this issue

[hanjoosten]

@stefjoosten and I have added and synchronized quite a few relations for formal ampersand. From now on, I consider work on formal ampersand as ongoing maintenance. Hence, I close this ticket.