XL: An extensible programming language

In XL, a program that prints Hello World on the terminal console output will look like this:

The first line imports the XL.CONSOLE.TEXT_IO module. The program can then use the print function from that module to write the text on the terminal console.

Why do we need the use statement? There is a general rule in XL that you only pay for things that you use. Not all programs will use a terminal console, so the corresponding functions must be explicitly imported into a program. It is possible that some systems, like embedded systems, don’t even have a terminal console. On such a system, the corresponding module would not be available, and the program would properly fail to compile.

What is more interesting, though, is the definition of print. That definition is discussed below, and you will see that it is quite simple, in particular when compared with similar input/output operations in languages such as C++.

Another interesting, if slightly more complicated version of "Hello World" is one written in the Tao3D dialect of XL that produces this result:

A program computing the factorial of numbers between 1 and 5, and then showing them on the console, can be written as follows:

We have used an alternative form of the use statement, where the imported module is given a local nick-name, IO. This form is useful when it’s important to avoid the risk of name collisions between modules. In that case, the programmer need to refer to the print function of the module as IO.print.

The definition of the factorial function shows how expressive XL is, making it possible to use the well-known notation for the factorial function. The definition consists in two parts:

That definition would not detect a problem with something like -3!. The second form would match, and presumably enter an infinite recursion that would exhaust available stack space. It is possible to fix that problem by indicating that the definition only works for positive numbers:

Writing the code that way will ensure that there is a compile-time error for code like -3!, because there is no definition that matches.

Definitions in the standard library include common fixtures of programming that are built-in in other languages, in particular well-known programming constructs such as loops, tests, and so on.

For example, the if statement in XL is defined in the standard library as follows:

Similarly, the while loop is defined as follows:

With the definitions above, programmers can then use if and while in their programs much like they would in any other programming language, as in the following code that verifies the Syracuse conjecture:

Moving features to a library is a natural evolution for programming languages. Consider for example the case of text I/O operations. They used to be built-in for early languages such as BASIC’s PRINT or Pascal’s WriteLn, but they moved to the library in later languages such as C with printf. As a result, C has a much wider variety of I/O functions. The same observation can be made on text manipulation and math functions, which were all built-in in BASIC, but all implemented as library functions in C. For tasking, Ada has built-in construct, C has the pthread library. And so on.

Yet, while C moved a very large number of things to libraries, it still did not go all the way. The meaning of x+1 in C is defined strictly by the compiler. So is the meaning of x/3, even if some implementations that lack a hardware implementation of division have to make a call to a library function to actually implement that code.

C++ went one step further than C, allowing programmers to overload operators, i.e. redefine the meaning of an operation like X+1, but only for custom data types, and only for already existing operators. In C++, a programmer cannot create the spaceship operator <=> using the standard language mechanisms. It has to be implemented in the compiler. The spaceship operator has to be added to the language by compiler writers, and it takes a 35-pages article to discuss the implications. This takes time and a large effort, since all compiler writers must implement the same thing.

By contrast, all it takes in XL to implement <=> in a variant that always returns -1, 0 or 1 is the following:

Note that this also requires a syntax file defining the precedence of the operator:

Similarly, C++ makes it extremely difficult to optimize away an expression like X*0, X*1 or X+0 using only standard programming techniques, whereas XL makes it extremely easy:

Finally, C++ also makes it very difficult to deal with expressions containing multiple operators. For example, many modern CPUs feature a form of fused multiply-add, which has benefits that include performance and precision. Yet C++ will not allow you to overload X*Y+Z to use this kind of operations. In XL, this is not a problem at all:

In other words, the XL approach represents the next logical evolutionary step for programming languages along a line already followed by highly-successful ancestors.

Putting basic features in the standard library, as opposed to keeping them in the compiler, has several benefits:

The XL standard library consists of a wide variety of modules. The top-level module is called XL, and sub-modules are categorized in a hierarchy. For example, if you need to perform computations on complex numbers, you would use XL.MATH.COMPLEX to load the complex numbers module

The library builtins is a list of definitions that are accessible to any XL program without any explicit use statement. This includes most features that you find in languages such as C, for example integer arithmetic or loops. Compiler options make it possible to load another file instead, or even to load no file at all, in which case you need to build everything from scratch.

Input/output operations (often abbreviated as I/O) are a fundamental brick in most programming languages. In general, I/O operations are somewhat complex. If you are curious, the source code for the venerable printf function in C is available online.

The implementation of text I/O in XL is comparatively very simple. The definition of print looks something like, where irrelevant implementation details were elided as …​:

This is an example of variadic function definition in XL. In other words, print can take a variable number of arguments, much like printf in C. You can write multiple comma-separated items in a print. For example, consider the following code:

That would first call the last definition of print with binding similar to what is shown below for the variable Items (simplified for clarity, details forthcoming):

This in turn is passed to write, and the definition that matches is write Head, Rest with the following bindings:

In that case, write Head will directly match write X:text and write some text on the console. On the other hand, write Rest will need to iterate once more through the write Head, Rest definition, this time with the following bindings:

The call to write Head will then match one of the implementations of write, depending on the actual type of X. For example, if X is an integer, then it will match with write X:integer. Then the last split occurs for write Rest with the following bindings:

For that last iteration, write Head will use the write X:text definition, and write Rest will use whatever definition of write matches the type of Y.

All this can be done at compile-time. The generated code can then be reused whenever the combination of argument types is the same. For example, if X and Y are integer values, the generated code could be used for the following code:

This is because the sequence of types is the same. Everything happens as if the above mechanism had created a series of additional definition that looks like:

All these definitions are then available as shortcuts whenever the compiler evaluates future function calls.

The print function as defined above is both type-safe and extensible, unlike similar facilities found for example in the C programming language.

It is type-safe because the compiler knows the type of each argument at every step, and can check that there is a matching write function.

It is extensible, because additional definitions of write will be considered when evaluating write Items. For example, if you add a complex type similar to the one defined by the standard library, all you need for that type to become "writable" is to add a definition of write that looks like:

Unlike the C++ iostream facility, the XL compiler will naturally emit less code. In particular, it will need only one function call for every call to print, calling the generated function for the given combination of arguments. That function will in turn call other generated functions, but the code sequence corresponding to a particular sequence of arguments will be factored out between all the call sites, minimizing code bloat.

Additionally, the approach used in XL makes it possible to offer specific features for output lines, for example to ensure that a single line is always printed contiguously even in a multi-threaded scenario. Assuming a single_thread facility ensuring that the code is executed by at most one thread, creating a print that executes only in one thread at a time is nothing more than:

It is extremely difficult, if not impossible, to achieve a similar effect with C++ iostream or, more generally, with I/O facilities that perform one call per I/O item. That’s because there is no efficient way for the compiler to identify where the "line breaks" are in your code.

Similarly, the C semantics enforce that a line is represented by a terminating "new-line" character. This is not the only way to represent lines. For example, each line could be a distinct block of memory, or a different record on disk. The semantics of XL does not preclude such implementations, which can sometimes perform much better.

Reactive programming is a form of programming designed to facilitate the propagation of changes in a program. It is particularly useful to react to changes in a user interface.

Tao3D added reactive programming to XL to deal with user-interface events, like mouse movements or keyboard input. This is achieved in Tao3D using a combination of partial re-evaluation of programs in response to events sent by functions that depend on user-interface state.

For example, consider the following Tao3D program to draw the hands of a clock (see complete YouTube tutorial for more details):

The locally function controls the scope of partial re-evaluation. Time-based functions like minutes, hours or seconds return the minutes, hours and seconds of the current time, respectively, but also trigger a time event each time they change. For example, the hours function will trigger a time event every hour.

The locally function controls partial re-evaluation of the code within it, and caches all drawing-related information within it in a structure called a layout. There is also a top-level layout for anything created outside of a locally.

The first time the program is evaluated, three layouts are created by the three locally calls, and populated with three rectangles (one of them colored in red), which were rotated along the Z axis (perpendicular to the screen) by an amount depending on time. When, say, the seconds value changes, a time event is sent by seconds, which is intercepted by the enclosing locally, which then re-evaluated its contents, and then sends a redraw event to the enclosing layout. The two other layouts will use the cached graphics, without re-evaluating the code under locally.

All this can be implemented entirely within the constraints of the normal XL evaluation rules. In other words, the language did not have to be changed in order to implement Tao3D.

Tao3D also demonstrates how a single language can be used to define documents in a way that feels declarative like a declarative language, i.e. similar to HTML, but still offers the power of imperative programming like JavaScript, as well as style sheets reminiscent of CSS. In other words, Tao3D does with a single language, XL, what HTML5 does with three.

For example, an interactive slide in Tao3D would be written using code like this (note that Tao3D uses import instead of use):

This can easily be mis-interpreted as being a mere markup language, something similar to markdown, which is one reason why I sometimes refer to XL as an XML without the M.

However, the true power of XL can more easily be shown by adding the clock defined previously, naming it clock, and then using it in the slide. This introduces the dynamic aspect that Javascript brings to HTML5.

In order to illustrate how pattern matching provides a powerful method to define styles, one can add the following definition to the program in order to change the font for the titles (more specifically, to change the font for the "title" layouts of all themes and all slide masters):

The result of this program is an animated slide that looks like the following:

ELFE is another XL-based experiment targeting distributed programming, notably for the Internet of things. The idea was to use the homoiconic aspect of XL to evaluate parts of the program on different machines, by sending the relevant program fragments and the associated data over the wire for remote evaluation.

This was achieved by adding only four relatively simple XL functions:

Consider the following program:

This small program looks like a relatively simple control script. However, the way it runs is extremely interesting.

This last point is worth insisting on. The following program uses the same function to compute the minimum, maximum and average temperature on the remote node. Nothing was changed to the temperature API. The computations are performed efficiently by the remote node.

To run the ELFE demos, you need to start an XL server on the machines called pi.local and pi2.local, using the -remote command-line option of XL:

