Merge pull request #696 from AmpersandTarski/development

Release 3.8.8.

.travis.yml

@@ -125,6 +125,7 @@ install:
 - chmod +x ./travis_long
 - if [ -f configure.ac ]; then autoreconf -i; fi
 - PATH=$PATH:~/.cabal/bin
+- mkdir dist
 - |
   case "$BUILD" in
     stack)
@@ -144,9 +145,20 @@ script:
 - |
   case "$BUILD" in
     stack)
-    ./travis_long stack --no-terminal $ARGS test
+    ./travis_long stack --no-terminal --test --local-bin-path=dist --copy-bins $ARGS build
       ;;
     cabal)
     ./travis_long cabal test
       ;;
   esac
+
+deploy:
+  provider: releases
+  skip_cleanup: true
+  file: dist/ampersand
+  on:
+    repo: AmpersandTarski/Ampersand
+    tags: true
+    condition: $BUILD = stack
+  api-key:
+    secure: ctc+qaMBb9wnQt9827grVDfqMDJsqgvGA3DQVo0P33B2J2XedHhn1PfRdSrZ8kdo55/658VQ4E94/quXYN7fdHbysFR+jO2b6ipTlo1alsOQ+t1B/s01nZ2QHZYkS+WD22bPWMO6ucbUsQ+NAUm44muL4GkdI4EXEIsZ3PEbHgg=

AmpersandData/FormalAmpersand/AST.adl

@@ -1,7 +1,7 @@
 CONTEXT RAP IN ENGLISH
 --! 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 !--
 INCLUDE "Concepts.adl"
---INCLUDE "AST.ifc"
+INCLUDE "AST.ifc"
 --INCLUDE "MinimalAST.xlsx" -- Contains minimal population. Anything discarded from it must violate an invariant
 INCLUDE "Contexts.adl"
 INCLUDE "Relations.adl"
@@ -20,12 +20,14 @@ INCLUDE "Interfaces.adl"
 -}
 RELATION interfaces[Context*Interface]
 RELATION name[Role*RoleName]
+REPRESENT RoleName TYPE ALPHANUMERIC
 RELATION markupText[Purpose*MarkupText]
 RELATION urlEncodedName[Concept*EncodedName]
+REPRESENT EncodedName TYPE ALPHANUMERIC
 RELATION context[Relation*Context]
-RELATION ttype[Concept*TType]
+RELATION ttype[Concept*TType][UNI]
+REPRESENT TType TYPE ALPHANUMERIC
 RELATION allRoles[Context*Role]
-RELATION sign[Expression*Signature]
 RELATION relsDefdIn[Pattern*Relation]
 RELATION maintains[Role*Rule]
 RELATION context[Population*Context]
@@ -34,12 +36,15 @@ RELATION urlEncodedName[Pattern*EncodedName]
 RELATION interfaces[Role*Interface]
 RELATION context[Population*Context]
 RELATION language[Context*Language]
+REPRESENT Language TYPE ALPHANUMERIC
 RELATION message[Rule*Message]
 RELATION origin[Rule*Origin]
+REPRESENT Origin TYPE ALPHANUMERIC
 RELATION versionInfo[Context*AmpersandVersion]
+REPRESENT AmpersandVersion TYPE ALPHANUMERIC
 RELATION urlEncodedName[Rule*EncodedName]
 RELATION context[IdentityDef*Context]
