Appendix

Type Universe Grammar

TODO: Actually make this EBNF

// Top level
type_universe ::= <stmt>...
definition ::= '(' 'define' symbol <domain_definition> ')'
stmt ::=  <definition> | <transform>

// Domain
domain_definition ::= <domain> | <permute_domain>
domain ::= '(' 'domain' <type_definition>... ')'
type_definition ::= <product_definition> | <sum_definition> | <record_definition>

// Product
product_definition ::= '(' 'product' <product_body>')'
product_body ::= symbol ( symbol::<type_ref> )...

// Record
record_definition ::= '(' 'record' <record_body> ')'
record_body ::= symbol ('(' symbol ( [symbol::]<field_definition> )... ')')
field_definition ::= '(' symbol <type_ref> ')'

// Sum
sum_definition ::= '(' 'sum' symbol <variant_definition>...')'
variant_definition ::= '(' symbol (<product_body> | <record_body>) ')'

// Domain permutation
permute_domain ::=
    '(' 
        'permute_domain' symbol 
            ( 
                  '(' 'exclude' symbol... ')' 
                | '(' 'include' <type_definition>... ')'  
                | <with> 
            )...
    ')'

with ::=
    '(' 'with' symbol 
        (
              '(' 'exclude' symbol... ')' 
            | '(' 'include' ( '(' <product_body> ')' )... ')' 
        )...
    ')'
    
// Transforms
transform ::= '(' 'transform' symbol symbol ')'

// Type references
type_ref ::= ion_type
           | symbol                     
           | '(' '?' symbol ')'
           | '(' '*' symbol int ')'
    
ion_type ::= 'int' | 'symbol' | 'bool' | 'ion'     

Ion Type

When the name of a specific Ion type is used, the equivalent type in the target language is used in the generated code and the transformation code is generated to expect and produce Ion values of that type. When the name ion is used, the type of the Ion implementation's DOM node (i.e. IonElement) is used and the transformation code allows any Ion value. Today, the only reason the ion type is needed is to facilitate the lit PartiQL AST node, whose only argument is an arbitrary Ion value.

For the Kotlin language, the mapping between Ion types and Kotlin types is the same as used by ion-java. For the initial revision we will only support the following subset of Ion types which are required by the PartiQL AST, although we can expect that needs will arise for other types at a later date.

PIG Type	Kotlin Type
int	Int
symbol	String
bool	Boolean
ion	AnyElement

Arity

A type reference includes a specification of arity. Arity can be required, optional, or variadic. The name of any type without adornment indicates that it is required.

• <type_name> - Indicates that the type is required and appears exactly once.
• (? <type_name>) - Indicates that the type is optional. All optional types are represented by null when not present.
• (* <type_name> [n]) - Indicates that the type may appear at least n times. When unspecified, n is zero.

Within the list of a product's elements, the following rules must be obeyed:

• Zero or more required types must appear first. After any required types none or one of the following is allowed:
  • 1 or more optional types
  • A single variadic argument

In other words, products may have any number of required types and cannot have both optional and variadic types. If variadic type is present, only one is allowed.

These constraints exist to reduce the complexity of the generated code and its uses.