You can then run the program on a third machine with:

Like for Tao3D, the implementation of these functions is not very complicated, and more importantly, it did not require any kind of change to the basic XL evaluation rules. In other words, adding something as sophisticated as transparently distributed programming to XL can be done by practically any programmer, without changing the language definition or implementation.

In that respect, XL is very much inspired by one of the earliest and most enduring high-level programming languages, Lisp. The earliest implementations of Lisp date back to 1958, yet that language remains surprisingly modern and flourishing today, unlike languages of that same era like Cobol or Fortran.

One reason for Lisp’s endurance is the metaprogramming capabilities deriving from homoiconicity. If you want to add a feature to Lisp, all you need is to write a program that translates Lisp programs with the new feature into previous-generation Lisp programs. This kind of capability made it much easier to add object-oriented programming to Lisp than to languages like C: neither C++ nor Objective C were implemented as just another C library, and there was a reason for that. Unlike Lisp, C is not extensible.

Despite its strengths, Lisp remains confined to specific markets, in large part because to most programmers, the language remains surprisingly alien to this day, even garnering such infamous nicknames as "Lots of Insipid and Stupid Parentheses". As seen from a concept programming point of view, the underlying problem is that the Lisp syntax departs from the usual notations as used by human beings. For example, adding 1 and 2 is written 1+2 in XL, like in most programming languages, but (+ 1 2) in Lisp. In concept programming, this notational problem is called syntactic noise.

XL addresses this problem by putting human usability first. In that sense, it can be seen as an effort to make the power of Lisp more accessible. That being said, XL is quite a bit more than just Lisp with a new fancy and programmer-friendly syntax.

The XL syntax is much simpler than that of languages such as C, and arguably not really more complicated than the syntax of Lisp. The parser for XL is less than 800 lines of straightforward C++ code, and the scanner barely adds another 900 lines. By contrast, the C parser in GCC needs more than 20000 lines of code, which is about the size of a complete XL interpreter, and the C++ parser is over twice as much!

A key to keeping things really simple is that the XL syntax is dynamic. Available operators and their precedence are configured primarily through a syntax file. As a result, there are no hard-coded keywords or special operators in the XL compiler.

All XL programs can be represented with a very simple tree structure, called a parse tree. The XL parse tree contains leaf nodes that don’t have any children, such as integer, real, text or symbol nodes, and inner nodes that have at least one child node, such as infix, prefix, postfix and block nodes. In general, when a node can have children, these children can be of any kind.

Leaf nodes contain values that are atomic as far as XL is concerned:

Inner nodes contains combinations of other XL nodes:

A program can directly access that source code program structure very easily, using a number of parse tree types, as shown in the following sample code, which produces text representing the internal structure of any code:

The output of this program should look like this:

The XL parse tree for any program can also be shown using the following command-line options to the xl program:

All of XL is built on this very simple data structure, and the parse tree types provide further refinements, for example distinguishing the character subtype of text, or the name subtype of symbol.

Numbers in XL begin with a digit, i.e. one of 0123456789, possibly followed by other digits. For example, 0 and 42 are valid XL numbers. XL describes two kinds of numbers: whole numbers, which have no fractional part, and fractional numbers, which have a fractional part.

A single underscore _ character can be used to separate digits, as in 1_000_000, in order to increase readability. The following are not valid XL numbers: _1 (leading underscore), 2_ (trailing underscore), 3__0 (two underscores). While this is not a requirement, it is considered good style to group digits in equal-sized chunks, for example 1_000_000 or 04_92_98_05_55.

By default, numbers are written in base 10. Any other numerical base between 2 and 36 can be used, as well as base 64 using a special syntax. Based numbers can be written by following the base with the # sign. For example 8#76 is an octal representation of 62. For bases between 11 and 36, letters A through Z or a through z represent digit values larger than 10, so that A is 10, f is 15, Z is 35. Case does not matter. For example, 16#FF and 16#ff are two valid hexadecimal representation of 255. For base 64, Base64 encoding is used, and case matters. This is mostly indended for binary data, e.g. after bits. For instance, 64#SGVsbG8h is the base-64 encoding for the number with the same binary representation as the sequence of ASCII characters in Hello!.

For fractional numbers, a dot . is used as decimal separator, and must separate digits. For example, 0.2 and 2.0 are valid but, unlike in C, .2 and 2. are not numbers but a prefix and postfix . respectively. This is necessary to avoid ambiguities. Also, the standard library denotes ranges using an infix .., so 2..3 is an infix .. with 2 and 3 as operands, representing the range between 2 and 3.

Numbers can contain an exponent, specified by the letter e or E. If the exponent is negative, then the number is parsed as a fractional number. Therefore, 1e3 is integer value 1000, but 1e-3 is the same as 0.001. The exponent is always given in base 10, and it indicates an exponentiation in the given base, so that 2#1e16 is 2¹⁶, in other words decimal value 65536. For based numbers, the exponent may be preceded by a # sign, which is mandatory if e or E are valid digits in the base. For example, 16#FF#e2 is an hexadecimal representation of decimal value 65280.

There is an implementation-dependent limit for the maximum value a number can have. This limit cannot be less than 2⁶⁴-1 for whole numbers, and less than 9.99e99 for floating-point numbers.

If a value is preceded by a + or - sign, that sign is parsed as a prefix operator and not as part of the number. For example, -2 is a prefix - with 2 as an argument. Notice that the default library definitions ensure that this prefix is evaluated to integer value -2.

This property can be verified by the program below, which exposes various cases of interest:

The various syntactic possibilities for XL numbers are only for convenience, and are all strictly equivalent as far as program execution is concerned. In other words, a program may not behave differently if a constant is spelled as 16#FF_FF or as 65535.

Version numbers and other special cases: One unsatisfactory aspect of XL number syntax is that it does not offer an obvious path to correctly represent "semantic" version numbers in the code. For example, a notation like 2.3.1 will parse as an infix . between real number 2.3 and integer 1, making it indistinguishable from 2.30.1. A similar problem exists with the representation of dates, although it is less serious, since a date like 12-05-1968 or 05/12/1968 can easily be processed correctly.

A future extension allowing the syntax file to specify new node types might enable the creation of special number formats like this. This is currently under consideration. Avoiding ambiguities is part of what makes the problem complicated.

Range limitations and numerical behaviour: Computers cannot really represent mathematical numbers. For example, the set of natural numbers is infinite, so there is no such thing as "the largest natural number". Due to hardware limitations, there is however such a thing as the largest 64-bit unsigned number. Similarly, there is no way to accurately represent real numbers in a computer, but there are at least two widely used representations called floating-point and fixed-point, and a widely implemented standard that is supported on the vast majority of modern computer platforms. XL leverages that work, and does not attempt to define real arithmetic or number representation other than by reference to the underlying floating-point implementation. XL also provides subtypes that offer some platform-independent guarantees.

Names in XL begin with an letter, followed by letters or digits. For example, MyName and A22 are valid XL names. A single underscore _ can be used to separate two valid characters in a name. Therefore, A_2 is a valid XL name, but A__2 and _A are not.

Case and delimiters are not significant in XL, so that JOE_DALTON and JoeDalton are treated identically.

Operators begin with one of the ASCII punctuation characters:

Operators longer than one character must be specified in the XL syntax file. For example, the XL syntax file defines a <= operator, but no <=> operator. Consequently, the sequence 1 <=> 2 will be parsed as (1 <= (> 2)). In order to add this operator, it is necessary to extend the syntax.

Names and operators are treated interchangeably by XL after the parsing phase, and are collectively called symbols.

Text in XL is delimited with a pair of single or double quotes. Text can contain any printable character. For example, "Hello World" or 'ABC' are valid text in XL. If the delimiter is needed in the text, it can be obtained by doubling it. For example, "He said ""Hello""" is text containing He said "Hello".

Additionally, the XL syntax file can specify delimiters for "long" text. Long text can include line-terminating characters, and only terminates when the matching delimiter is reached. By default, << and >> are long-text delimiters, so that the following is valid text:

Additional delimiters can be configured, and can be used to define specific types of text. For example, a program that often has to manipulate HTML data could allow HTML and END_HTML as delimiters, so that you could write:

Indentation in XL is significant. XL follows the off-side rule to define program blocks. There is no need for keywords such as begin and end, nor for block delimiters such as { or }. However, { and } can be used as block delimiters when needed, for example to create a block on a single line. The code below shows two equivalent ways to write the same loop:

The two ways to write the loop above are not just functionally equivalent. They also share the same parse tree structure, the only difference being the operators being used. For example, A;B is an infix ; with A on the left and B on the right, whereas individual lines are operands of an infix new-line operator. Similarly, {A} is a block containing A, and indentation is represented in the parse tree by a block delimited by indent and outdent internal symbols.

The structure of the second loop from the previous listing can be shown by the XL compiler using the -show option, as illustrated below:

A given source file must use the same indentation character, either tab or space. In other words, either your whole file is indented with tabs, or it is indented with spaces, but it is a syntax error to mix both in the same file.

Indentation within a block must be consistent. For example, the following code will cause a syntax error because of the incorrect indentation of Pray:

The operators available for XL programmers are defined by a syntax file. The same rules apply for all symbols, i.e. for names or for operators. The table given in this file uses keywords such as INFIX, PREFIX and POSTFIX to indicate if an operator is an infix, a prefix, or a postfix respectively.

This table also gives operators a precedence. For example, the following segment in the INFIX portion of the table indicates that * and / have higher precedence than + and -, so that X+Y*Z will parse as X+(Y*Z):

The precedence also indicates associativity for infix operators. Even precedences indicate left associativity, like for + and * above. This means that X * Y * Z parses as (X * Y) * Z. Conversely, right-associativity is indicated by an odd precedence, as is the case for is. This means that X is Y is Z parses as X is (Y is Z).

