Parsing of INTERFACE without BOX followed by another INTERFACE fails

[hanjoosten]

When we have two succesive INTERFACE definitions, where the first one has no BOX defined, the parser complains, while it can be perfectly sound.

[hanjoosten]

The script

CONTEXT Issue406a IN ENGLISH
   INTERFACE Foo : I[A]
   s :: A*B
ENDCONTEXT

fails with error message:

In file "Issue406a.adl" (line 3, column 6):
Parsing stumbled upon operator '::'
at that point expecting keyword "META", keyword "PATTERN", keyword "PROCESS", keyword "RULE", keyword "CLASSIFY", keyword "RELATION", lower case identifier, keyword "CONCEPT", keyword "REPRESENT", keyword "ROLE", keyword "SERVICE", keyword "SPEC", keyword "IDENT", keyword "VIEW", keyword "INTERFACE", keyword "SQLPLUG", keyword "PHPPLUG", keyword "PURPOSE", keyword "POPULATION", keyword "THEMES", keyword "INCLUDE" or keyword "ENDCONTEXT"

[hanjoosten]

The script

CONTEXT Issue406b IN ENGLISH
   INTERFACE Foo : I[A]
   INTERFACE Bar : I[A]
      BOX [ "s" : s ]
   s :: A*B
ENDCONTEXT

fails with error message:

In file "Issue406b.adl" (line 3, column 18):
Parsing stumbled upon operator ':'
at that point expecting keyword "META", keyword "PATTERN", keyword "PROCESS", keyword "RULE", keyword "CLASSIFY", keyword "RELATION", lower case identifier, keyword "CONCEPT", keyword "REPRESENT", keyword "ROLE", keyword "SERVICE", keyword "SPEC", keyword "IDENT", keyword "VIEW", keyword "INTERFACE", keyword "SQLPLUG", keyword "PHPPLUG", keyword "PURPOSE", keyword "POPULATION", keyword "THEMES", keyword "INCLUDE" or keyword "ENDCONTEXT"

[hanjoosten]

Diagnosis

The problem is, the parser does not know when the first INTERFACE statement is done. It has some optional stuff at the rear of the statement. INTERFACE Bar is a valid part of the first INTERFACE statement.

Solutions

1. We could add a mandatory "ENDINTERFACE" keyword to the INTERFACE statement. This however has quite some impact on existing scripts.
2. We could change the optional subInterface to be mandatory. This will require an extra keyword like NONE for the case that there is no subinterface.
3. ...

[hanjoosten]

@stefjoosten I would like your opinion please

[stefjoosten]

What purpose is served by an INTERFACE without BOX? @RieksJ, do you have a use-case for that?

[Michiel-s]

How about an optional ENDINTERFACE statement. Low user impact but enables us to have interfaces without boxes.

Stef, for now I have already two use cases.

1. Creating system interfaces. We've already implemented one. The interface SessionRoles is called to determine all allowed roles for the current session user. This interface is defined in the SIAM module which you need to enable the built-in login functionality. This interface currently is defined as:

INTERFACE "SessionRoles" FOR SYSTEM : sessionAllowedRoles[SESSION*Role] BOX [ "ignored" : I ]

The ignored part is not needed because the interface expression sessionAllowedRoles already provides the Role atoms we need. So let's leave out the box here.

2. Currently for input fields in the user interfaces the front end calls the API to get all the atoms to choose from. We would like to start experimenting with the possibility to limit this list of possibilities (think of a select box). In some way we need to express this select expression. I think this could be implemented by interfaces. A first step here would be to not get all the atoms given a certain concept, but only those that are returned by an interface expression (just like use case 1). For sure thoughts on this are not fully clear yet.

A final argument: sub interfaces can have no box and interfaces and subinterfaces are the same (it's recursive). So let's turn it around, why prevent interfaces from having no box?

[hanjoosten]

An optional keyword is no solution. Then parsing remains a pain. since there is a usecase for this situation, I agree that something has to be done. I suggest the following:

• The subinterface of the top-level INTERFACE will be made mandatory in the syntax.
• To enable the above mentioned usecases, we introduce a keyword (i.e. NONE) to expicitly specify that there is no subinterface.
  Would this suffice?

[Michiel-s]

As discussed earlier, allowing an empty box would also be ok.

So:

INTERFACE "Test" : expr BOX []

I personally don't like the NONE option. But that's a matter of taste I guess.

[hanjoosten]

Instead of the introduction of the keyword NONE, I enabled the list of the BOX [ ] construction to be empty.