Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Language proposal: include patterns #1470

Open
sjcjoosten opened this issue Feb 26, 2024 · 3 comments
Open

Language proposal: include patterns #1470

sjcjoosten opened this issue Feb 26, 2024 · 3 comments
Labels
Discussion enhancement Indicates new feature requests Namespaces

Comments

@sjcjoosten
Copy link
Contributor

sjcjoosten commented Feb 26, 2024

Current situation

Composing Ampersand scripts currently works by taking the union of a bunch of ADL files. This gives a lot of flexibility but also provides little to no structure. One of the problems solved by simply taking the union of a bunch of ADL files is that it allows the reuse of designs. A good convention is to ensure that an ADL design can only talk about itself: rules and populations that mention relations outside of that design aren't supposed to exist. Ampersand doesn't enforce such conventions, and allowing Ampersand users to create a mess for themselves.
I propose to make reuse of designs something on which Ampersand is opinionated, that is: Ampersand as a language provides constructs for the programmer to make design (re)use explicit. This will give up some flexibility, forcing Ampersand users to be a bit more structured, with the benefit of the system offering certain guarantees.

Scope of the solution

To describe the composition of Ampersand patterns, I want to start by talking about design (re)use within a file. One of the issues that will come up is what should happen if a design is reused twice: does that mean the relations mentioned in that design end up in the final system once or twice? Additionally, when composing designs, we might want to make changes (or additions) to how the inclusion of files work.

Proposal

I propose the following changes:

  • Patterns have a name, and that name is implicitly used as a name-space for anything inside that pattern
  • Patterns can be included in other patterns, indicating design reuse
  • The only way one can refer to things within a pattern, is by including it

Concretely, I propose the following would be a valid script:

PATTERN Siam
  RELATION role[User * Role]
ENDPATTERN

PATTERN EmployeePortal
  INCLUDE Siam AS Siam
  RELATION homepage[Siam.User * Page]
  RELATION access[Page * Siam.Role]
  RULE homepage_access : homepage :- Siam.role ; access
  MEANING "A user must have a role that gives it access to its homepage"
ENDPATTERN

INCLUDE EmployeePortal AS EmployeePortal
POPULATION EmployeePortal.access CONTAINS [("Employee", "Welcome")]
POPULATION EmployeePortal.Siam.role CONTAINS [("Sebastiaan", "Employee")]

Here the EmployeePortal.Siam.role reference intends to illustrate that we can refer to named things (relations, concepts, rules) in patterns from outside of them by adding a prefix. An equivalent way to achieve the same thing would be to replace the last line with:

INCLUDE Siam AS Siam
POPULATION Siam.role CONTAINS [("Sebastiaan","Employee")]
@stefjoosten
Copy link
Contributor

stefjoosten commented Mar 2, 2024

Question: Under the same population in Script 1 and Script 2, which differences may I expect in the violations of rule homepage_access?
Script 1:

PATTERN Siam
  RELATION role[User * Role]
ENDPATTERN

PATTERN EmployeePortal
  INCLUDE Siam
  RELATION homepage[User * Page]
  RELATION access[Page * Role]
  RULE homepage_access : homepage :- role ; access
  MEANING "A user must have a role that gives it access to its homepage"
ENDPATTERN

and Script 2:

PATTERN Siam
  RELATION role[User * Role]
ENDPATTERN

PATTERN EmployeePortal
  INCLUDE Siam AS Siam
  ALIAS Siam.User AS User
  ALIAS Siam.Role AS Role
  ALIAS Siam.role[User * Role] AS role[User * Role]
  RELATION homepage[Siam.User * Page]
  RELATION access[Page * Siam.Role]
  RULE homepage_access : homepage :- Siam.role ; access
  MEANING "A user must have a role that gives it access to its homepage"
ENDPATTERN

@sjcjoosten
Copy link
Contributor Author

As much fun as it is to add new keywords to Ampersand and imagine how they might interact, I think that in the interest of proposing something that can be built quickly without needing to wreck our brains on the possible interactions of all these features, it might be a good idea not to introduce the ALIAS keyword as part of this proposal. (Unless it is already part of Ampersand and I wasn't aware of it, in which case you'll have to explain to me what its meaning is.)

@stefjoosten
Copy link
Contributor

After our discussion yesterday, I presume the answer is: We expect no differences in the violation set of rule homepage_access in Script1 and Script2 respectively.

@stefjoosten stefjoosten added enhancement Indicates new feature requests Discussion Namespaces labels Mar 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion enhancement Indicates new feature requests Namespaces
Projects
None yet
Development

No branches or pull requests

2 participants