Enforcing different precedences for left and right associativity guarantees that it’s impossible for operators to have the same precedence, with some being left-associative and some being right-associative, which would cause parsing ambiguities. You can remember that odd values correspond to right-associativity because the rightmost bit is set, or because precedence 1 is highter than 0, which matches the fact that right-associativity takes precedence over left-associativity.

The syntax file uses a few special names:

Additional sections of the syntax file define delimiters for comment, block and text. Comment and text delimiters come in pairs.

The default syntax file specifies comments that follow the C/C++ convention, i.e. comments either start with /* and end with */ or start with // and end with a new line. The basic text separators (simple and double quotes) are not specified in the syntax file because they are used to parse the syntax file itself. The default syntax file adds << and >> as separators for multi-line text..

Block separators come in pairs and have a priority. The special names INDENT and UNINDENT are used for the indentation block. The block priority is used to give the priority of the block in an expression, but also to determine if the block contains an expression or a statement.

In the default syntax file, indentation blocks and blocks delimited by curly braces { } contain statements, whereas blocks delimited by parentheses ( ) or square brackets [ ] will contain expressions.

Binary data prefix is introduced by the keyword BINARY. By default, the bits prefix is used for that purpose.

A syntax file can define a child syntax file, which overrides the syntax when a given symbol is found.

The default syntax file contains a child syntax named C which is activated between the extern name and a following semi-colon ;. This is used to approximate C-style parsing for extern declarations, making it easier to reference C code from XL:

In addition the to the default syntax provided by the syntax file, modules can also supply a .syntax file providing the precedence of the operators that this module adds.

For example, if you want to add the spaceship operator <=> in your program, and give the same precedence as <=, namely 290, you could write a spaceship module with a spaceship.syntax file containing:

The first tweak is intended to put in XL an implicit grammatical grouping that humans apparently do. Consider for example the following:

Most human beings parse this as print (sin(X),cos(Y)), i.e. we call print with two values resulting from evaluating sin X and cos Y.

