diff --git a/.github/workflows/build-push-to-docker-hub.yml b/.github/workflows/build-push-to-docker-hub.yml index 496d2a76e7..0bcf6a5c0f 100644 --- a/.github/workflows/build-push-to-docker-hub.yml +++ b/.github/workflows/build-push-to-docker-hub.yml @@ -20,7 +20,7 @@ jobs: uses: actions/checkout@v2 - name: Build and push Docker images - uses: docker/build-push-action@v1 + uses: docker/build-push-action@v2 with: username: ${{ secrets.DOCKER_HUB_USERNAME }} password: ${{ secrets.DOCKER_HUB_PASSWORD }} diff --git a/AmpersandData/FormalAmpersand/AST.adl b/AmpersandData/FormalAmpersand/AST.adl deleted file mode 100644 index bda7257797..0000000000 --- a/AmpersandData/FormalAmpersand/AST.adl +++ /dev/null @@ -1,3 +0,0 @@ -CONTEXT Ampersand IN ENGLISH - - diff --git a/AmpersandData/FormalAmpersand/AST.docadl b/AmpersandData/FormalAmpersand/AST.docadl deleted file mode 100644 index 03e836c96a..0000000000 --- a/AmpersandData/FormalAmpersand/AST.docadl +++ /dev/null @@ -1,228 +0,0 @@ -CONTEXT RAP IN ENGLISH LATEX -{- This file contains the documentation of RAP in LaTeX format. - Each concept of the RAP metamodel has its own section, where sections are separated by comments -} -INCLUDE "FormalAmpersand.adl" -INCLUDE "Atoms.docadl" ---INCLUDE "Terms.docadl" -INCLUDE "Rules.docadl" - --- Context -PURPOSE PATTERN Context -{+The rules that govern contexts are brought together in one pattern, -in order to formalize contexts and determine their meaning. -+} -CONCEPT Context "A context is a set of statements in a formal language that are true within that context." -PURPOSE CONCEPT Context -{+ -Contexts exist in Ampersand for the purpose of dealing with truth. -Within one context there can be no contradictions. -Ampersand's way of dealing with a contradiction is either to resolve it or to separate them in different contexts. -\subsubsection*{Explanation} -The world is full of contradictions. Examples: -\begin{itemize} -\item Bob's personal income over March 2013 according to Bob's employer differs from Bob's personal income over March 2013 according to the National Tax Authority. -\item The police can be convinced that Peter X commited the crime, yet his attorney is convinced he is innocent. -\item One computer system can tell that the person with social security number 721-07-4426 was born on April 27th, 1943, while at the same time another computer system tells me this person was born on May 3rd, 1952. -\end{itemize} - -\begin{itemize} -In language philosopy, the idea of a context was invented to give truth a place. -\item In the context of the National Tax Authority, Bob's personal income over March 2013 can be computed to precisely one amount. In the context of his employment, Bob's personal income over March 2013 can be different, because that is another context. -\item The job of a court of law is to create a new truth, whose consequences (e.g. imprisonement) can be enforced by law. The court creates a new context, in which conflicts between the (different) truths of both parties are resolved by a decision of the court. -\item If two computers operate in the same context, yet disagree on matters of fact, we say there is an error. It is likely that in this example someone must step in to determine which date of birth is correct (if any). The error could be detected because we know (i.e. we have a rule that says) that a person must have a unique date of birth. -\end{itemize} - -Ampersand uses contexts to organize truth. -Within one context, there is a single truth and there are no contradictions. -For this reason, a context defines a language by means of concepts and relations, in which utterances can be made. -We say that these utterances {\emph make sense} in that context. -+} - -PURPOSE PATTERN Rules -{+The rules that govern rules are brought together in one pattern, -in order to formalize rules and determine their meaning. -+} -CONCEPT Rule "A rule is a statement that must be true in each context in which it is valid." -PURPOSE CONCEPT Rule -{+ -Rules are used as a concrete reason for people to act, feel or believe. -In philosophy, this is called a 'norm'. -\subsubsection*{Explanation} -A rule differs from a statement in that it must always be true. -Example: -\begin{itemize} -\item The statement "St. Paul street is a one way street." might be either true or false. - We just have to check the road signs on St. Paul street to know. - If, however, the city council decides that St. Paul street is a one way street, we have a rule. - It is a rule because St. Paul street must be a one way street. - As long as the appropriate road signs are absent, the situation on the street contradicts the decision of the city council. -\end{itemize} -The word 'must' implies that there is someone who says so. -In this example, the city council, by the authority invested upon it by the law, says that St. Paul street must be a one way street. -The people who are affected by this are called stakeholders. -All contexts in which this rule is valid are called the scope of this rule. -Outside its scope, a rule has no meaning. -For example a rule may be valid in downtown St. Catharines, Ontario, but totally meaningless in Smalltown, NY that does not even have a St. Paul street. -+} - -PURPOSE PATTERN Patterns -{+The rules that govern patterns are brought together in one pattern, -in order to formalize patterns and determine their meaning. -+} -CONCEPT Pattern "A pattern is a set of rules that describes a theme or a general reusable solution to a commonly occurring problem." -PURPOSE CONCEPT Pattern -{+ -Patterns are used to isolate discussions about a specific theme to a particular group of stakeholders, -who are competent to identify (define, select, invent, etc.) rules that define the theme. - -\subsubsection*{Explanation} -A pattern formalizes the agreement among stakeholders on this particular theme. -Design patterns are meant to make solutions reusable. -On top of that, Ampersand advocates "one theme in one pattern". -Stakeholders confine their discussion to one theme, and deliver the result in one pattern. -A pattern is created when a group of stakeholders is trying to agree on a solution for a particular problem. -The agreements they reach are written as rules, which are collected in a pattern. -Therefore, they are independent from a particular context. -\subsubsection*{Example} -The problem of identifying which persons have been using an information system can be solved by making rules -about log-in, users and sessions. -+} - --- Term -PATTERN Terms -PURPOSE PATTERN Terms -{+The rules that govern terms are brought together in one pattern, -in order to formalize terms and determine their meaning. -+} -CONCEPT Term "An term is a relation algebraic term, denoted in Ampersand syntax" -REPRESENT Term TYPE ALPHANUMERIC -PURPOSE CONCEPT Term -{+ -Ampersand uses relation algebra to formalize phrases. -The formalized phrases are called terms. -An Ampersand professional uses terms to calculate with language and to specify information systems and business processes. -\subsubsection*{Explanation} -An term combines relations with operators. -That results in new relations, the population of which can be calculated from the constituent parts. -This is similar to arithmetic, where for instance the result of term $(3+5)\times 2$ can be calculated from the constituent numbers. -In Ampersand, you calculate with relations rather than numbers. -\subsubsection*{Example} -The problem of identifying which persons have been using an information system can be solved by making rules -about log-in, users and sessions. -+} -ENDPATTERN - -PURPOSE PATTERN Specialization -{+Let us briefly recall, by example, what specialization is all about. -Citrus fruit comes in many colors: oranges are orange, lemons are yellow, limes are green, and grapefruits are red, yellow or a mixture of both. -Based on such an observation, we might have a concept $\id{Citrus}$, with a property $\id{color}$. -Since all limes are citrus fruits, we might have a concept $\id{Lime}$. -Every instance of $\id{Lime}$ is a small green and very sour fruit. It is not just a $\id{Lime}$, but it is a $\id{Citrus}$ as well. -This is called {\em specialization}. -The reason we call \id{Lime} a specialization of \id{Citrus} is that every lime (i.e.\ each instance of \id{Lime}) has all the properties of a citrus -and on top of that it has properties specific to limes. - -Specialization should be used on intrinsic properties only. -Ask yourself: once a lime, always a lime? If the answer is yes (which sounds right to me), you can use specialization. -Now ask yourself: once an employee, always an employee? The answer to this question is more likely to be no. -Therefore, don't use specialization to say that an employee is a person. -+} - --- Concept -PATTERN Concepts -PURPOSE PATTERN Concepts -{+The rules that govern concepts are brought together in one pattern, -in order to formalize concepts and determine their meaning. -+} ---HJO, 20150420: In het documentatie bestand moet je eigenlijk geen definities opnemen. Die moeten elders --CONCEPT A_Concept "A concept is a name for a category of similar objects." ---HJO, 20150420: In het documentatie bestand moet je eigenlijk geen definities opnemen. Die moeten elders ----CONCEPT ConceptOne "ConceptOne, also known as ONE, is a predefined concept that has the role of universal singleton" -PURPOSE CONCEPT Concept -{+ -In order to reason about meaning, -Ampersand has borrowed the idea of a "concept" from the field of semantics -(a part of the philosophy of language). -\subsubsection*{Example} -For example, the city of Amsterdam is an instance of the concept ``City''. -\subsubsection*{Explanation} -Concepts, such as City, Person, Document, Installment, and so on, -allow a designer to talk about things without having them. -We can discuss cities and persons that live in them -without referring to the actual instances of those concepts. -The distinction between an object (Amsterdam) and the corresponding concept (City) -has been studied for a long time [e.g.\ Frege, 1892] and is highly relevant for Ampersand. -+} -CONCEPT Concept "A set of things that we can talk about using the name of the concept." -ENDPATTERN - -PATTERN Populations -PURPOSE PATTERN Populations -{+The rules that govern atoms, pairs, and populations are brought together in one pattern, -in order to formalize them and determine their meaning. -+} - -CONCEPT Population "The contents of a Concept or Relation" -PURPOSE CONCEPT Population -{+ -Populations are a means to specify a number of true statements that are stored in a relation. -If an information system is generated, the population specified in an Ampersand script -is used as the initial data stored in the database. -This data can subsequently be changed by performing transactions on that database. -\subsubsection*{Example} -\begin{verbatim} - POPULATION address[Person,Address] CONTAINS - { ("Peter", "148 Browning Street") - ; ("Susan", "Dorpsstraat 78") - ; ("Bart", "2013 McGinnigall Drive") - } -\end{verbatim} -\subsubsection*{Explanation} -Populations provide the initial content of a database. - -The word {\emph population} is used sloppily for contexts as well. -It refers the the total of all populations in relations and concepts inside that context. -+} - -CONCEPT RelPopu "The content of a relation" -CONCEPT CptPopu "The content of a concept" -CONCEPT Pair "A pair is an identifier for a pair of atomic terms as an instance of an element with a sign e.g. the population of a relation or the violations of a rule" -CONCEPT Blob "A blob is a pString expected to need more than 256 characters of reserved space." -REPRESENT Blob TYPE BIGBINARY -CONCEPT String "A string is a pString expected to be less than 256 characters." ---HJO20150420: Uitgezet: CONCEPT Conid "A conid is an identifier starting with an uppercase" ---HJO20150420: Uitgezet: CONCEPT Varid "A varid is an identifier starting with a lowercase" ---HJO20150420: Uitgezet: CONCEPT ADLid "An ADLid is an identifier of type pVarid <|> pConid <|> pString" -CONCEPT Isa "An Isa, or generalization rule, represents an is-a-relation between two concepts, one of which we call specific and the other generic. It means that any atom of the specific concept is an atom of the generic concept as well." -CONCEPT IsE "An IsE, or generalization rule, is the is-relation between one concept, which is called specific, and other concepts which are called generic. It means that all atoms of the specific concepts are all atoms of the intersection set of the generic concepts. Note that if there is one generic concept, the IsE can be regarded as a synonym definition." -CONCEPT Signature "A signature is a pair of concepts, which are called source concept and target concept." -CONCEPT PropertyRule "A property rule is a rule, that is a property of a user-declared relation" -CONCEPT Property "UNI<|>TOT<|>INJ<|>SUR<|>RFX<|>IRF<|>SYM<|>ASY<|>TRN<|>PROP" -CONCEPT Relation "A relation is a set of pairs, that is characterized by a name, a source concept and a target concept." -CONCEPT Pair "A pair is an element of a relation, which has a left atom and a right atom." -ENDPATTERN - -PURPOSE PATTERN Plugs -{+Atoms are stored in pairs, pairs are stored in relations, relations are stored in plugs, and plugs are stored in databases. -To understand how (binary) relations are stored, -you may perceive a plug as a database table, in which a number of rules are being maintained. - -Plugs are defined merely for reasons of efficient storage. -Theoretically, each relation can be stored in a binary plug. -In that situation, the system will work. Such a system is likely to contain more joins to be executed, so a performance problem lures. -Ampersand tries to store multiple relations and concepts in one plug, in order to create tables with multiple columns, but with little data duplication. -The way it works is easily visualized by perceiving each plug as a single worksheet in a spreadsheet. -The first few colums are used as concept tables, in which concepts are stored that are related through generalization and specializations. -The other columns are used to store relations. -+} - -PURPOSE RULE "rule allocation" -{+In order to maintain a rule, a plug must have access to the data necessary for detecting violations. -Consequently, the information contents of a plug limits the number of rules it can maintain on its own. -+} - -PURPOSE RULE "All isas in one plug" -{+If every atom that is Lime is also Citrus, then creating a new limes must ensure that the newly made atom is a citrus too. -Similarly, deleting the lime must ensure that the atom does not remain existent as a citrus. -For this purpose, all concepts that are related through specialization or generalization are stored in the same plug. -+} - -ENDCONTEXT \ No newline at end of file diff --git a/AmpersandData/FormalAmpersand/Contexts.adl b/AmpersandData/FormalAmpersand/Contexts.adl index df5dbd638f..ec14689415 100644 --- a/AmpersandData/FormalAmpersand/Contexts.adl +++ b/AmpersandData/FormalAmpersand/Contexts.adl @@ -1,6 +1,7 @@ CONTEXT RAP IN ENGLISH INCLUDE "Rules.adl" INCLUDE "Relations.adl" +INCLUDE "Patterns.adl" VIEW Signature: Signature( TXT "[" , src;name[Concept*ConceptName] , TXT "*" , tgt;name[Concept*ConceptName] , TXT "]" ) @@ -32,6 +33,8 @@ PATTERN Context MEANING "A ContextName without Context will be removed." VIOLATION ( TXT "{EX} DelAtom;ContextName;", SRC I ) + IDENT Pattern: Pattern(name[Pattern*PatternName],context[Pattern*Context]) + RELATION name[Concept*ConceptName] [UNI,TOT] MEANING "Every relation has a name by which it can be referenced within its Context(s)." REPRESENT ConceptName TYPE ALPHANUMERIC @@ -145,45 +148,6 @@ PATTERN Validity VIOLATION (TXT "Rule ", SRC name, TXT " is not valid in context ", TGT I) ENDPATTERN -PATTERN Patterns - CONCEPT Pattern "A pattern is a container for relation declarations and rule definitions" - VIEW Pattern: Pattern(name[Pattern*PatternName]) - IDENT Pattern: Pattern(name[Pattern*PatternName],context[Pattern*Context]) - REPRESENT PatternName TYPE ALPHANUMERIC - RELATION name[Pattern*PatternName] [UNI,TOT,SUR] - MEANING "The name of a pattern." - ROLE ExecEngine MAINTAINS "del unused PatternName" - RULE "del unused PatternName" : I[PatternName] |- name~;name - MEANING "A PatternName without Pattern will be removed." - VIOLATION ( TXT "{EX} DelAtom;PatternName;", SRC I ) - - - RELATION allRules[Rule*Context] [] -- ^ all rules in the context, i.e. all user defined rules, property rules, and identity rules. - RELATION udefrules[Rule*Pattern] [] -- ^ all rules the user has declared within this pattern including the patterns it contains, - -- which are not property- and not identity rules. See ViewPoint.hs - RELATION proprules[Rule*Pattern] [] -- ^ all property rules the user has declared within a pattern. - RELATION identityRules[Rule*Pattern] [] -- ^ all identity rules the user has declared within this pattern. This contains all rules declared inside a pattern including the patterns it contains. - RELATION patRules[Pattern*Rule] -- This contains all rules declared inside a pattern. This contains all rules declared inside a pattern including the patterns it contains. - MEANING "The user-defined rules in a pattern." - RELATION declaredIn[Relation*Pattern] -- comes from class Language. This contains all relations declared inside a pattern. - MEANING "The relations that are declared in a pattern." - - ROLE ExecEngine MAINTAINS "Remove rule atom" - RULE "Remove rule atom" : I[Rule] - allRules;I[Context];allRules~ |- -V - MEANING "A rule without declaration will be removed." - VIOLATION ( TXT "{EX} DelAtom;Rule;", SRC I ) - - ROLE ExecEngine MAINTAINS "Remove relation atom" - RULE "Remove relation atom" : I[Relation] - relsDefdIn;I[Context];relsDefdIn~ |- -V - MEANING "A relation without declaration will be removed." - VIOLATION ( TXT "{EX} DelAtom;Relation;", SRC I ) - - ROLE User MAINTAINS "self-sustained rules" - RULE "self-sustained rules" : usedIn;formalTerm~;patRules~ |- declaredIn - MEANING "A relation that is used in a rule, which is declared in a pattern, must be declared in that same pattern." - -ENDPATTERN - ENDCONTEXT diff --git a/AmpersandData/FormalAmpersand/Contexts.docadl b/AmpersandData/FormalAmpersand/Contexts.docadl index 1dd64a5f9d..34ea6a1501 100644 --- a/AmpersandData/FormalAmpersand/Contexts.docadl +++ b/AmpersandData/FormalAmpersand/Contexts.docadl @@ -1,4 +1,4 @@ -CONTEXT RAP IN ENGLISH +CONTEXT FormalAmpersand IN ENGLISH PURPOSE RULE "validity of concepts in a context" {+The relation `context[Concept*Context]` represents all concepts that are valid within a context. Valid concepts can be used in the natural language and the formal language, which makes it relevant to register which concepts are valid within a context. diff --git a/AmpersandData/FormalAmpersand/Documentation.adl b/AmpersandData/FormalAmpersand/Documentation.adl index ead1822cb3..626bb4d89a 100644 --- a/AmpersandData/FormalAmpersand/Documentation.adl +++ b/AmpersandData/FormalAmpersand/Documentation.adl @@ -1,4 +1,4 @@ -CONTEXT RAP IN ENGLISH +CONTEXT FormalAmpersand IN ENGLISH PURPOSE PATTERN Documentation {+ +} diff --git a/AmpersandData/FormalAmpersand/Generics.adl b/AmpersandData/FormalAmpersand/Generics.adl index e95283950b..740ac436da 100644 --- a/AmpersandData/FormalAmpersand/Generics.adl +++ b/AmpersandData/FormalAmpersand/Generics.adl @@ -1,4 +1,4 @@ -CONTEXT Generics IN ENGLISH LATEX +CONTEXT FormalAmpersand IN ENGLISH LATEX PURPOSE CONTEXT Generics {+This context specifies the administration that currently is, and in future will have been, the contents of GENERICS.PHP+} diff --git a/AmpersandData/FormalAmpersand/Interfaces.adl b/AmpersandData/FormalAmpersand/Interfaces.adl index 7600e472d5..5846163a0c 100644 --- a/AmpersandData/FormalAmpersand/Interfaces.adl +++ b/AmpersandData/FormalAmpersand/Interfaces.adl @@ -25,8 +25,6 @@ PATTERN "Static Interface Structure" RELATION context[Interface*Context][UNI] CONCEPT Interface "An interface is a mechanism that communicates data between different (two) contexts." - IDENT Interface: Interface(name,context[Interface*Context]) - REPRESENT Origin TYPE ALPHANUMERIC RELATION ifcPos[Interface*Origin] [UNI] MEANING "The position in the file (filename, line- and column number)." diff --git a/AmpersandData/FormalAmpersand/Interfaces.docadl b/AmpersandData/FormalAmpersand/Interfaces.docadl index a2b4ecd442..6b58f839a3 100644 --- a/AmpersandData/FormalAmpersand/Interfaces.docadl +++ b/AmpersandData/FormalAmpersand/Interfaces.docadl @@ -1,4 +1,4 @@ -CONTEXT RAP IN ENGLISH LATEX +CONTEXT FormalAmpersand IN ENGLISH LATEX INCLUDE "Interfaces.adl" --! It is allowed to change texts and/or the order of texts IF AND ONLY IF this is also done in the corresponding Haskell files !-- diff --git a/AmpersandData/FormalAmpersand/Patterns.adl b/AmpersandData/FormalAmpersand/Patterns.adl index 510bef7c9a..bf474b2e87 100644 --- a/AmpersandData/FormalAmpersand/Patterns.adl +++ b/AmpersandData/FormalAmpersand/Patterns.adl @@ -1,7 +1,48 @@ -CONTEXT RAP IN ENGLISH +CONTEXT FormalAmpersand IN ENGLISH +INCLUDE "Terms.adl" +INCLUDE "Rules.adl" + PATTERN Patterns + CONCEPT Pattern "A pattern is a container for relation declarations and rule definitions" CONCEPT Pattern "A pattern is a file that is meant to contain Ampersand source code." + VIEW Pattern: Pattern(name[Pattern*PatternName]) + + REPRESENT PatternName TYPE ALPHANUMERIC + RELATION name[Pattern*PatternName] [UNI,TOT,SUR] + MEANING "The name of a pattern." + ROLE ExecEngine MAINTAINS "del unused PatternName" + RULE "del unused PatternName" : I[PatternName] |- name~;name + MEANING "A PatternName without Pattern will be removed." + VIOLATION ( TXT "{EX} DelAtom;PatternName;", SRC I ) + + RELATION allRules[Rule*Context] [] -- ^ all rules in the context, i.e. all user defined rules, property rules, and identity rules. + RELATION udefrules[Rule*Pattern] [] -- ^ all rules the user has declared within this pattern including the patterns it contains, + -- which are not property- and not identity rules. See ViewPoint.hs + RELATION proprules[Rule*Pattern] [] -- ^ all property rules the user has declared within a pattern. + RELATION identityRules[Rule*Pattern] [] -- ^ all identity rules the user has declared within this pattern. This contains all rules declared inside a pattern including the patterns it contains. + RELATION patRules[Pattern*Rule] -- This contains all rules declared inside a pattern. This contains all rules declared inside a pattern including the patterns it contains. + MEANING "The user-defined rules in a pattern." + RELATION declaredIn[Relation*Pattern] -- comes from class Language. This contains all relations declared inside a pattern. + MEANING "The relations that are declared in a pattern." + + ROLE ExecEngine MAINTAINS "Remove rule atom" + RULE "Remove rule atom" : I[Rule] - allRules;I[Context];allRules~ |- -V + MEANING "A rule without declaration will be removed." + VIOLATION ( TXT "{EX} DelAtom;Rule;", SRC I ) + + ROLE ExecEngine MAINTAINS "Remove relation atom" + RULE "Remove relation atom" : I[Relation] - relsDefdIn;I[Context];relsDefdIn~ |- -V + MEANING "A relation without declaration will be removed." + VIOLATION ( TXT "{EX} DelAtom;Relation;", SRC I ) + + ROLE User MAINTAINS "self-sustained patterns" + RULE "self-sustained patterns" : usedIn;formalTerm~;patRules~ |- declaredIn[Relation*Pattern] + MEANING "A relation that is used in a rule, which is declared in a pattern, must be declared in that same pattern." + +ENDPATTERN + +PATTERN Patterns CONCEPT Instance "An instance corresponds to an INSTANCE statement in a pattern." CONCEPT Entity "Something that refers to a definition." CONCEPT Definition "A definition is a locally defined entity." diff --git a/AmpersandData/FormalAmpersand/Patterns.docadl b/AmpersandData/FormalAmpersand/Patterns.docadl index 381d0939b5..a2d9e24bb4 100644 --- a/AmpersandData/FormalAmpersand/Patterns.docadl +++ b/AmpersandData/FormalAmpersand/Patterns.docadl @@ -1,4 +1,4 @@ -CONTEXT RAP IN ENGLISH MARKDOWN +CONTEXT FormalAmpersand IN ENGLISH MARKDOWN INCLUDE "Patterns.adl" PURPOSE PATTERN "Reusing Definitions" diff --git a/ReleaseNotes.md b/ReleaseNotes.md index 1b9065e5f2..5135b8f602 100644 --- a/ReleaseNotes.md +++ b/ReleaseNotes.md @@ -1,8 +1,13 @@ # Release notes of Ampersand +## v4.4.1 ( 10 October 2021) + +* [Issue #1212](https://github.com/AmpersandTarski/Ampersand/issues/1212) Solved issue with trailing whitespace. +* [PR #1210](https://github.com/AmpersandTarski/Ampersand/pull/1210) Partial implementation for [Issue #1189](https://github.com/AmpersandTarski/Ampersand/issues/1189). The prototype still has to be adapted, so this issue isn't closed yet. + ## v4.4.0 ( 10 September August 2021) -* PR #1201 changes to Transformers.hs for the new RAP release. +* [PR #1201](https://github.com/AmpersandTarski/Ampersand/pull/1201) Changes to Transformers.hs for the new RAP release. * [Issue #1171](https://github.com/AmpersandTarski/Ampersand/issues/1171) Duplicate labels in VIEW will now result in error, not warning. * [Issue #1204](https://github.com/AmpersandTarski/Ampersand/issues/1204) Introduction of ENFORCE statement. @@ -48,9 +53,9 @@ * [Issue #1084](https://github.com/AmpersandTarski/Ampersand/issues/1084) Add template attributes to BOX syntax * **Breaking change** Because of the implementation of feature of #1084 we could greatly reduce the number of BOX templates (e.g. ROWS, ROWSNL, HROWS and HROWSNL are merged into a single template). Documentation of new templates can be found [here](https://github.com/AmpersandTarski/prototype/tree/master/templates). This breaking change presented an opportunity to rename the built-in templates to more self explaining template names: - * ROWS -> BOX