-RELATION ifcname[Interface*String]
+
 {- ******************************************** 
    *** Einde elders neer te zetten relaties *** 
    ******************************************** 

AmpersandData/FormalAmpersand/AST.docadl

@@ -10,7 +10,7 @@ INCLUDE "Rules.docadl"
 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
 {+
@@ -36,12 +36,12 @@ 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
 {+
@@ -63,12 +63,12 @@ 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
 {+
@@ -86,14 +86,14 @@ 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.
--}
++}
 
 -- Expression
 PATTERN Expressions
 PURPOSE PATTERN Expressions
 {+The rules that govern expressions are brought together in one pattern,
 in order to formalize expressions and determine their meaning.
--}
++}
 CONCEPT Expression "An expression is a relation algebraic term, denoted in Ampersand syntax"
 REPRESENT Expression TYPE ALPHANUMERIC
 PURPOSE CONCEPT Expression
@@ -109,7 +109,7 @@ 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
@@ -126,14 +126,14 @@ 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
@@ -150,15 +150,15 @@ 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
@@ -180,7 +180,7 @@ 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"
@@ -196,7 +196,6 @@ CONCEPT IsE "An IsE, or generalization rule, is the is-relation between one conc
 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 Declaration "A declaration is a statement saying there exists a relation."
 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
@@ -213,17 +212,17 @@ Ampersand tries to store multiple relations and concepts in one plug, in order t
 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

AmpersandData/FormalAmpersand/AST.ifc

@@ -53,9 +53,9 @@ BOX [ "name" : name[Rule*RuleName]
  --   , "srcConcept" : srcConcept[Rule*Concept]
     , "formalExpression" : formalExpression[Rule*Expression]
     , "sign" : sign[Rule*Signature]
-    , "maintains~ (Plug)" : maintains[Plug*Rule]~
+--    , "maintains~ (Plug)" : maintains[Plug*Rule]~
  --   , "origin" : origin[Rule*Origin]
-    , "rrviols" : rrviols
+--    , "rrviols" : rrviols
  --   , "pairView" : pairView
  --   , "message" : message
     , "meaning" : meaning[Rule * Meaning]
@@ -70,19 +70,19 @@ INTERFACE "Conjunct" FOR Ampersand : I[Conjunct] BOX
 INTERFACE "Concept" FOR Ampersand : I[Concept] BOX
     [ concept : I
     , name    : name[Concept*ConceptName]
---    , ttype   : ttype
+    , ttype   : ttype
     , "source~" : source[Relation*Concept]~ LINKTO INTERFACE Relation
     , "target~" : target[Relation*Concept]~ LINKTO INTERFACE Relation
     , "gengen~" : gengen[Isa*Concept]~
     , "genspc~" : genspc[Isa*Concept]~
 --    , "rootConcept~" : rootConcept~
-    , "src of expression~" : src[Expression*Concept]~
-    , "tgt of expression~" : tgt[Expression*Concept]~
+    , "src of expression~" : (sign[Expression*Signature];src[Signature*Concept])~
+    , "tgt of expression~" : (sign[Expression*Signature];tgt[Signature*Concept])~
     , "src of sign~" : src[Signature*Concept]~
     , "tgt of sign~" : tgt[Signature*Concept]~
 --    , "concept~" : concept~
 --    , "conceptAttribute" : conceptAttribute
-    , "in" : in[Concept*Plug]
+--    , "in" : in[Concept*Plug]
     ]
 
 INTERFACE Expression FOR Ampersand : I[Expression] cRud
@@ -168,7 +168,7 @@ BOX [ "declared in context" : declaredIn[Relation*Context]
 --	        , rAtom : rAtom
 --	        ]
 	, "valid in (context)" : valid[Relation*Context]
-	, "relsInPlug~" : relsInPlug[Plug*Relation]~
+--	, "relsInPlug~" : relsInPlug[Plug*Relation]~
     ]
 
 {-

AmpersandData/FormalAmpersand/Atoms.docadl

@@ -12,7 +12,7 @@ In fact, representations are the only things an information system can work with
 In order to unleash the available logical power of relational algebra to its maximum, 
 Ampersand is restricted to {\em representable} relation algebras.
 In this section, we describe such representations in terms of references to things that exist (atoms) and relations between such references.
--}
++}
 
 PURPOSE CONCEPT Atom
 {+People who design information systems must discuss ``things''.
@@ -27,7 +27,7 @@ An atom is a reference to
 \item some thing that (the information system 'knows' to) exist in the real world and 
 \item a representation (perception) of that thing in the information system that the atom belongs to.
 \end{enumerate}
--}
++}
 CONCEPT Atom "An atom represents a real-world thing in an information system context."
 
 PURPOSE CONCEPT Concept
@@ -41,15 +41,15 @@ For instance, we use the concept ``Car'' to denote the set of cars in a context.
 Similarly, we may use the concept ``Number'' to denote things such as 1, 2 or 101.
 Words such as ``Joy'' or ``Peace'' will not be used as a concept, as long as they do not represent a set of things.
 (Ask yourself ``Which joys are there?'' or ``Which peaces are there?'' when you doubt whether joy and peace are things to collect in a set.)
--}
++}
 CONCEPT Concept "A concept is a name to characterize a set of similar things."
 
 PURPOSE CONCEPT Relation
 {+
 In order to define a domain language, which business stakeholders can agree on, Ampersand uses relations as the basic building block of that language.
 Relations are equally useful as the basic element of a formal language, which computers can understand.
 For now, relations can be treated as a set of pairs.
--}
++}
 CONCEPT Relation "A relation is a set of pairs."
 
 PURPOSE CONCEPT Pair
@@ -58,7 +58,7 @@ In order to populate relations, atoms are assembled in pairs.
 A relation may be regarded as a set of pairs of atoms.
 In an information system, the population of relations can change because of edit actions by users in user interfaces.
 This means that pairs are inserted into and deleted from relations as time goes by.
