There is a wide spectrum of possibilities for moving XML support from the API level into a first-class language feature. Currently the most popular technique is to use some form of mapping from XML to the host language. There exist a plethora of such databinding tools (see http://www.research.avayalabs.com/user/wadler/xml/ for a list of links), the Microsoft .NET environment contains a tool called xsd.exe that can translate between XSD schema and CLR types [xsd.exe]; for Java there is the JAXB tool [JAXB]. BEA XMLBeans is an interesting hybrid that allows the API approach and the databinding approach to coexist [XMLBeans].

Using these tools we can, for example, map an XSD schema for orders and items into a corresponding set of classes and then program against them in the following way:

  int GetTotalByZip(orders d, int zip) {
    ArrayList items = new ArrayList();
    foreach(order o in d){ if(o.zip == zip) items.Add(o.item); }
    int total = 0;
    foreach (item x in items) total += x.price*x.quantity;
    return total;
  }

The main advantage is that via the mapping XML values are represented in the strongly typed world of C#. It is perhaps also worth pointing out that this code would be further improved with the use of generic collections. These will soon be added to both C# and Java.

This mapping technology works reasonably well, but in practice we find that there are some annoying mismatches that makes this technology harder to use than might have been expected. In essence this mapping technique is dodging the fundamental impedance mismatch between XML and the host language. As we will see later, there is often no natural counterpart in C# (or Java) for many XSD constructs and vice versa. In fact the XPath/Infoset data-model and the usual object data-models have very little in common.

One final problem: even after the mapping of XSD schema into classes, we can see clearly in the example code that we have nothing as high-level and expressive as XQuery/XPath in C#. Thus queries have to be written using lower-level loops and conditionals. Whilst C# ensures that this is done type correctly, the resulting code is verbose and hard to maintain. Hence even if there was a perfect mapping between XML and objects at the type-level, we still would lack the expressive power of path expressions in the object-oriented programming language.

In conclusion, we can see that this "databinding" approach boils down to hiding XML instead of embracing it. We are interested in finding a clearer solution. In order to successfully promote XML support from the API to the language level we shall first compare both models carefully. After this comparison we will argue that the inherent impedance mismatch between the XML and object data-models suggests that we should both modify the host object language to enhance XML support and compromise full XML fidelity. This leads to an elegant language design that incorporates the strengths of both data-models within a coherent whole: a language ideal for circles, triangles and rectangles.

Probably the deepest and most fundamental difference between the XML and the object data-model is that the former assumes node-labelled trees/graphs (see page 33 of [Data On The Web]) while the latter assumes edge-labelled trees/graphs. This clearly represents a profound dichotomy between the two worlds, yet at best many people seem unaware of this difference, and at worst confuse the two.

To make the clash concrete, consider the following simple schema for a Point element that contains x and y child elements:

    <element name="Point">
      <complexType>
        <sequence>
          <element name="x" type="integer" /> 
          <element name="y" type="integer" /> 
        </sequence>
      </complexType>
    </element>

Assuming the XML data-model, selecting the x child of a Point element p returns an element node with name x, parent p, type integer and a single text node as a child node. Note that the type of the result is not string, but an element node that has as one of its properties the type of its content. Elemements are also types, types that describe the structure of nodes. It is a common misconception not to consider elements as proper types.

Most people, including the authors of section 5 of the original SOAP specification (http://www.w3.org/TR/SOAP/), believe that the above element declaration for Point corresponds to the following class declaration in the object world:

    class Point {
      public int x;
      public int y;
    }

In this case, selecting the x field of a Point instance p returns an integer that has no name, parent, or any of the other properties that the "corresponding" element node has in the XML world. Also note that the top level element Point is mapped to a corresponding type Point, whereas the nested elements x and y are mapped to fields x and y, which are not types by themselves.

In general, the different node types such as document, element, attribute, text, processing instructions, comments, and the properties of such nodes such as base-uri, node-name, parent, type, children, attributes, namespaces, nilled as exposed in the XPath data-model do not necessarily correspond to anything in the familiar object data-model. In other words triangles can't easily be made into circles.

In the XML world, there is an important distinction between elements and attributes. That distinction simply does not exist in the object world. For example, consider adding an attribute <attribute name="Color" type="string"/> to our example element Point above. This becomes an item in the attributes collection of a Point element p, which is distinct from the children collection and is accessed in XPath using the attribute instead of the child axis.

In the corresponding mapped class, Color would simply be represented using another field, no different from x and y. In particular it is accessed using normal member access; there is no equivalent of the axis. To ensure correct representation the fields denoting attributes should be restricted to primitive (simple) types, but that would require a rather ad-hoc extension to the object data-model. Finally, concepts like global attributes and attribute groups seem difficult to model if we assume that attributes are modelled as class members.

In the XML data-model a distinction is often made between elements and attributes on the one hand and simple and complex types on the other hand. However this is a little misleading because element and attribute declarations actually define types. Perhaps a clearer and more meaningful distinction is that XSD has stratified the world into two parts: elements and attributes to describe the nodes in the data model, and simple and complex types to describe the content of those nodes.

In the object-oriented world, this distinction is not usually made; indeed there is no mechanism to describe the structure of the members of a class declaration in isolation. Hence this is another difference between the two data-models.

Unfortunately this difference leads to further problems with the mapping tools. As we noted earlier global element declarations and complex type declarations are mapped to classes, and local element declarations to field declarations inside these classes. The problem is now how to handle element references; they have no natural counterpart in the object data-model.

    <element name="Line">
      <complexType>
        <sequence>
          <element ref="Point" /> 
          <element ref="Point" /> 
        </sequence>
      </complexType>
    </element>

The rather clumsy solution chosen by databinding tools is to replace the element references with a copy of the actual element declaration it refers to.

In the XML data-model, a complex type is permitted to have several occurrences of the same child element. Consider, for example, the following declaration of a Verse element which has two A and two B children in a specific order:

    <element name="Verse">
      <complexType>
        <sequence>
          <element name="A" type="string" /> 
          <element name="B" type="string" /> 
          <element name="B" type="string" /> 
          <element name="A" type="string" /> 
        </sequence>
      </complexType>
    </element>

At this point the mapping of elements to fields breaks down as most object-oriented languages do not allow duplicated fields. The automatic mapping tools generally pick some ad-hoc way out -- for example, the xsd.exe tool will "invent" arbitrary new field names for the duplicate elements. Clearly this is a fragile and unsatisfactory solution.

XSD allows element declarations to use anonymous types, rather than insisting that they all use named types. This immediately begs the question of how to resolve type equivalence of two elements using anonymous types: is it by structural equivalence or nominal equivalence? Rather depressingly the various XML specifications have not been terribly consistent nor stable on this matter. For example, the May 2003 XQuery and XPath data-model specification implies that every occurrence of an anonymous type is assigned an implementation-defined, globally unique type name.

   <element name="Foo">
      <complexType>
        <sequence>
          <element name="Bar" > 
            <complexType>
              <sequence>
                <element name="x" type="integer"/> 
              </sequence>
          </complexType>
        </element> 
        <element name="Baz" > 
          <complexType>
            <sequence>
              <element name="x" type="integer"/> 
            </sequence>
          </complexType>
        </element> 
      </sequence>
    </complexType>
  </element>

Given the declarations above, the type properties of a Bar node and of a Baz node would be different as each would be assigned a separate globally unique type name.

From a programming language perspective this is an unusual choice. A more meaningful approach would be to employ structural type equivalence for anonymous types. Of course, if the data-model only supports nominal type equivalence then we are left in a difficult situation when dealing with anonymous types. However, our opinion is that a solution that generates unique type names on the fly is an unsatisfactory one. In that case it is better to disallow anonymous types from the start.

XSD supports two forms of "inheritance": substitution groups for elements, and derivation by extension/restriction for complex and simple types. These two forms of inheritance are strangely intertwined where elements can only be in the same substitution group if their content types are related by derivation. This restriction reflects, as we have stated earlier, that complex/simple types describe the content of nodes.

Most object-oriented languages only support what would roughly amount to derivation by extension: a subclass can add new fields and methods. However most languages also permit a subclass to hide or override members of the superclass. This unfortunately has no counterpart in the XML data-model; it is another mismatch.

XSD distinguishes between simple types and complex types. At first glance simple types seem to correspond to primitive types in Java or C#. However, simple types in XSD can be derived from other simple types in order to further restrict the possible values of that type. Unfortunately primitive types in most object-oriented languages are sealed (final), and cannot be further specialized. The correspondence is again imperfect.

Another fundamental difference between the XML and the object data-models is that the former adopts a closed-world assumption with respect to substitution groups and derivation by extension/restriction. For example the XQuery typing rules assume that all elements of a substitution group are known when performing (static) type-checking of child access [The Essence of XML]. On the other hand an important feature of the object data-model is that it adopts an open-world assumption. When type-checking member access only the static type of the receiver type is assumed.

In the XPath data-model, namespace nodes exist as first-class values (although subsequently XPath 2.0 has deprecated the use of name-spaces as first class values). This is not the case in the usual object data-model. For example in C# namespaces are purely syntactic sugar; from the point of view of the underlying runtime they don't exist.

In so far as the notion of namespaces exists in C#, the places where namespaces can be introduced, the places where qualified names can be used, and the actual first class status of namespaces, are much more restricted than in XML. For instance in C# or Java field names are never qualified. Again a feature in both models that at the surface appeared related has turned out to be different.

In XSD occurrence constraints appear on element declarations, not on the underlying type of the children of that element. For instance, the element declaration for element A below states that Foo has at most 10 children named A:

   <element name="Foo">
      <complexType>
        <sequence>
          <element name="A" type="string" maxOccurs="10"/> 
          <element name="B" type="string"/> 
        </sequence>
      </complexType>
    </element>

This is a natural thing to do when you consider elements as types. However, there is nothing that directly corresponds to this in the object data-model given that local element declarations are mapped to fields. Instead Foo would be expected to be mapped to a class that has a single field A of type string[]:

  class Foo {
    string[] A;
    string B;
  }

This means something completely different! Class Foo has one member whose type is an array of string instances. As well as the obvious mismatch, there is nothing to restrict the size of the array, and Foo can have any number of A children.

The mismatch becomes even more pronounced once we start putting occurrence constraints on the sequence, choice, or all particles, such as in the example below. There are no simple counterparts in the object data-model.

  <element name="Foo">
    <complexType>
      <sequence maxOccurs="10">
        <element name="A" type="string"/> 
        <element name="B" type="string"/> 
      </sequence>
    </complexType>
  </element>

The idea of mixed content reflects the schizophrenic nature of XML as data versus XML as documents.

  <element name="Bar">
    <complexType mixed="true">
      <sequence>
        <element name="A" type="integer" maxOccurs="10"/> 
      </sequence>
    </complexType>
  </element>

The children of the element instance <Bar>aaa<A>0</A>bbb<A>1</A>ccc</Bar> would be a text node, an element node A, a text node, an element node A and another text node. Since objects represent data not documents, there is no natural interpretation for mixed content in the object world.

The detailed examples in the previous section demonstrate that at a foundational level there is a significant gulf between the XML and object data-models [Impedance Mismatch]. In our opinion the impedance mismatch is too big to attempt a complete integration.

Given these problems, how are we to proceed? Our approach is to first take as our starting point the object data-model of our programming language. This is the model that programmers are familiar with, and that is supported by the underlying execution engine. Rather than trying to blindly integrate the complete XML data-model and the full complexity of schemas, we shall take a simpler design goal: We consider XML 1.0 [XML 1.0] as simply syntax for serialized object instances. We shall see in the rest of this paper the significant design advantages that follow from such a simple intuition.

Take the following XML fragment:

  <Point>
    <x>46</x>
    <y>11</y>
  </Point>

We consider this to simply denote the XML serialization of an object of type Point, say p, that is constructed via the series of assignments Point p = new Point(); p.x = 46; p.y = 11. Even though the XML fragment is a valid instance of an Point element according to the XSD schema we gave earlier, none of the XML data-model properties will be exposed at the level of the programming language; the programmer just sees an instance of class Point.

Even though we have adopted a simple view of XML, in fact the object data-model and the corresponding type-system is not powerful enough to handle the rich scenarios that we envisage. In order to consume and generate a wide enough set of documents we need to enrich the type system with new type constructors such as unions, sequences and streams. These have been carefully chosen and designed so that they integrate coherently with the existing type system. Interestingly, the resulting types look very similar to Relax NG compact notation (http://www.oasis-open.org/committees/relax-ng/compact-20020607.html), or DTDs written using XSD keywords.

We define XML fidelity as being able to serialize and deserialize as many possible documents that are expressible by some given XML schema language (http://www.xml.com/pub/a/2001/12/12/schemacompare.html), not as how closely we match one of the XML datamodels in our programming language once we have parsed an XML document. Although Xen by design doesn't support the entirety of the full XML stack, we believe that our type system and language extensions are rich enough to support many potential scenarios. For example we are able to cover the complete set of XQuery Use Cases [XQuery Use Cases], and we have written several large applications, some of them up to 50,000 lines, without running into significant fidelity problems.

In this section we give some details of the Xen type system. Despite its considerable expressive power we have carefully designed this type system as a small, yet coherent extension of the C# type system. For reasons of space we can not describe all of the language in this paper, but it does support the entirety of the C# language.

First we consider Xen class declarations. Instead of having zero or more field declarations inside a class, we allow classes to have one content type and zero or more attributes, in addition to zero or more method declarations as usual. Let C denote class declarations, I identifiers, T types, A attribute declarations, and M method declarations. A Xen class declaration has the following general form:

  C ::= class I : I...I { T; A* M*  }

An attribute declaration is like a field declaration, but is decorated by the attribute keyword

  A ::= attribute T I;

Attributes have no special semantics except for influencing the serialization format of types. In particular we have no special "axis" to distinguish between child and attribute access.

A type is either a sequence type (corresponding to the XSD <sequence> particle, the DTD (...,...) construct), a choice type (corresponding to a C-style union, the XSD <choice> particle, or the DTD (..|...) construct), an all type (corresponding to the XSD <all> particle), a possibly empty stream type (corresponding to the XSD minOccurs="0", maxOccurs="unbounded" occurrence constraint, or the DTD * construct), a nonempty stream type (corresponding to the XSD minOccurs="1", maxOccurs="unbounded" occurrence constraint, or the DTD + construct), an option type (corresponding to the XSD minOccurs="0", maxOccurs="1" occurrence constraint, or the DTD ? construct) or a named type that was introduced by a content class. Types are given by the following grammar.

  T ::= sequence{ ... T I? ; ...}
     |  choice{ ... T I? ; ...}
     |  all{ ... T I?; ...}
     |  T* | T+ | T?
     |  I

We use the phrase T I ? to indicate that field names in Xen are optional.

Subtyping relationships between these new types are defined based on their structure and not only by their name. Structural subtyping is nothing new. In a limited form it is already available in C# or Java. Suppose for example, that class ColorPoint is a subtype of class Point, then an array of ColorPoints, (written ColorPoint[]) is a subtype of an array of Points (written Point[]). In the same fashion, in Xen a stream of ColorPoints (written as ColorPoint*) is a subtype of a stream of Points (written as Point*). Similar covariance rules apply to the other structural types. It is beyond the scope of this paper to explain Xen's subtyping relationships in greater detail. Instead we refer interested readers to two accompanying papers ([Unifying Tables, Objects and Documents], and [The Meaning of Xen]). These papers also give some details on related programming languages that embrace XML such as Xtatic [Xtatic] and CDuce [CDuce].

To illustrate both the type system and the syntax of Xen we will take examples from the XQuery Use Cases. This defines a bibliography of books given by the following DTDs:

  <!ELEMENT bib  (book* )>
  <!ELEMENT book (title,(author+ | editor+), publisher, price)>
  <!ATTLIST book  year CDATA  #REQUIRED >

In fact the DTD for book is a nice example illustrating where current object-oriented languages fall short in defining rich content models. For example there is no equivalent notion of union types in Java or C# and no way to indicate that a collection should contain at least one element.

Below we give the Xen class declaration for books. It states that a book has either at least one editor or at least one author, a publisher and a price, and a year attribute:

  
  public class book {
    sequence{
      string title;
      choice{
        sequence{ editor editor; }+;
        sequence{ author author; }+;
      }
      string publisher;
      int price;
    }
    attribute int year;
  }

When serializing values of type book as XML, they will conform to the given DTD for book. However, why would you only use XML serialization outside the language? Xen internalizes XML serialized objects into the language, allowing programmers to use XML fragments as object literals. For instance, we can create a new instance of a book object using the following XML object literal:

  book b = <book year="2004">
             <title>C# Concisely</title>
             <author>
               <first>Judith</first><last>Bishop</last>
             </author>
             <author>
               <first>Nigel</first><last>Horspool</last>
             </author>
             <publisher>Addison-Wesley</publisher>
             <price>68.00</price>
           </book>;

The Xen compiler contains a validating XML parser that analyzes the XML literal and "deserializes" it at compile time into code that will construct the correct book instance. This allows Xen programmers to treat XML fragments as first-class expressions in their code.

In addition to first-class XML object literals, Xen also allows arbitrary embedded code, using curly braces as escape syntax (where curly braces themselves are escaped using \{ and \} respectively). As Xen is statically typed, the type of the embedded expression must be of an "allowable" type (see section Section 4.5, “The Xen validation rules” for more details). In the following example we splice in the embedded expression LookupPrice("C# Concisely") to construct the price of our book.

    book b = <book year="2004">
               <title>C# Concisely</title>
               <author>
                 <first>Judith</first><last>Bishop</last>
               </author>
               <author>
                 <first>Nigel</first><last>Horspool</last>
               </author>
               <publisher>Addison-Wesley</publisher>
               <price>{LookupPrice("C# Concisely")}</price>
             </book>;

Of course embedded expressions can be used for attributes also, so we could use <book year={e}/> in the example above provided e is some expression of type int that computes the year of our book.

The validation rules in Xen allows us to write particularly concise code when dealing with embedded expressions. Consider the following declaration of a book whose authors are computed by an embedded expression:

  book b = <book year="2004">
               <title>C# Concisely</title>
               { authors }
               <publisher>Addison-Wesley</publisher>
               <price>68.00</price>
             </book>;

According to the content type of book, the expected type for the embedded expression { authors } is

  choice{ 
    sequence{ editor editor; }+ 
    sequence{ author author; }+
  }

We'd like to be able to use the following declaration for authors.

  author* authors = <author>
                     <first>Judith</first><last>Bishop</last>
                    </author>
                    <author>
                      <first>Nigel</first><last>Horspool</last>
                    </author>;

The variable authors has type author*. This type is considered to allowable instead of the expected type according to the Xen validation rules because the set of documents described by the type author* is a subset of the set of documents described by the original union type. Thus the declaration is permitted with no explicit type conversions needed.

The validation rules are defined using a relation is allowable between types. Let S and T be two types. We say that S is allowable for T if the set of serialized XML documents of type S is a subset of the set of serialized documents for type T. It is the case that if S is implicitly convertible to T then S is allowable for T, but not necessarily the other way around. For instance the serialized values of type sequence{ A A }* are the same as the serialized values of the type A*, but the type sequence{ A A }* is not implicitly convertible to the type A*.

We do not put any restrictions on our class declarations and in particular we do not impose any non-ambiguity constraints. For example the following class declaration A is perfectly legal in Xen, even though it is obvious that the content model is ambiguous:

  class a { int; }
  
  class As {
    sequence{
      choice{
        sequence{ a a; a a; }
        sequence{ a a; }
      }
      choice{
        sequence{ a a; a a; }
        sequence{ a a; }
      }
    }
  }

The validator will attempt to validate a given object literal in all possible ways, and only flag an error if it did not find exactly one parse. When using ambiguous context-free grammars this is similar to the idea of using a general purpose parser such as GLR or Early [ASF/SDF] and demanding that each particular parse is unambiguous.

In this case, the literal below is ambiguous, and the validator will generate a compile-time error

  As a = <As><a>1</a><a>2</a><a>3</a></As>;

To disambiguate we can use embedded expressions and write

  As a = <As>{<a>1</a><a>2</a>}<a>3</a></As>;

to indicate to the validator that we intend the first choice to be the two a's and the second just one a. Of course we should be careful with ambiguous content models when values have to be serialized to the outside world where we cannot use embedded expressions.

Streams of values play an important role in many XML content types, for instance a book can have one or more authors or editors. In Xen stream types ?, +, and * all implement the IEnumerable interface and hence we can iterate over any stream using a foreach loop:

    book b = ...
    author* authors = b.author;
    foreach(author a in authors) Console.WriteLine(a);

Note that even though the content type of book says that a book has one or more authors, the result type of b.author is author* because it could be that the book has editors not authors. (To be precise, the return type of b.author is author+?, which is according to Xen's type equivalences the same as author*. See our companion papers [Unifying Tables, Objects and Documents] and [The Meaning of Xen] for a more detailed account of Xen's type system.

Whilst it is easy to traverse streams using foreach loops, it is still a little verbose compared to XPath. In the next couple of sections we discuss some of the features that we have added to Xen to make iteration over streams even simpler. Before describing them we first need to tackle another problem, namely how to make it easy to generate streams.

The most convenient way to generate finite streams is to use the fact that the Xen type system defines an implicit conversion between sequences and streams. For example Xen considers sequence{ Author; Author;} to be a subtype of Author*. The following code is then type correct (where new(..) is the Xen sequence constructor).

  author* authors = new(author1, author2);

Of course, this only works for finite streams; it does not help us to generate more complex or infinite streams. For this we introduce yield statements. A method body that contains yield statements can "return" multiple times, each time yielding the next element of a stream. For example the method FromTo(n,m) below generates a stream of integers n, n+1, ..., m by yielding (m-n)+1 times:

  // FromTo(n,m) ==> n, n+1, ...,m
  int* FromTo(int n, int m){
    for(int i=n; i=<m; i++) yield i;
  }

The concept of methods that return multiple times is also available in XQuery, which (confusingly) uses the return keyword instead of yield. It is also supported by several other programming languages including Icon, Clu, and Python, and will be in the next version of C#.

It turns out that especially for generators it is convenient to allow statement blocks as expressions. So for instance instead of having to define a separate method FromTo we can just use the block expression { for(int i=n; i=<m; i++) yield i; } of type int*.

The most important difference between path expressions and ordinary member selection as found in object-oriented languages is the way path expressions lift (homomorphically extend) over structural types such as streams, sequences, and unions.

Suppose that we have a bibliography that contains zero or more books as its content model.

  public class bibliography {
    book* books;
  }

and that given an instance bib of type bibliography we want to select all the titles of all the books. The most natural way to write this query is by using the following path expression:

  string* titles = bib.books.title;  // Xen code

Note that the result type of the sub-expression bib.books is book*. In C# or Java, the subsequent title member access would not be allowed as it would be assumed to be on the stream itself, rather than the elements of the stream. In Xen the notion of member access has been generalized to support this style of programming. Member access is defined to be lifted (mapped) over the stream and so the code above is valid and behaves as expected. In contrast we would have to write the following C# code to achieve the same effect.

  string* getTitles(books bs){
    foreach(book it in bs) yield it.title;
  }
  
  string* titles = getTitles(bib.books); // C# code

Note how convenient the Xen code bib.books.title is in comparison to the somewhat clumsy C# code. This is an example of where promoting XML access to the language level has allowed us to provide elegant support for a typical programming pattern.

A similar situation happens when we have an instance b of a choice type say choice{ string; Button; }. The most natural way to select the BackColor field of b is to write b.BackColor, which either returns null if b happens to be of type string or a value of type Color in case b is indeed of type Button. This is precisely what happens in Xen. Without such lifting we would be forced to define a new method that performs an explicit instance check to determine the actual type of b:

  Color? getBackColor(choice{string; Button; } b){
    if(b is Button) return ((Button)b).BackColor;
    return null;
  }

and then use getBackColor(b) in place of Xen's more elegant b.BackColor.

Finally, it nearly goes without saying that lifting of member access over sequence types is also extremely convenient. In fact, Xen automatically lifts member-access (including method calls) over all its structural types. As we have seen this yields elegant and compact code that is familiar to the XPath programmer.

Besides lifting, filters are another example of an XPath feature that is indispensable for writing concise code. Again we have promoted this vital programming pattern to a first-class language feature. Given a stream expression e, the Xen expression e[p] denotes the stream resulting from applying the filter p to each element. In the boolean predicate p the stream element can be referenced using the implicit variable it.

For example given a bibliography of books, bib, we can select all books whose publisher is Addison-Wesley that are published after 1991 by the following filter expression.

    book* AWbooks = 
      bib.book[it.publisher == "Addison-Wesley" && it.year > 1991];

Often we want to lift operations other than member-access and method invocation over a structural type. For example, suppose we want to collect the title and year of all books, or we want to print out all the titles of the books. Again we have promoted this common programming pattern to a first-class language feature; the apply-to-all block.

Given a stream expression e and a code-block { s } where s is a Xen statement, the apply-to-all expression e.{ s } generates a stream resulting from executing the code-block for each element in the original stream (again s can contain the identifier it to denote the current stream element).

To collect all titles and publication dates of a stream of Addison-Wesley books (henceforth called AWbooks) we apply the method body { return new(it.title, it.year); } to the AWbooks stream as follows.

  sequence{string; int;}* bs
   = AWBooks.{return new(it.title, it.year);};

In this case the return type of the apply-to-all block is sequence{ string; int;}. The result of the whole expression is a stream of type sequence{ string; int;}* that is built lazily.

Apply-to-all blocks need not just be used to construct new streams. Printing out all the titles of the AWbooks books is simply a one liner:

  AWbooks.{ Console.WriteLine(it); }

Note that the return type of { Console.WriteLine(it); } is void; therefore the result of the whole expression is void. Obviously void results cannot be consumed, thus it makes no sense to postpone the evaluation of void apply-to-all blocks. As a consequence, Xen evaluates the effect of void apply-to-all blocks eagerly.