This is, however, not entirely logical. If print takes comma-separated arguments, why wouldn’t sin also take comma-separated arguments? In other words, why doesn’t this parse as print(sin(X, cos(Y))?

This shows that humans have a notion of expressions vs. statements. Expressions such as sin X have higher priority than commas and require parentheses if you want multiple arguments. By contrast, statements such as print have lower priority, and will take comma-separated argument lists. In XL, with the default syntax file, indent or {} begin a statement, whereas parentheses () or square brackets [] begin an expression.

There are rare cases where the default rule will not achieve the desired objective, and you will need additional parentheses or curly braces to enforce a particular interpretation. One important such case is what follow is if it is not a block. Consider the following declarations:

The first example parses as intended, as a statement. The second one, however, is not, despite being syntactically similar. On could want to see this parse as (exp X) -1, but in reality, it parses as exp (X-1) for the same reason that the line above parses as write ("X=", X). Another issue occurs with the body of double X, because it actually only contains the first X. The ; operator has lower precedence than is, which is useful for maps, but does not achieve the expected effect in the double definition above.

The solution to these problems is use a block on the right of is in all these cases. The correct way to write the above code is therefore:

Another special rule is that XL will use the presence of a space on only one side of an operator to disambiguate between an infix or a prefix. For example:

This rule was implemented for practical reasons, based on experience using XL in the Tao3D project.

The execution of XL programs is defined by describing the evolution of a particular data structure called the execution context, or simply context, which stores all values accessible to the program at any given time.

That data structure is only intended to explain the effect of evaluating the program. It is not intended to be a model of how things are actually implemented. As a matter of fact, care was taken in the design of XL to allow standard compilation and optimization techniques to remain applicable, and to leave a lot of freedom regarding actual evaluation techniques.

Context are a formal representation of activation records, and let us know which values are presently live, and which values are presently visible. Conventionally, in the rest of the document, we will denote CONTEXT (possibly CONTEXT1, CONTEXT2, …​) a context that is visible, and HIDDEN (possibly HIDDEN1, HIDDEN2, …​) a context that is live but not currently visible.

Just like XL source code has a well-defined parse tree representation that is accessible to programs, XL contexts also have a normalized representation called scopes and maps, which is used notably by the language implementation modules, but can also, under specific conditions, be made visible to a program.

Consider the following program:

At the point where the program evaluates the expression Z+42 inside foo, the evaluation context will look something like the following scoped expression:

In this scoped expression, the outer context contains the definitions of X and Y. A local context contains the binding for the parameters of foo Z, specifically Z is X + Y. Notice how it is necessary to have the outer context to be able to evaluate that binding correctly.

The parsing phase reads source text and turns it into a parse tree using operator spelling and precedence information given in the syntax file. This results either in a parse-time error, or in a faithful representation of the source code as a parse tree data structure that can be used for program evaluation.

Since there is almost a complete equivalence between the parse tree and the source code, the rest of the document will, for convenience, represent a parse tree using a source code form. In the rare cases where additional information is necessary for understanding, it will be provided in the form of XL comments.

Beyond the creation of the parse tree, very little actual processing happens during parsing. There are, however, a few tasks that can only be performed during parsing:

The need to process use statements during parsing means that it’s not possible in XL to have computed use statements. The name of the module must always be evaluated at compile-time.

Once parsing completes successfully, the parse tree can be handed to the declaration and evaluation phases. Parsing occurs for the entire program, including imported modules, before the other phases begin.

The rule that parsing occurs for the entire program only applies to the source code that is known before evaluation. The XL standard library features modules providing access to the underlying XL implementation (compiler or interpreter). It is possible to use these modules to dynamically evaluate XL programs. However, doing so corresponds, conceptually, to parsing or evaluating a separate program.

Both declaration and evaluation phases will process sequences, which are one of:

For example, consider the following code:

The first and last line are representing a definition of pi and circumference Radius:real respectively. The second line is made of one statement that computes circumference 5.3. There are two definitions, one statement and no type annotation in this code.

Note that there is a type annotation for Radius in the definition on the last line, but that annotation is local to the definition, and consequently not part of the declarations in the top-level sequence.

In that specific case, that type annotation is a declaration of a parameter called Radius, which only accepts real values. Sometimes, such parameters are called formal parameters. A parameter will receive its value from an argument during the evaluation. For example the Radius parameter will be bound to argument 5.3 while evaluating the statement on the second line.

The result of a sequence is the value of its last statement. In our example, the result of executing the code will be the value computed by circumference 5.3. A sequence can be made of multiple statements, which are evaluated in order. Note that XL statements are expected to evaluate as nil. Unlike C, it is a type error to have values in a middle of a sequence.

The declaration phase of the program begins as soon as the parsing phase finishes.

During the declaration phase, all declarations are stored in order in the context, so that they appear before any declaration that was already in the context. As a result, the new declarations may shadow existing declarations that match.

In the example above, the declaration phase would result in a context that looks something like:

An actual implementation is likely to store declarations is a more efficient manner. For example, an interpreter might use some hashing or some form of balanced tree. Such optimizations must preserve the order of declarations, since correct behavior during the evaluation phase depends on it.

In the case of a compiled implementation, the compiler will most likely assign machine locations to each of the declarations. When the program runs, a constant like pi or the definition of circumference may end up being represented as a machine address, and a variable such as Radius may be represented as a "stack location", i.e. a preallocated offset from the current stack pointer, the corresponding memory location only containing the value, i.e. the right-hand side of :=. Most of the type analysis can be performed at compile time, meaning that most type information is unnecessary at program run time and can be eliminated from the compiled program.

Note that since the declaration phase occurs before the execution phase, all declarations in the program will be visible during the evaluation phase. In our example, it is possible to use circumference before it has been declared. Definitions may therefore refer to one another in a circular way. Some other languages such as C require "forward declarations" in such cases, XL does not.

The parse tree on the left of is, as or : is called the pattern of the declaration. The pattern will be checked against the form of parse trees to be evaluated. The right operand of : or as is the type of the type annotation. The parse tree on the right of is is called the body of the definition.

The evaluation phase processes each statement in the order they appear in the program. For each statement, the context is looked up for matching declarations in order. There is a match if the shape of the tree being evaluated matches the pattern of the declaration. Precise pattern matching rules will be detailed below. In our example, circumference 5.3 will not match the declaration of pi, but it will match the declaration of circumference Radius:real since the value 5.3 is indeed a real number.

When a match happens, a new context is created with definitions that bind formal parameters to the corresponding argument. Such definitions are, unsurprisingly, called bindings. This new context is called a local context and will be used to evaluate the body of the definition. For example, the local context for circumference Radius:real would be:

As a reminder, Radius is a formal parameter, or simply parameter that receives the argument 5.3 as a result of binding. The binding remains active for the duration of the evaluation of of the body of the definition. The binding, at least conceptually, contains the type annotation for the formal parameter, ensuring that all required type constraints are known and respected. For example, the context contains the Redius:real annotation, so that attempting Radius := "Hello" in the body of circumference would fail, because the type of "Hello" does not match the real type.

Bindings can be marked as mutable or constant. In this document, bindings made with := are mutable, while binding made with is are constant. Since by default, an X : T annotation creates a mutable binding, the binding for Radius is made with :=.

Once the new context has been created, execution of the program continues with the body of the definition. In that case, that means evaluating expression 2 * pi * Radius in the newly created local context.

After execution of the body completes, the result of that execution replaces the statement that matched the definition’s pattern. In our example, circumference 5.3 behaves like 2 * pi * Radius in a context containing Radius is 5.3.

The process can then resume with the next statement if there is one. In our example, there isn’t one, so the execution is complete.

The type prefix can be used to announce a type, which implicitly indicates that the form has the type type:

There is also a syntactic sugar for the common case where the definition of the type is a matching form. In that case, is matching can be replaced with matches:

This syntactic sugar also applies to the interface of a type, including the definition of its features or of the types it inherits from:

Finally, the word class is a syntactic sugar for type, which can be used for type hierarchies intended to support object-oriended programming:

Using syntactic sugar for types gives the compiler additional hints that the form is intended to be used as a type in type annotations. This can be used by the compiler to:

The syntactic sugar for modules is very similar in its syntax to that of types:

The module syntactic sugar gives hints to the compiler that the declaration is used as a module. The compiler can use that information to:

The in, out and in out have a syntactic sugar, where they can be placed before a type annotation or a pattern, instead of just before the type in the type annotation.

This sugar can also be used without a type, in which case the type is assumed to be anything:

Some syntactic sugar can be used to indicate if a form is a procedure, a method, a function, an operation or if it represents data, a property or an attribute. Like other kinds of syntactic sugar, the primary intent is to make the code easier to read.

While these sugared forms are optional, they may make the code more readable, shorter or more precise. In addition, they convey additional additional information to the compiler or to a person reading the code:

Prefix names such as constant, variable, macro, generic, polymorphic, fast and small tell the compiler what is the intended usage for the definition. They may guide the compiler into favoring one possible implementation over another.

For example, consider a parameter-less name like seconds. This could be a variable holding a duration in seconds, a constant indicating the number of seconds in an hour, an operation that returns the seconds in the current time, or a function that computes the number of seconds our universe will last, which is a very lengthy computation that always returns the same value. This would best be indicated by using different syntactic sugar for the declaration of seconds:

The meaning of these words is intended as follows:

A compiler is free to emit a diagnostic if one of the conditions is not met. This is only a quality of implementation consideration. In all cases, the meaning of the declaration remains the same as far as the semantics of the language is concerned. In other words, an annotation should not change what your program does, although it may observably change how your program does it.

In order to see the effect that these modifiers may have, we can consider code that simply adds a value to itself, and see what C++ feature this may be related to:

Three forms of syntactic sugar provide storage hints:

In the following example, Counter keeps its value from one evaluation of EvaluationCounter to the next, but is not visible to any entity outside of EvaluationCounter:

In some cases, it may be useful to provide several notations for the same things. The written infix form can be used to specify additional patterns for the same implementation. This may increase readability, or help deal with properties such as commutativity.

For example, the following defines an iterative Factorial function, which gives the operation a name, while also providing the familiar N! notation for it:

The following code provides a fused multiply-add operation that is recognized whether the multiplication is on the left or on the right:

Top-level name patterns only match the exact same name.

Definitions with a top-level name pattern are called name definitions.

Name patterns that are not at the top-level can match any expression, and this does not require immediate evaluation. In that case, the expression will be bound to the name in the argument context, unless it is already bound in the current context. In that latter case, the value New of the new expression is compared with the already bound value Old by evaluating the New=Old expression, and the pattern only matches if that check evaluates to true.

Such name patterns are called wildcard parameters because they can match any expression, or untyped parameters because no type checking occurs on the matched argument.

Wildcards do not apply to the top level of a pattern, since they would be interpreted as name definitions there. For example, X is 3 will define name X and not define a pattern that matches anything and returns 3. There are use cases where it is interesting to be able to do that, for example in maps. In that case, it is necessary to use the lambda notation:

When the pattern is an infix : or as, it matches an expression if the expression matches the pattern on the left of the infix, and if the type of the expression matches the type on the right of the infix.

A type annotation as a top-level pattern is a declaration:

A type annotation as a sub-pattern declares a parameter:

Such patterns are called type annotations, and are used to perform type checking. The precedence of as is lower than :, which means that in a procedure or function, type annotations using : are used to declare the type of parameters, whereas as is used to declare the type of the expression being defined, as shown for the pattern on the left of is in the example below:

For readability, a type annotation for a name can also be matched by an assignment or a name definition with the same name as the formal parameter:

A rule called scope pattern matching makes it possible to give arguments in a different order in that case.

When the pattern is a prefix, like sin X, the expression will match only if it is a prefix with the same name, and when the pattern on the right of the prefix matches the right operand of the expression.

When the prefix is a name, definitions for such patterns are called function definitions, and the corresponding expressions are usually called function calls. Otherwise, they are called prefix definitions.

When the pattern is a postfix, like X%, the expression will match only if it is a postfix with the same name, and when the pattern on the left of the postfix matches the left operand of the expression.

Definitions for such patterns are called postfix definitions, and the corresponding expressions are usually called postfix expressions. The name or operator is sometimes called the suffix.

When the pattern is an infix, it matches an infix expression with the same infix operator when both the left and right operands of the pattern match the corresponding left and right operands of the expression.

Definitions for such patterns are called infix definitions, and the corresponding expressions are called infix expressions.

When the pattern is an infix, a prefix or a postfix, it also matches a name if that name is bound to an infix, prefix or postfix expression that would match. In that case, the bound value is said to be split to match the parameters.

When a top-level pattern is an infix like Pattern when Condition, then the pattern matches an expression if the pattern on the left of the infix matches the expression, and if the expression on the right evaluates to true after bindings

Such patterns are called conditional patterns. They do not match if the expression evaluates to anything but true, notably if it evaluates to any kind of error. For example:

When a top-level pattern is an infix like Pattern where Validation, then the pattern matches an expression if the pattern on the left of the infix matches the expression, and if the validation on the right compiles correctly after binding.

Such patterns are called validated patterns. They do not match if the evaluation of the validation fails, i.e. returns an error. Like for conditional patterns, all bindings defined in the pattern are visible in the body of the validation.

The validation is part of the interface of the pattern. This enables more precise error reporting.

The most common use case for validated patterns is to create so-called validated generic types, which are types used solely to indicate that a specific operation is available, facilitating the use of generic code.

For example, the ordered type defined by the standard library requires a comparison between values of the type, and can be defined with something like:

This can also be used to create advanced type interfaces that would be difficult to express clearly using the more common pattern syntax. To facilitate that usage, type annotations in a validation that apply to parameters bound in the pattern apply as if they were directly in the pattern.

For example, an interface for matrix multiplication can validate the dimensions and value type as follows:

When the pattern is an integer like 0, a real like 3.5, a text like "ABC", it only matches an expression with the same value, as verified by evaluating the Pattern = Value expression, where Pattern is the literal constant in the pattern, and Value is the evaluated value of the expression. Checking that the value matches will therefore require immediate evaluation.

This case applies to sub-patterns, as was the case for 0! is 1 in the definition of factorial. It also applies to top-level patterns, which is primarily useful in maps:

When the pattern is a an expression between two square brackets, like [[true]], it is called a metabox, and it only matches a value that is equal to the value computed by the metabox. This equality is checked by evaluating Pattern = Value, where Pattern is the expression in the metabox, and Value is the expression being tested.

A metabox is used in particular when a name would be interpreted as a parameter. The two declarations below declare a short-circuit boolean and operator:

By contrast, the two definitions would not work as intended, since they would simply declare parameters called true and false, always causing the first one to be evaluated for any A and B expression:

When the pattern is a block, it matches what the block’s child would match. In other words, blocks in patterns can be used to change the relative precedence of operators in a complex expression, but play otherwise no other role in pattern matching.

The delimiters of a block cannot be tested that way. In other words, a pattern with angle brackets can match parentheses or conversely. For example, [A:integer] will match 2 or (2) or {2}.

It is possible to test the delimiters of a block, but that requires a conditional pattern. For example the following code will check if its argument is delimited with parentheses:

In some cases, checking if an argument matches a pattern requires evaluation of the corresponding expression or sub-expression. This is called immediate evaluation. Otherwise, evaluation will be lazy.

When a block in a pattern defines a sequence of declarations or definitions, that block is called a parameter scope, and it can be matched by any argument scope that provides matching definitions. In that case, the definitions in the argument scope may be provided in a different order, provide additional declarations, and the scope does not need to use the same delimiters or separators:

This form is often used for data types containing a large number of parameters:

When matching a pattern, a local execution context is created that holds the bindings associated to the patterns being matched. This pattern-matching scope is used while evaluating the body of the definition.

Consider the following simple example:

As indicated earlier, the body associated to the foo pattern will evaluate with a pattern-matching scope that looks like:

This is particularly useful for structured data values and user-defined data types. In XL, types are defined by the shape of a parse tree, and that shape is typically defined using a pattern. The scoping operator can then be used on values of the type to access the pattern scope.

For example, a complex data type and the addition of complex numbers can be written as follows:

There may be multiple declarations where the pattern matches a given parse tree. This is called overloading. For example, as we have seen above, for the multiplication expression X*Y we have at least integer and real candidates that look something like:

The first declaration above would be used for an expression like 2+3 and the second one for an expression like 5.5*6.4. It is important for the evaluation to be able to distinguish them, since they may result in very different machine-level operations.

In XL, the various declarations in the context are considered in order, and the first declaration that matches is selected. A candidate declaration matches if it matches the whole shape of the tree.

For example, X+1 can match any of the declarations patterns below:

The same X+1 expression will not match any of the following patterns:

Knowing which candidate matches may be possible statically, e.g. at compile-time, for example if the selection of the declaration can be done solely based on the type of the arguments and parameters. This would be the case if matching an integer argument against an integer parameter, since any value of that argument would match. In other cases, it may require run-time tests against the values in the declaration. This would be the case if matching an integer argument against 0, or against N:integer when N mod 2 = 0.

For example, a definition of the Fibonacci sequence in XL is given below:

When evaluating a sub-expression like fib(N-1), three candidates for fib are available, and type information is not sufficient to eliminate any of them. The generated code will therefore have to evaluate N-1. Immediate evaluation is needed in order to compare the value against the candidates. If the value is 0, the first definition will be selected. If the value is 1, the second definition will be used. Otherwise, the third definition will be used.

A binding may contain a value that may itself need to be split in order to be tested against the formal parameters. This is used in the implementation of print:

In that case, finding the declaration matching print "Hello", "World" involves creating a binding like this:

When evaluating write Items, the various candidates for write include write Head, Rest, and this will be the one selected after splitting Items, causing the context to become:

A context may contain multiple identical definitions, in which case the later ones are not visible. A slightly more useful case is to have multiple definitions that are identical except for their type. In that case, a definition that requires no implicit conversion will be selected over one that does require one. An example of use would be to provide two representations for the i complex constant:

This provides a form of value-based overloading, where a form is selected over another based on the return type. This is in particular used to implement forms that may return a value or not depending on usage. This is in particular the case for assignment operators, which can either return the assigned value, or nil. The nil case is necessary when they are used as statements, because non-nil values cannot be ignored in XL.

As shown above, the declaration that is actually selected to evaluate a given parse tree may depend on the dynamic value of the arguments. In the Fibonacci example above, fib(N-1) may select any of the three declarations of fib depending on the actual value of N. This runtime selection of declarations based on the value of arguments is called dynamic dispatch.

In the case of fib, the selection of the correct definition is a function of an integer argument. This is not the only kind of test that can be made. In particular, dynamic dispatch based on the type of the argument is an important feature to support well-known techniques such as object-oriented programming.

Let’s consider an archetypal example for object-oriented programming, the shape class, with derived classes such as rectangle, circle, polygon, and so on. Textbooks typically illustrate dynamic dispatch using a Draw method that features different implementations depending on the class. Dynamic dispatch selects the appropriate implementation based on the class of the shape object.

In XL, this can be written as follows:

A single dynamic dispatch may require multiple tests on different arguments. For example, the and binary operator can be defined (somewhat inefficiently) as follows:

When applied to types, this capability is sometimes called multi-methods in the object-oriented world. This makes the XL version of dynamic dispatch somewhat harder to optimize, but has interesting use cases. Consider for example an operator that checks if two shapes intersect. In XL, this can be written as follows:

As another illustration of a complex dynamic dispatch not based on types, Tao3D uses theme functions that depend on the names of the slide theme, master and element, as in:

As the example above illustrates, the XL approach to dynamic dispatch takes advantage of pattern matching to allow complex combinations of argument tests.

In the circumference examples, matching 2 * pi * Radius against the possible candidates for X * Y expressions required an evaluation of 2 * pi in order to check whether it was a real or integer value. This is called immediate evaluation of arguments, and is required in XL for statements, but also in the following cases:

Evaluation of sub-expressions is performed in the order required to test pattern matching, and from left to right, depth first. Patterns are tested in the order of declarations. Computed values for sub-expressions are memoized, meaning that they are computed at most once in a given statement.

In the cases where immediate evaluation is not required, an argument will be bound to a formal parameter in such a way that an evaluation of the formal argument in the body of the declaration will evaluate the original expression in the original context. This is called lazy evaluation. The original expression will be evaluated every time the parameter is evaluated.

To understand these rules, consider the canonical definition of while loops:

Let’s use that definition of while in a context where we test the Syracuse conjecture:

The definition of while given above only works because Condition and Body are evaluated multiple times. The context when evaluating the body of the definition is somewhat equivalent to the following:

In the body of the while definition, Condition must be evaluated because it is tested against metabox [[true]] and [[false]] in the definition of if-then-else. In that same definition for while, Body must be evaluated because it is a statement.

The value of Body or Condition is not changed by them being evaluated. In our example, the Body and Condition passed in the recursive statement at the end of the while Condition loop Body are the same arguments that were passed to the original invokation. For the same reason, each test of N <> 1 in our example is with the latest value of N.

Lazy evaluation can also be used to implement "short circuit" boolean operators. The following code for the and operator will not evaluate Condition if its left operand is false, making this implementation of and more efficient than the one given earlier:

The bindings given in the while loop definition above for Condition and Body are somewhat simplistic. Consider what would happen if you wrote the following while loop:

Evaluating this would lead to a "naive" binding that looks like this:

That would not work well, since evaluating Condition would require evaluating Condition, and indefinitely so. Something needs to be done to address this.

In reality, the bindings must look more like this:

The notation CONTEXT1 { Condition } means that we evaluate Condition in context CONTEXT1. This one of the scoping operators, which is explained in more details below. A prefix with a context on the left and a block on the right is called a closure.

In the above example, we gave an arbitrary name to the closure, CONTEXT1, which is the same for both Condition and Body. This name is intended to underline that the same context is used to evaluate both. In particular, if Body contains a context-modifying operation like N -= 1, that will modify the same N in the same CONTEXT1 that will later be used to evaluate N > 1 while evaluating Condition.

A closure may be returned as a result of evaluation, in which case all or part of a context may need to be captured in the returned value, even after that context would otherwise normally be discarded.

For example, consider the following code defining an anonymous function:

When we evaluate add3, a binding N is 3 is created in a new context that contains declaration N is 3. That context can simply be written as { N is 3 }. A context with an additional binding for M is "Hello" could be written something like { N is 3; M is "Hello" }.

The value returned by adder N is not simply { lambda X is X + N }, but something like { N is 3 } { lambda X is X + N }, i.e. a closure that captures the bindings necessary for evaluation of the body X + N at a later time.

This closure can correctly be evaluated even in a context where there is no longer any binding for N, like the global context after the finishing the evaluation of add3. This ensures that add3 5 correctly evaluates as 8, because the value N is 3 is captured in the closure.

A closure looks like a prefix CONTEXT EXPR, where CONTEXT and EXPR are blocks, and where CONTEXT is a sequence of declarations. Evaluating such a closure is equivalent to evaluating EXPR in the current context with CONTEXT as a local context, i.e. with the declarations in CONTEXT possibly shadowing declarations in the current context.

In particular, if argument splitting is required to evaluate the expression, each of the split arguments shares the same context. Consider the write and print implementation, with the following declarations:

When evaluating { X is 42 } { print "X=", X }, Items will be bound with a closure that captures the { X is 42 } context:

In turn, this will lead to the evaluation of write Items, where Items is evaluated using the { X is 42 } context. As a result, the bindings while evaluating write will be:

The whole processus ensures that, when write evaluates write Tail, it computes X in a context where the correct value of X is available, and write Tail will correctly write 42.

A sub-expression will only be computed once irrespective of the number of overload candidates considered or of the number of tests performed on the value. Once a sub-expression has been computed, the computed value is always used for testing or binding that specific sub-expression, and only that sub-expression. This is called memoization.

For example, consider the following declarations:

If you evaluate an expression like A + foo B, then foo B will be evaluated in order to test the first candidate, and the result will be compared against 0. The test Y > 25 will then be performed with the result of that evaluation, because the test concerns a sub-expression, foo B, which has already been evaluated.

On the other hand, if you evaluate A + B * foo C, then B * foo C will be evaluated to match against 0. Like previously, the evaluated result will also be used to test Y > 25. If that test fails, the third declaration remains a candidate, because having evaluated B * foo C does not preclude the consideration of different sub-expressions such as B and foo C. However, if the evaluation of B * foo C required the evaluation of foo C, then that evaluated version will be used as a binding for Z.

Another important effect of memoization is that it limits the number of evaluation of top-level constants. In other words, a single evaluation will not "chase constants". Consider the following example:

The evaluation of sub-expression 0 happens only once, and therefore, 1 is not itself evaluated again for the same sub-expression. This is quite important to get sensible results for maps.

Unlike in several functional languages, when you declare a "function", you do not automatically declare a named entity or value with the function’s name.

For example, the first definition in the following code does not create any declaration for my_function in the context, which means that the last statement in that code will cause an error.

It is not clear how such a name would be called as a function either, since some of the arguments may themselves contain arbitrary parse trees, as we have seen for the definition of print, where the single Items parameter may actually be a comma-separated list of arguments that will be split when calling write Items and matching it to write Head, Tail.

If you need to perform the operation above, it is however quite easy to create a map that performs the operation. That map may be given a name or be anonymous. The following code example shows two correct ways to write such an apply call for a factorial definition:

Passing definitions like this might be seen as related to what other languages call anonymous functions, or sometimes lambda function in reference to Church’s lambda calculus. The way this works, however, is markedly different internally, and is detailed in the section on scoping above.

A sequence, i.e. an infix with a ; or new-line as a separator, requires immediate evaluation of its left term, and evaluates as its right term, which may be evaluated lazily.

The left term is expected to evaluate to nil. However, if it evaluates as an error value, then the sequence as a whole evaluates as that error value.

Any other return value results in a type error.

In a definition body, self refers to the input parse tree. A special idiom is a definition where the body is self, called a self definition. Such definitions indicates that the item being defined needs no further evaluation. For example, true and false can be defined as:

This means that evaluating true will return true, and evaluating false will return false, without any further evaluation. Note that you cannot write for example true is true, as true in the body is a statement, which would require further evaluation, hence an infinite recursion.

It is possible to use self for data structures. For example, in order to ensure that elements of a comma-separated list are not evaluated, you can write :

A sugar form using data is usually in that case to draw attention to this situation.

Note that the following values also evaluate as themselves:

Within the body of a definition, an implicit variable called result holds the value that will be given to the caller. For example, an iterative version of the factorial function can be written as follows:

The value returned by the body of a definition is, in order:

For example, in addition to the definition given in the previous section, a factorial can be written as follows using a return statement, although it is not quite idiomatic:

An alternate form would use the last returned value:

A definition body, or any block for that matter, may itself contain declarations, which are called nested declarations.

When the body is evaluated, a local declaration phase will run, followed by a local evaluation phase. The local declaration phase will add the local declarations at the beginning of a new context, which will be destroyed when the body evaluation terminates. The local declarations therefore shadow declarations from the enclosing context.

For example, a function that returns the number of vowels in some text can be written as follows:

This code example defines a local helper is_vowel C that checks if C is a vowel by comparing it against a list of vowels. That local helper is not visible to the outer scopes, in other words, to the rest of the program. You cannot use is_vowel X elsewhere in the program, since it is not present in the outer context. It is, however, visible while evaluating the body of count_vowels T.

Similarly, the local helper itself defines an even more local helper infix in in order ot evaluate the following expression:

While evaluating count_vowels "Hello World", the context will look something like:

In turn, while evaluating is_vowel Char, the context will look something like:

The context is sorted so that the innermost definitions are visible first, possibly shadowing outer declarations. Also, outer declarations are visible from the body of inner ones. In the example above, the body of is_vowel Char could validly refer to Count or to InputText.

A list of declarations, similar to the kind that is used in closures, is called a map and evaluates as itself. One of the primary uses for maps is to create a common scopes for the declarations that it contains. Since the declaration phase operates on entire blocks, all declarations within a scope are visible at the same time.

There are two primary operations that apply to a map:

Evaluating a closure is a prime example of map application. The context is captured by the closure in a map, and the closure itself is a prefix that corresponds to the map application. Such an expression can also be created explicitly. For example, { X is 40; Y is 2 } { X + Y } will evaluate as 42, taking X and Y from the map, and taking the declaration used to evaluate X + Y from the current context.

Another common usage for maps is to store declarations where the patterns are constant values. For example, you can use a map called digit_spelling to convert a digit to its English spelling:

With this declaration, the expression digit_spelling 3 evaluates to "three". This kind of map application is called indexing. A suggested style choice is to make the intent more explicit using square brackets, i.e. digit_spelling[4], as a nod to the syntax of programming languages such as C or C++.

When the index is an expression, for example digit_spelling[A+3] in a context where A is 2, we must evaluate A+3 in the current context augmented with the declarations in digit_spelling. In other words, the relevant context for evaluation will look something like:

The first candidate for evaluation has pattern 0. This requires immediate evaluation of expression A+3 to check if it matches the value. Naively, one might think that evaluating it requires matching once more against 0, and that the evaluation would neve terminate. However, memoization of sub-expression A+3 means that it can no longer be evaluated in the inner context.

It can still, however, be evaluted in the outer context. In that outer context, the pattern matches the X:integer+Y:integer pattern, from which it computes value 2+3, and then returns 5 for comparison in the inner context, in order to compare it against 0. Since 0=5 fails, it then considers the next candidate, but again because of memoization, there is no need to re-evaluate the value of sub-expression A+3. Instead, the computed value 5 will be compared successively against 1, 2, and so on, until it matches 5. The returned value for the inner expression is therefore "five".

A map is not restricted to constant patterns. For example, the following map performs a more complete spelling conversion for numbers below 1000.

Another common idiom is to use a named map to group related declarations. This is the basis for the XL module system. For example, consider the following declaration:

With that declaration, byte_magic_constants.num_bits evaluates to 8. A declaration like this can of course be more than a simple name:

In that case, magic_constants(4).max_values will evaluate to 15.

This is also exactly what happens when you use a module. For example, with use IO = XL.CONSOLE.TEXT_IO, a local name IO is created in the current context that contains the declarations in the module. As a result, IO.write will refer to the declaration in the module.

The context variable can be used to access the current scope at any point of the program. This can be used in particular to pass the current context to some other declaration:

In a given context, super is a way to refer to the enclosing scope.

The static name can be used to refer to a context that is specific to the current scope, but remains from one evaluation of that scope to the next.

The static sugar for declarations creates types that store their values in the static context. The above code can be written as:

The global name can be used to refer to the global context, which is a special static context shared by all modules and all scopes in the system.

The thread name can be used to refer to a per-thread global context. Like the static context, the thread context is local to the current scope.

The simplest way to handle errors is to have a variant of the function that takes an error as an argument. For example, you could extend your square root function as follows:

Now if you attempt to take the square root of an error, you will get a different output:

Another way to handle errors is to use so-called fallible types, which use the T? notation, a shortcut for T or error. The ok type is the same as nil?, and is normally used for functions that are not expected to return a value, but can return an error.

T? contains four accessible features:

The following code shows how to use a real? type to return 0.0 for the sqrt of a negative value:

A third way to handle errors is to use a try Body catch Handler form, which evaluates Body, and if Body returns an error, evaluates Handler instead. The error that was caught by catch is called caught.

With this construct, the sanitized_sqrt above can be written in a much shorter and more idiomatic way as follows:

If a statement, assignment or declaration returns an error, then as a special evaluation rule, any error value is immediately returned by the enclosing function. It is a type error if the interface of the enclosing function does not allow an error return value.

For example, in C, it is frequent to have code that looks like:

In XL, handling error values is implicit, so that code similar to the above can be written as follows:

The notation own T above is an owning type that dynamically allocates an object from the heap.

The simplest way to convert a type to another is to embed the original type in a constructor for the second type. This only works if the original type is compatible with the pattern for the second type.

In the above example, distance is both the name of the type and a prefix used as a constructor for the type. This is only coincidental, if frequent. The above example could be written using a postfix form as follows:

Rewrite the code as seen above demonstrates that what really matters is the constructor pattern, not the name of the type, which is nothing special.

Having to use a type-specific constructor pattern is not practical when writing generic code. Consider for example that you want to create a long_distance subtype that corresponds to distances greater than 1000 m

In such cases, it is possible to create an explicit conversion form that takes the target type as a prefix, using a metabox to make it clear that the type, not its name, is what you use as a prefix:

Invoking such an explicit conversion function requires you to evaluate the type separately, not as part of a prefix form. This can be done by putting the type expression in a block:

The rules of overloading are such that, in general, the parentheses are not necessary to invoke an explicit conversion. Programmers should use the parenthese form if they intend to make it clear that this is an explicit conversion, and if they want to avoid calling any prefix form with a matching name. This is also the only possible syntax if the type results form an expression. Conversely, If they want to pick up the prefix form first if it exists, then they should use the prefix form.

There are explicit conversion functions for most numerical types , which in general allows you to get the closest numerical value in the target form.

Many types also have an explicit conversion to text, which must produce a human-readable version of the value. Some types can also feature an explicit conversion from text, which can be used to parse a value given in human-readable form.

Implicit type conversions are definitions that have a single typed parameter and return a different type. For example, if you want to be able to implicitly convert between polar and cartesian form for a complex number, you would need:

A single implicit type conversion can apply to a single binding, and is only applied if there is no direct match with the original type. For example:

In a case like the one that causes an error, you can use a type hint, which is simply a sequence of explicit conversions indicating how to get from one type to another.

Implicit type conversions can also be used on return values or when evaluating statements, in order to adjust a value to what is expected in that context.

A particular usage of implicit conversions to adjust to the context is ignorable types. the ignorable T generic type provided by the standard library can implicitly convert to either T or nil so that itcan be either returned from a function or used in a statement. Its definition is roughly as follows:

An ignorable type can be used for the return value of any operation that is useful, but may safely be ignored. The most common use case for this are assignments, which are used primarily for the side effect of assigning to the target, but can also return the value of the target.

Some fundamental data types are available on all implementations, and do not require any use statement. These fundamental types are called basic types, and include the following:

Basic data types are not very precisely sized, in order to leave the implementation free to pick up a size that is maximally efficient on the target machine. For example, integer should hold 32-bit values on a 32-bit machine, and 64-bit values on a 64-bit machine.

This may adversely affect portability, and for that reason, XL also offers sized types, with a precise number of bits specified in the name. The size is appended to the type name. For example, i64 is an integer type that is guaranteed to be exactly 64-bit.

Such sized data types exist for the following base types:

Additional sizes may be provided if they are native to the target machine. For example, some DSPs feature 24-bit operations, and compilers for such machines should provide types like u24 to match.

The sized types are guaranteed to wrap around at the boundary for the given number of bits. For example, u8 holds values between 0 and 255, and will wrap around so that the next value after 255 is 0, and the value preceding 0 is 255.

When the standard sizes are not sufficient, it is easy to use integer subtypes to identify precise ranges of values, as in integer range 1..5, which only accepts values between 1 and 5, or precise number of bits, such as integer bits 24, which wraps around like a 24-bit integer value.

Some types are intended primarily as an easy way to categorize values along generally useful boundaries, and are naturally called category types. Examples include:

Category types are often used to implement generic algorithms and generic types without overly burdening the code. For example, the vector type represents a mathematical vector, and that requires a number type for the values in the vector. Similarly, the sort algorithm only works on ordered values.

In some cases, a general structure is shared by a number of data types. For example, all array types share an internal organization and provide similar features. XL features generic types to address this kind of need. Most often, generic types are declared with formal parameters, and are instantiated by supplying arguments for the required parameters.

This is particularly useful for container types, i.e. types that are primarily designed to store a possibly large number of values from some other type.

Container types include in particular the following:

Often, an algorithm will apply to all variants of a generic type. For example, consider the operation that sums all the elements in an array. Its body can be written so as to not really depend on the type or number of elements.

In order to make it easier to write such generic code, XL programmers can take advantage of a feature called true generic type, which is a way to define a type that will accept any variant of some underlying generic type. It is customary to use a name that easily relates to the generic type. For example, one can define a true generic type named array that covers all array types as follows:

This makes it possible to write true generic code that takes an array argument, as follows:

Such generic types can be equipped with attributes or functions like any other entity in XL. For example, to get the length of an array type, assuming we know how to compute the length of its index, we could write:

Wihin a same definition, a given name only matches a single type, even if the type is generic and could represent different values. For example, if we define a function that performs the sum of two arrays, the array types have to match:

If you want to have multiple distinct types in the same declaration, you need to name them indiviudally. For example, to example a Find functions that checks if a smaller array is contained in a larger one with the same value type, you can write the following:

It is possible for the pattern of the true generic type to be somewhat more restrictive. For example, for a complex type, one might want to create a type that only accepts numbers for the real type. The type some T describes all types that derive from T, so that the true generic type for complex can be defined with something like:

A true generic type with constraints like in the above example is called a constrained generic type.

Many generic types are not intended as containers. They include the following:

Computers are often used to perform mathematical operations. XL features several mathematical types designed for that purpose:

The XL.PARSER module offers a number of types intended to represent or match elements in the parse tree:

A few other types are related to program evaluation, notably:

A number of modules provide various generally useful, if more specialized types. Here are some examples:

There are many more, documented in the section about the standard library.

The lifetime of a value is the amount of time during which the value exists in the program, in other words the time between its creation and its destruction.

An entity is said to be live if it was created but not yet destroyed. It is said to be dead otherwise.

The lifetime information known by the compiler about entity X is represented as compile-time constant lifetime X. The lifetime values are equipped with a partial order <, such that the expression lifetime X < lifetime Y being true is a compiler guarantee that Y will always be live while X is live. It is possible for neither lifetime X < lifetime Y nor lifetime X > lifetime Y to be true. This lifetime feature is used to implement Rust-like restrictions on access types, i.e. a way to achieve memory safety at zero runtime cost.

The lifetime of XL values fall in one of the following categories:

For example, consider the following piece of code:

Creation is the process of preparing a value for use. The XL language rules guarantee that values are never undefined while the value is live, by calling programmer-supplied code at the appropriate times.

The lifetime of a value V begins by implicitly evaluating a creation statement create V. This happens in particular if you create a local variable without initializing it.

For example, consider the following code:

The code above is really equivalent to the following, where the implicitly-generated code has been put between parentheses:

Values in containers receive well-defined values through creation. For example, if you create an array[1..5] of complex, the 5 complex values are created before you can access them.

A create operation must take a single out argument. All the values in this out argument are themselves created before the body of the definition begins. For example, consider the following:

This code does not lead to uninitialized values, because it is really equivalent to the following:

The create operator for basic types is said to zero initialize them as follows:

The create operation can be called by the programmer, and therefore must behave correctly if it is called multiple times. This is true by default because of the rule that out parameters are destroyed before a call.

For example, if you explicitly call create as in the following code:

this is really equivalent to the following, where implicit statements are between parentheses:

The compiler may be able to elide some of these calls in such cases. Another important case where a compiler should elide creation calls is called construction, and is based on the shape defined for types. When you define a type, you need to specify the associate shape. For example, we defined a complex type as follows:

This means that a shape like complex(2.3, 5.6) is a complex. This also means that the only elementary way to build an arbitrary complex value is by creating such a shape. It is therefore not possible to have an uninitialized element in a complex, since for example complex(X, Y) would not match the shape unless both X and Y were valid real values.

However, there are contexts where it is desirable to default initialize a complex value, for example when creating a container, and this is where the create operation is necessary.

Using the shape explicitly given for the type is called the constructor for the type, and can be used in definitions or in variable declarations with an initial value. A constructor can never fail nor build a partial object. If an argument returns an error during evaluation, then that error value will not match the expected argument, except naturally if the constructor is written to accept error values.

Often, developers will offer alternate ways to create values of a given type. These alternate helpers are nothing else than regular definitions that return a value of the type.

For example, for the complex type, you may create an imaginary unit, i, but you need a constructor to define it. You can also recognize common expressions such as 2+3i and turn them into constructors.

For this, you need a syntax extension for the i postfix notation:

The fact that the only elementary way to create a type is through the constructor is illustrated by the following code:

The A:large and B:large initializations are acceptable, because it is possible to validate that the initial values match the large pattern. The C:large definition, however, is not acceptable, despite the presence of a create operation. The reason is that there is no way to create V.N, first because the type to use cannot be deduced, second because if we picked a type like integer, the default initial value 0 would not match the pattern.

The code above can be fixed, however, by using a constructor for the large type inside the creator, which means supplying a value that matches the type’s pattern. The following is an almost acceptable version of the create function:

A type implementation may be hidden in a module interface, in which case the module interface should also provide some functions to create elements of the type. The following example illustrates this for a file interface based on Unix-style file descriptors:

If the interface provides a create operation, it must be ready to accept default-created values as input in all other functions of the module. In the module above, however, the only way to get a value of the file type is by using the open function. This also means that you cannot create a variable of type file without initializing it.

When the lifetime of a value V terminates, the statement delete V automatically evaluates. Declared entites are destroyed in the reverse order of their declaration. A delete X:T definition is called a destructor for type T. It often has an in out parameter for the value to destroy, in order to be able to modify its argument, i.e. a destructor often has a signature like delete X:in out T.

Symmetrical to creation, the body of a delete V automatically invokes delete V.X for any field X in V at exit of the body of the definition.

For example, consider the definition below:

That definition is actually equivalent to the definition below:

There is a built-in default definition of that statement that has no effect and matches any value, and which only deletes the fields:

There may be multiple destructors that match a given expression. When this happens, normal lookup rules happen. This means that, unlike languages like C++, a programmer can deliberately override the destruction of an object, and remains in control of the destruction process. More importantly, this means that the destruction process respects the global type semantics.

Consider for example the deletion of the file type defined in the MY_FILE module above. Since there is a special case for negative values, that might be reflected in the implementation as follows:

However, this also means that the programmer could create a valid_file type corresponding to the case where F.fd<0 is false. If you have a valid_file value to delete, normal type system and lookup rules ensure that the second case will be selected.

Consider another interesting example, where you have the following declarations:

In this example, we create an integers type based on string of integers, for which we implement the N>0 operator to mean that all elements in the string are positive. This in turn means that some values that have type integers also have type positive. In the body of example, A is positive, but B is not.

If one consider implicit inheritance and the implicitly inserted field destruction, the code for the integers type and delete operations above is really equivalent to the following:

As a result, the output of this program should be something like:

It is possible to create local destructor definitions. When such a local definition exists, it is possible for it to override a more general definition. The general definition can be accessed using link:#enclosing context[super lookup], and generally, it should in order to preserve the language semantics.

This should output something similar to the following:

The first value being output is the temporary value created by the necessary implicit conversion of X from integer to real. Note that additional temporary values may appear depending on the optimizations performed by the compiler. The value returned by the function should not be destroyed, since it’s passed to the caller.

Any destruction code must be able to be called multiple times with the same value, if only because you cannot prevent a programmer from writing:

In that case, Value will be destroyed twice, once by the explicit delete, and a second time when Value goes out of scope. There is obviously no limit on the number of destructions that an object may go through.

Also, remember that passing a value as an out argument implicitly destroys it. This is in particular the case for the target of an assignment.

Errors in XL are represented by values with the error type, or any type that inherits from error. The error type has a constructor that takes a simple error message, or a simple message and a payload.:

The message is typically a localizable format text taking elements in the payload as numbered argument in a way similar to the format function:

A function that may fail will often have a T or error return value. There is a specific shortcut for that, T?:

For example, a logarithm returns an error for non-positive values, so that the signature of the log functions is:

If possible, error detection should be pushed to the interface of the function. For the log function, it is known to fail only for negative or null values, so that a better interface would be:

With the definitions above, the type of log X will be real if it is known that X > 0.0, error if it is known that the condition is false, and real or error, i.e. real?, in the more general case. A benefit of writing code this way is that the compiler can more easily figure out that the following code is correct and does not require any kind of error handling:

A number of types derive from the base error type to feature additional properties:

A value is said to be mutable if it can change during its lifetime. A value that is not mutable is said to be constant.

You create a mutable entity with the notation: Name:Type := Init, where Name is the name you give to the entity, Type is the type it must have over its lifetime, and Init is its initial value.

A mutable value can be referenced at most in one place at a time in the program. That place is called the owner of the mutable value. A mutable binding is a binding that transfers a mutable value. While the mutable binding is active, the mutable value is owned by the mutable binding. A mutable binding is marked by the out or inout marker.

Consider for example a Swap function that swaps its parameters. Since it needs to modify both parameters, both are marked as inout, meaning that they are both mutable.

The following code shows an example of valid use of Swap:

However, the statement Swap X, X is not valid, because X is passed to two distinct mutable bindings.

Consider the following more subtle example:

The second example is not valid, because for A[I] to be mutable, A needs to be mutable itself, so for X[2], X[3], we need to hold two mutable bindings to X at the same time.

Note that you can implement Swap for an array by swapping its elements, because if Swap receives two mutable bindings, they are necesary to two different mutable arrays.

The X:T type annotations indicates that X is a mutable value of type T, unless type T is explicitly marked as constant. When X is a name, the annotation declares that X is a variable. The X as T type annotation indicates that X is a constant value of type T, unless type T is explicitly marked as variable. When X is a name, this may declare either a named constant or a function without parameters, depending on the shape of the body.

A mutable value can be initialized or modified using the := operator, which is called an assignment. There are a number of derived operators, such as +=, that combine a frequent arithmetic operation and an assignment.

Some entities may give access to individual inner values. For example, a text value is conceptually made of a number of individual character values that can be accessed individually. This is true irrespective of how text is represented. In addition, a slice of a text value is itself a text value. The mutability of a text value obviously has an effect on the mutability of accessed elements in the text.

The following example shows how text values can be mutated directly (1), using a computed assignment (2), by changing a slice (3) or by changing an individual element (4).

None of these operations would be valid on a constant text such as Person in the code above. For example, Person[3]:='a' is invalid, since Person is a constant value.

A constant value does not change over its lifetime, but it may change over the lifetime of the program. More precisely, the lifetime of a constant is at most as long as the lifetime of the values it is computed from. For example, in the following code, the constant K has a different value for every interation of the loop, but the constant L has the same value for all iterations of I

Some data types can be represented by a fixed number of contiguous memory locations. This is the case for example of integer or real: all integer values take the same number of bytes. Such data types are called compact.

On the other hand, a text value can be of any length, and may therefore require a variable number of bytes to represent values such as "Hi" and "There once was a time where text was represented in languages such as Pascal by fixed-size character array with a byte representing the length. This meant that you could not process text that was longer than, say, 255 characters. More modern languages have lifted this restriction.". These values are said to be scattered.

Scattered types are always built by interpreting compact types. For example, a representation for text could be made of two values, the memory address of the first character, and the size of the text. This is not the only possible representation, of course, but any representation require interpreting fixed-size memory locations and giving them a logical structure.

Although this is not always the case, the assignment for compact types generally does a copy, while the assignment for scattered types typically does a move.

Computers offer a number of resources: memory, files, locks, network connexions, devices, sensors, actuators, and so on. A common problem with such resources is to control their ownership. In other words, who is responsible for a given resource at any given time.

In XL, like in languages like Rust or C++, ownership is largely determined by the type system, and relies heavily on the guarantees it provides, in particular with respect to creation and destruction. In C++, the mechanism is called RAII, which stands for Resource Acquisition is Initialization. The central idea is that ownership of a resource is an invariant during the lifetime of a value. In other words, the value gets ownership of the resource during construction, and releases this ownership during destruction. This was illustrated in the file type of the module MY_FILE given earlier.

Types designed to own the associated value are called owner types. There is normally at most one live owner at any given time for each controlled resource, that acquired the resource at construction time, and will release it at destruction time. It may be possible to release the owned resource early using delete Value.

The standard library provides a number of types intended to own common classes of resources, including:

Not all types are intended to be owner types. Many types delegate ownership to another type. Such types are called access types. When an access type is destroyed, the resources that it accesses are not disposed of, since the access type does not own the value. A value of the acces type merely provides access to a particular value of the associated owner type.

For example, if T is a text value and if A and B are integer values, then T[A..B] is a particular kind of access value called a slice, which denotes the fragment of text between 0-based positions A and B. By construction, slice T[A..B] can only access T, not any other text value. Similarly, it is easy to implement bound checks on A and B to make sure that no operation ever accesses any character value outside of T. As a result, this access value is perfectly safe to use.

Access types generalize pointers or references found in other languages, because they can describe a much wider class of access patterns. A pointer can only access a single element, whereas access types have no such restriction, as the T[A..B] example demonstrates. Access types can also enforce much stricter ownership rules than mere pointers.

The standard library provides a number of types intended to access common owner types, including:

A type is said to inherit another type, called its base type, if it can use all its operations. The type is then said to derive from the base type. In XL, this is achieved simply by providing an implicit conversion between the derived type and the base type:

As a consequence of this approach, a type can derive from any number of other types, a feature sometimes called multiple inheritance. There is also no need for the base and derived type to share any specific data representation, although this is often done in practice. For example, there is an implicit conversion from i16 to i32, altough the machine representation is different, so in XL, one can say that i16 derives from i32.

Sometimes, it is necessary to denote a type that inherits from a specific type. For example, if you want to create a constrained generic type for complex, you might want it to accept only number for its type argument. The following code is an incorrect way to do it, since it creates a type that only accept number values as an argument, i.e. it would accept complex[3.5] but not complex[real]:

To denote a type that derives from a base type, one can use the derived like base notation. The correct way to implement the above restriction is as follows, which indicates that the argument is a type, not a value, and that the type must derive from number:

The precedence of like is lower than that of :, so that the above really parses as (real:type) like number. The like operator can be applied to specify inheritance at any place in a declaration, and notably in scopes. An alternate spelling for like is inherits, which is generally more readable in global scope. For example, you can indicate that the complex type itself inherits from arithmetic (providing arithmetic operations) as well as from compact (using a contiguous memory range) as follows:

Subtyping to select a range is common enough that there is a shortcut for it. For any type with an order, subtypes can be created with the range infix operator, creating a range subtype:

With this definition, the month type can be defines simply as follows:

The infix bits operator creates a size subtype with the specified number of bits. It applies to real, integer and character types.

For example, the i8 type can be defined as:

This implicitly implies a range that depends on the type being subtyped. For example, for integer and natural, the range would be defined as follows:

The real type can be subtyped with a range and a bits size, as well as with additional constraints more specific to the real type:

A real subtype should be represented using fixed-point arithmetic if one of the following conditions is true:

For example, the hundredth type defined below could be represented internally by an natural values between 0 and 100, and converted to real by multiplying this value by the given quantum value.

The saturating prefix operator can be used on integer and real types (primarily intended for use with fixed-point subtypes) to select saturation arithmetic in case of overflow.

For example, a color_component type that has values between 0.0 and 1.0 and saturates can be defined as follows:

The character types can be subtyped with the range and bits operators:

In addition, character types can be subtyped with the following infix operators:

The text type can be subtyped with the encoding, locale and collation operators, with the same meaning as for character.

Many recent machines provide several ways to access memory, for example to deal with synchronization between multiple CPUs or between CPUs and memory-mapped devices. XL presents this kind of features as subtypes.

The following standard subtypes implement memory-related semantics:

Additional subtypes may be available to match the features of the machine the code runs on.

The interface of a type does not reveal any information on the actual implementation of the type, e.g. on the shape of the parse tree associated with it. This is called information hiding and is the primary way in XL to achieve encapsulation.

While the type interface for picture above does not give us any clue about how the type is actually implemented, it still provides very useful information. It remains sufficient to validate code that uses values of the type, like the following definition of is_square:

In that code, P is properly tagged as having the picture type, and even if we have no idea how that type is implemented, we can still use P.width and deduce that it’s an integer value based on the type interface alone.

Information hiding is specially useful in the context of modules, where the interface and implementation typically reside in different source files.

The simplest way to implement any feature of a type is to ensure that the implementation of the type has a matching feature. This is called a direct implementation of the feature.

A feature is directly implemented by providing a definition for it. For example:

In that case, type point type implementation creates a scope that contains definitions for X and Y. In other words, if P is a point, then P.X is defined by the implementation, and therefore the interface requirement for P.X is satisfied as well.

This is a particular case of the a pattern matching scope rule applied to the type implementation.

A direct implementation for the type picture interface might look like:

In a context where only the interface is visible, an expression like P.width is known to be valid because we can look it up in the interface for the picture type. However, in order to identify the implementation for P.width, we must look this expression up in a context where the implementation of picture is known. Finding an implementation definition that matches the interface definition is the mechanism underlying direct implementation of the feature.

To implement inheritance, a direct implementation is to simply reuse the existing data in the original type, possibly adding more to it. This is called data inheritance, and is implemented by using the T with Fields notation.

For example, using data inheritance to implement a colored_text that derives from the text type and adds a color, the interface might be:

An implementation using data inheritance would look like this:

As shown in the example, the fields need not be in the same order in the implementation as in the interface. In the resulting implementation type, a field named base refers to the base type on the left of with. For values of that derived type, the field base refers to the base value. Using data inheritance lets the translator automatically generate implicit conversion code that takes a derived value and returns its base. In our case, that implicit conversion would look like this:

However, the implementation may be entirely different from the interface, as long as any expression that is valid knowing the interface is valid in a context where the implementation is known. An implementation that provides an advertised feature of the interface withtout using a similar definition is called an indirect implementation of that feature.

A simple case of indirect implementation for inheritance is to provide an implicit conversion function. For example, the implementation of text may simply be defined in a scope that also features the following function:

While it is reasonable to infer from the interface that text and string of character might share a common internal representation, this is only an efficient way to provide inheritance, but it is not a constraint on the implementation.

A type may also provide entirely different implementations of its features, while still allowing individual features to be accessed almost as if they were provided by a direct implementation. We will see a number of examples in the next sections.

An interesting case is when the type delegates most of its implementation to some other type. For example, the picture type might actually be using a bitmap type as its internal representation:

Such an implementation of the picture type must perform some serious adjustments in order to delegate the work to the underlying bitmap value while providing the expected interface. Dealing with the width and height fields seems relatively straightforward:

This, however, will not work as is, because we have only provided a way to read width and height, not to write it. This does not match the interface. A simple solution would be to modify the picture interface, for example so that it reads width as size. With this interface change, the code above will correctly allow us to find an implementation for expressions such as P.width.

If, however, we still want to be able to write into width and height, the implementation must provide a way to assign to the field. The first problem here is with the notation that properly identifies this operation. The following for example does not work:

The reason it does not work is that width in the width := W pattern is a formal parameter. The metabox solution does not work in that context, since writing [[width]] := W would match the value of width, not its shape, and unless width is defined as self like true or false can be, attempting to evaluate width will not achieve the desired effect.

It is possible to resort to a more convoluted solution that intercepts assignments to width and height by using type(width) as a way to only match width, which leads to somewhat inelegant and unreadable code like:

To avoid this issue, XL provides a helper generic type called attribute T, which helps implementing an attribute of the desired type. An attribute T behaves like a T that provides get and set features, as well as support for assignments. The implementation for the picture type type can be correctly written as follows:

If P is a picture, then the width value can be read using P.width or P.width.get, and written to using P.width := W, P.width.set W or P.width W. The best method will depend on the use case. In any case, an attribute T can be used to implement a field of type T declared in the interface.

By providing as little type information as possible, the code as written above remains as generic as possible. This enables better optimizations. For instance, writing width 320 might generate only code for u16 without any need for any size value to be ever created.

Unfortunately, that code will only be accepted by the compiler until you try to use it with values that do not fit within an u16. It is accepted because it is not typed, therefore generic, so that some errors cannot be detected until you instantiate it. Furthermore, no error will be generated if the values being passed all fit within an u16.

If P is a picture, then P.width 320 will work, but P.width 1_000_000 will not, since that value is out of range for u16. This is problematic because it is quite likely that the attribute will receive some unknown size value. After all, the interface was designed for an sie, not an u16, so it makes sense to invoke it with values of this type. There will be an error in that case, because nothing in our code accepts a size value that does not fit in the u16 subtype.

This can also be fixed, but if we want to do it correctly, we need to range-check the input. One cheap and lazy way to do it is to ignore bad input and just print some run-time error.

If we instead want to return the error, then we need to expose the error in the interface, for example: