#463 Unclear semantics of interface refs

[Martijn Schrage]

Something that was bugging me for a while finally made sense after I did some digging in the old prototype generator. If we have friends :: Person * Person and name, city :: Person * String in this pattern:

INTERFACE
BOX [ ..
      "My friends" : friends
      BOX [ "Name" : isNamed
          , "City" : livesIn
          ]
      ..
    ]

it looks like we can abstract by using a separate Person interface

INTERFACE
BOX [ ..
      "My friends" : friends
      INTERFACE Person
      ..
    ]

INTERFACE Person : I[Person]
BOX [ "Name" : isNamed
    , "City" : livesIn
    ]

However, this is not the same interface as the first one, as we introduce an extra relation (I[Person]) and an extra label Person. If the relation is I, you won't really notice it, but there is currently no restriction on the relation, so it could be any relation of type Person*a.

In the old prototype, this is handled by introducing an implicit box, which means the interface with the ref expands to:

INTERFACE
BOX [ ..
      "My friends" : friends
        BOX [ Person : I[Person]
              BOX [ "Name" : isNamed
                  , "City" : livesIn
                  ]
            ]
      ..
    ]

This may not really be what you would expect, as the BOX before Person does not appear anywhere in the source, and cannot be given a class with our future BOX<class> syntax.

The generator for the new front-end still has some todo's in the code for refs. At the moment, it does not insert an implicit box, but uses a composition of the two relations. This creates some problems when trying to determine editability though (which is therefore always set to False.)

A cleaner solution would be to restrict referenced interfaces to I, so we can simply ignore
the relation and label of the interface and only use its BOX.

[Rieks]

You can look at it in another way: the I[Person] is one way to specify the concept on which an INTERFACE (or BOX) is supposed to work. There are other ways of doing this, e.g. INTERFACE[<Concept>], and for the BOX, the concept may be derived from its context in the same way this is done in rules that contain relations that have overloaded arguments. Then, the I[Person] would no longer be required, but it would remain possible to explicitly have an expression there.

[Bas Joosten]

Here's my 2¢. I suggest we don't restrict interfaces to I, but allow arbitrary expressions. The reason is that the expression can be used to indicate something like: don't draw this interface unless this or that property holds.

To get rid of the BOX, I suggest we ;-together the expression and the interface referred to, like this:

INTERFACE
BOX [ ..
"My friends" : friends;I[Person]
BOX [ "Name" : isNamed
, "City" : livesIn
]
..
]

The type-checker currently checks that no epsilon needs to be inserted on that ;, so this should be safe, but we'd have to put in a test case with a non-endo relation for the Interface just to be sure.

[Martijn Schrage]

Yes, that's actually how I implemented it, with a composition of the two relations. The thing that bothered me though is how to determine editability of the composition. One issue was with generalizations, but the interface ref type checker currently does not allow those. Another is when the normalized composition may return an editable relation where you may not expect it (e.g. by normalizing some r;r~ to I for an injective and total r). Maybe this is not a problem (also the normalizer does not seem to do it at the moment due to the nesting of the compositions), but it does make things a bit more complex.

If there's a desire for non-I relations on referenced interfaces though, I can have a closer look at the editability and keep the composition in place.

I didn't quite get the remark about the epsilon, or why it would be a problem to have one there, but it looks like it doesn't affect the above, does it?

[Martijn Schrage]

I have implemented the editability check on the composition, so this ticket can be closed for now.

https://github.com/AmpersandTarski/ampersand/commit/8dc21cecbefeff2a0483294a4debcc3a9e028db8