--}
++}
 CONCEPT Pair "A pair is an element of a relation, which has a left atom and a right atom."
 
 PURPOSE RELATION repr[Atom*Representation]
@@ -83,53 +83,53 @@ and we might even realize that this atom refers to something in the real world c
 --To do so, every perception must not only be referrable (named), but also distinguishable from all other such perceptions.
 In the current version of Ampersand, every atom is represented by a finite list of UTF-8 characters.
 In future versions, other types of representation will become possible.
--}
++}
 
 PURPOSE RELATION name[Relation*Identifier]
 {+Each relation has a name, provided by the Ampersand-programmer.
 This name has no meaning in the language.
 Therefore, the Ampersand-programmer can invent a name that can serve as a reminder of the meaning or purpose of that relation.
 For example, a relation that links a bank's customers to account numbers might be called ``customerAccount'' for this very reason.
 Ampersand has the convention that relation names start with a lowercase letter.
--}
++}
 PURPOSE RELATION source[Relation*Concept]
 {+Every relation has a source concept. Let us call it $A$.
 Each atom in the left hand side of a pair in that relation, is said to be of type $A$.
--}
++}
 PURPOSE RELATION target[Relation*Concept]
 {+Every relation has a target concept. Let us call it $A$.
 Each atom in the right hand side of a pair in that relation, is said to be of type $A$.
--}
++}
 
 PURPOSE RELATION in[Pair*Relation]
 {+The pair that is stored in a relation, is linked to it by means of in.
--}
++}
 PURPOSE RELATION lAtom[Pair*Atom]
 {+The atom on the left hand side of a pair is linked to that pair via the relation lAtom.
--}
++}
 PURPOSE RELATION rAtom[Pair*Atom]
 {+The atom on the right hand side of a pair is linked to that pair via the relation rAtom.
--}
++}
 
 PURPOSE RELATION pop
 {+In order to talk about (perceptions of) real world entities that share (perceived) similar properties, or in order to specify rules, it must be possible to classify Atoms.
 We use the term 'Concept' to refer to a class of Atoms.
 We say that 'an Atom is in the population of some Concept' or alternatively 'an Atom is an element of some Concept' iff the Atom belongs to (or: is an instance of) that class.
--}
++}
 
 PURPOSE RULE "Identifiability of concepts"
 {+In order to identify and distinguish concepts, they have a name.
 Throughout the context, this name refers to that particular concept, so there cannot be two distinct concepts with the same name within a context.
--}
++}
 PURPOSE RULE "TOT in"
 {+To ensure that pairs only exist in relations, Ampersand requires the totality of in.
 This rule is automated.
 When a relation ceases to exist, the application deletes all pairs in that relation.
--}
++}
 PURPOSE RULE "SUR lAtom and rAtom"
 {+To ensure that atoms only exist in pairs, Ampersand automates the surjectivity of lAtom and rAtom.
 When an atom no longer resides in lAtom or rAtom, the application deletes that atom.
--}
++}
 
 PURPOSE RULE "equality on Atoms"
 {+
@@ -139,14 +139,14 @@ By the way, this definition of equality enables static type checking.
 The type system can guarantee that two atoms are not compared for equality unless they are in the same population.
 Under that condition, equality on atoms may be implemented on runtime by comparing representations only.
 Needless to say that this property must be proven in Ampersand's type system.
--}
++}
 PURPOSE RELATION isa[Concept*Concept]
 {+Specialization is required for the purpose of code re-use.
 Ampersand defines specialization so that type checking can be performed statically.
--}
++}
 PURPOSE RELATION isaPlus[Concept*Concept]
 {+The relation $\id{isaPlus}$ is defined as the transitive closure of $\id{isa}$.
--}
++}
 
 RELATION eq[Atom*Atom]
 RULE "equality on Atoms" : eq = repr;repr~ /\ pop;(isa\/isa~)*;pop~
@@ -156,11 +156,12 @@ MEANING "Two atoms are equal if their representations are equal and they share t
 
 PURPOSE CONCEPT Typology
 {+Merriam-Webster defines a typology as ``a system used for putting things into groups according to how they are similar''.
--}
++}
 CONCEPT Typology "a hierarchy of Concepts"
 {-
 PURPOSE RULE "Integrity of Atoms and populations"
 {+It must be ensured that the representations of ((different) perceptions of) (different) real world entities can be properly distinguished. Any pair of Atoms in the same Concept are distinct (per definition). Thus, we need a rule that expresses when two Atoms that are in different Concepts represent the same (perception of) a real world entity.
++}
 -}
 
 ENDCONTEXT