Eli User Interface Reference Manual
The objects in Eli's universe are divided into two classes, source objects and derived objects. Source objects are owned by the user of Eli, and may be manipulated in any way. Derived objects are owned by Eli; the user may inspect them or obtain copies of them on request, but has no direct access to them and cannot change them. Each derived object can be manufactured from some set of source objects, and therefore does not represent any new information.
Every object has a name. The name of a source object is its Unix file name and the name of a derived object is an odin-expression. The remainder of this chapter explains the form and meaning of an odin-expression.
Eli splits each file name into two parts: a root and a type-name. The type-name is the longest suffix of the file name that matches one of the declared source type suffixes. If no suffix match is found, the type-name is the empty string.
Lexically, an odin-expression consists of a sequence of identifier and operator tokens terminated by a newline character. An odin-expression can be continued on multiple lines by escaping each newline character with a backslash. This backslash (but not the newline) is deleted before the expression is parsed. Multiple odin-expressions can be specified on the same line by separating them with semicolons.
An identifier token is just a sequence of characters. The following characters must be escaped to be included in an identifier:
: + = ( ) / % ; ? $ < > ! <space> <tab> <newline> # \ '
A single character can be escaped by preceding it with a backslash
Unescaped white space characters (spaces, tabs, and newlines) are ignored during parsing except when they separate adjacent identifiers. A comment begins with a sharp and is terminated by the next newline character:
# this is a comment
Each comment is equivalent to white space.
An odin-expression can be surrounded by parentheses.
Parentheses are required for nested odin-expressions
(such as values of parameters) or for the empty expression
A selection expression, indicated by the slash operator,
selects a file from a directory.
The argument to the slash operator is the file name of the desired file.
For example, the following odin-expression
Any special character must be escaped.
A derivation expression, indicated by the colon operator, is used to specify a derived object. The argument to the colon operator is an object type (or product) (see Top of Products and Parameters):
sets.specs :exe sets.specs :source :names
The first line names the executable program derived from the specifications enumerated in file `sets.specs', while the second names a text file containing the names of the C files, header files and Makefile from which that program can be built.
A derived object can be a directory,
in which case it is called a derived directory.
Elements of a derived directory are selected with the
same slash operator used to select elements of source directories.
For example, if
examples/sets.specs:source/Makefile examples/sets.specs:source/driver.c examples/sets.specs:source/HEAD.h
A parameterization expression, indicated by the + operator, extends an object with additional information that affects the derived objects produced from that object. The argument to the + operator is a parameter type (see Top of Products and Parameters), optionally followed by an = operator and a value consisting of a sequence of one or more identifiers and parenthesized odin-expressions:
test +cmd=(sets.specs +fold :exe) +cmd=data :run test +cmd=(sets.specs +fold :exe) data :run test +cmd=(sets.specs +fold=' ' :exe) data :run test +cmd=(sets.specs +fold :exe) +cmd=data +cmd=data :run
(We shall see that all of these lines are equivalent.)
If the parameter value is omitted,
it is equivalent to specifying the identifier consisting of a single space
The parameter values of a given parameter type in an odin-expression form an ordered set, where the order of the values is the order specified in the odin-expression. If multiple copies of the same parameter value appear, only the first of the multiple copies is kept. The parameter value lists of each parameter type are disjoint, therefore, the order of parameters of different types is not significant.
If a parameter has a value that is a sequence, that value is only considered the same as another identical sequence. Thus the following odin-expression is not equivalent to those given above:
test +cmd=(sets.specs +fold :exe) data +cmd=data :run
Frequently, several odin-expressions share a common set of parameters. To support this kind of sharing, a parameterization expression can take the form of a + followed by a parenthesized odin-expression. The common set of parameters are then stored in the file named by the odin-expression. For example, suppose the file `my.prms' contained the text:
+debug +lib_sp=(/local/lib) +monitor +fold
sets.specs +(my.prms) :exe sets.specs +debug +lib_sp=(/local/lib) +monitor +fold :exe