Documentation
  • Introduction
  • Why Ampersand?
    • The Business Rules Manifesto and Ampersand
  • Tutorial
    • Example system: Enrollment
    • Conceptual Model: Enrollment
    • Your tool: RAP4
    • Making your first Ampersand script
  • Reactive programming
  • The language Ampersand
    • How to read syntax statements
    • Truth
    • Atoms
    • The CONCEPT statement
    • The RELATION statement
    • The MEANING statement
    • The PURPOSE statement
    • The CLASSIFY statement
    • The RULE statement
    • Terms
      • Semantics
      • Semantics in logic
        • Primitive terms
        • Boolean operators
        • Relational operators
        • Residual operators
      • Semantics in natural language
        • Primitive terms in natural language
        • Boolean operators in natural language
        • Relational operators in natural language
        • Residual operators in natural language
      • Semantics in sets
        • Primitive terms in set theory
        • Boolean operators in set theory
        • Relational operators in set theory
      • Semantics of terms, defined algebraically
        • Boolean operators in algebra
        • Relational operators in algebra
      • Semantics visualized
        • Semantics of boolean operators visualized
        • Semantics of relational operators visualized
        • Semantics of residuals visualized
    • Context
    • Module
    • Best Practices
    • Syntactical Conventions
      • The CONCEPT statement
      • The RELATION statement
      • The RULE statement
      • The CONTEXT statement
      • The INCLUDE statement
      • Explanation
      • Patterns
      • Population
        • Population in spreadsheets
      • The PURPOSE statement
      • The IDENT statement
      • The TABLE statement
      • Language support
    • The INCLUDE statement
    • Patterns
    • Services
      • Example: Client
      • Example: Login
      • Syntax and meaning
      • Explanation
      • Layout of user interfaces
        • Your own widgets (HTML and CSS)
      • CRUD
    • Population
      • Population in spreadsheets
    • The ENFORCE statement
    • The IDENT statement
    • The TABLE statement
    • Language support
    • Current date
    • The Preprocessor
    • Design considerations
  • Running the Ampersand compiler
    • Configuration
    • Commands (vs. 4.0.0 and later)
    • Options (up to vs. 3.17.4)
  • Architecture of an Ampersand Application
    • Backend framework
    • Hooks
    • Extensions
      • The ExecEngine
  • Deploying your Ampersand script
    • Compiler
    • Deploy your own web application on your laptop
    • Prototype multi-stage build
    • Prototype database
  • Reusing Available Modules
    • Modules
    • Security
    • SIAM (Sessions, Identity and Access Management) Module
  • Exercises
    • Delivery
    • VOG (in Dutch)
  • Installing Ampersand
    • Deploying your Prototype
    • Installing the tools manually
  • Modeling
    • Domain Driven Design
    • Data modeling
    • Legal modeling
    • Architecture modeling
    • Metamodeling
    • Limitations of Ampersand
  • Configuring your application
  • The Excel Importer
  • Plans
    • Current State
    • NoSQL storage
    • API documentation
    • OWL and RDFS input
    • Refactor the front-end
  • Research
Powered by GitBook
On this page
  • Disclaimer
  • Purpose
  • Syntax
  • Semantics by example
  • Practice
Export as PDF
  1. The language Ampersand

The TABLE statement

Disclaimer

This statement will be available in Ampersand vs. 4.

Purpose

This statement provides syntactic sugar for defining tabular information conveniently. It introduces a number of relations and rules in a single statement, to simplify a script.

Syntax

`TABLE` <Concept> `(` (<term> `:` <Concept> <Multiplicities>?)* `)`

where:

  • <label> is the name of the rule. It can be a single word or a string (enclosed by double brackets). It is followed by a colon (:) to distinguish the label from the concept that follows.

  • <Concept> is the name of the Concept for atoms of which the rule specifies an identity

  • Between brackets are terms whose source concept must be <Concept>. This is enforced by the type system.

Semantics by example

TABLE  C (e1:C1, e2:C2)

translates into the following declarations:

RELATION E1[C*C1]
RELATION E2[C*C2]

Multiplicity annotations are allowed. For example:

TABLE  C (e1:C1[UNI,TOT], e2:C2, e3:C[ASY], ...)

translates into the following declarations:

RELATION E1[C*C1] [UNI,TOT]
RELATION E2[C*C2]
RELATION E3[C*C] [ASY]
...

Practice

This statement makes nice combinations with the IDENT statement. For example to define two identities for persons:

TABLE Person(name:String, ssn:SSN, birthplace:City, birthdate:Date)
IDENT Person(ssn)
IDENT Person(name,birthplace,birthdate)

This states that a person is uniquely defined by ssn, but also by the combination of name, birthplace, and birthdate. This statement can also be used to objectify (reify) an term e

TABLE T(pi:P, rho:R)
IDENT T(pi,rho)
RULE "Create T" : e |- pi~;rho
RULE "Delete T" : pi~;rho |- e

If a user is tempted to replace the Create/Delete pair with a single equivalence, this becomes:

TABLE T(pi:P, rho:R)
IDENT T(pi,rho)
RULE e = pi~;rho
PreviousThe IDENT statementNextLanguage support

Last updated 3 years ago