AmpersandTarski / Ampersand

Build database applications faster than anyone else, and keep your data pollution free as a bonus.
http://ampersandtarski.github.io/
GNU General Public License v3.0
40 stars 8 forks source link

Language proposal: include patterns #1470

Open sjcjoosten opened 4 months ago

sjcjoosten commented 4 months ago

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:

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.