# COmega, II

6/13/2005 1:08:48 PM

## COmega, II

After reading several more articles on COmega, I filled in more details on the probable features of C# 3.0 regarding data. A good source of information was the MSDN article Integrating XML into Popular Programming Languages.

From reading the papers of COmega, the authors imply that there really only three forms of data—relational, object-oriented, and hierarchical. One author compares the three forms to tables, objects, documents; another to rectangles, circles, and triangles, respectively. Objects and XML are very similar in that they both depict graphs, where one is edge-labeled and the other is node-labeled. So, objects and XML are really the same thing and relational data is just a normalized, hyperefficient representation for doing queries. They do seem to mirror the three types of databases encountered in history, but could there be a fourth, like, say, the multidimensional databases used for OLAP reporting (coming from my PivotTable background)?

With so many new enhancements, I thought that the editor Intellisense engine and compiler backend of C# 3.0 should go into overdrive. I confirmed this by downloading the COmega preview and viewing the voluminous generated code from the small “hello world” samples within Reflector. Lots of new types and closures were produced. There clearly needs to be additional runtime support for concepts like streams and tuples to curb the codegen. That said, COmega does appear to be using undocumented IL from Beta 2 that Reflector cannot read.

COmega also includes two small runtime DLLs System.Compiler.Runtime and Microsoft.COmega.Runtime. These two libraries also contained Spec# support, so COmega and Spec# may be the same language or any least share the same runtimes. Since C# and C++ won’t ship with separate runtimes, any compiler support will have to be included within the CLR.

Streams.

Streams, T*, are derived from, IEnumerable<T> but differ in that the streams are flattened as one list when combined in any way. Yielding a stream in an iterator results in multiple values being emitted. Streams also don’t contain any null values—these just disappear as you insert them into the steam.

COmega currently uses the star notation, common in regular expressions, but the notation conflicts with existing pointer support. C# might keep this notation and attempt to resolve ambiguities instead through context. If streams of pointers are disallowed, then any assignment of a non-null pointer could resolve any ambiguities. On the other hand, null values can be assigned to both pointers and streams.

Nullable (T?) and Nonnullable Types (T!).

Both values and references are considered singleton streams, unless their value is null, in which case they are empty streams. There is new notation to allow for nullable value types and non-nullable reference values. The nullable valuetype syntax was introduce in C# 2.0.  COmega borrows nonnullable reference types from Spec#, which is another Microsoft’s experimental language, attempting to improve code reliability and quality with invariants and checked exceptions. I have also seen the notation (+) in another document used for a non-empty stream containing at least one value.

XPath and XQuery

COmega supports “lifting” or generalized member access (books.author) by which a new stream is created consisting of a property of all the elements of a stream. It also supports transitive member access (books…author) and “Apply to All” (books.*). In addition, it includes filters, books[it.author == “Shakespeare”]. In combination with the SQL operators, it’s possible to get rich enough support for all the XQuery use cases. However, COmega is missing support for XPath-like axes.

Anonymous Structs or Tuples

Tuples (anonymous structs) are value types with structural equivalence and public-only fields with optional or duplicate names (unspecified name uses type as the name), but no additional methods. These correspond to a database record but also to children of XML node. Introducing tuples to the CLR would mean a new class of types that exhibit structural equivalence.

Implicit Declarations

The Javascript-like “var” keyword, which Anders proposed in a whiteboard session last year to incorporate some of the advantages of dynamic languages, makes increasing sense when using select queries that can return long tuples too cumbersome to type. COmega does not have a var keyword, but instead allowed new variables to be initialized without any declaration, because of the problem with the select query.

Full Array of SQL Operations

SQL support would extend not just to queries, but to updates as well. The MSDN article explicitly mentions a large range of operations including filtering, ordering, grouping, aggregations, data modifications, and all four joins.

Transaction Support

In addition, transaction support is included with three keywords transact, commit, and rollback. The syntax mirrors that of try, catch and finally; additionally, commit and rollback can also be called from within the transact block . This support would alleviate issues with the using block for transactions and its assumption that abnormal termination is the default case.

Integration

For an example of the level of integration, here’s an example of how one could create a WinForms button directory through the inline XML support. I pulled this from the COmega preview. Note that it is possible to escape from within XML to C# by using the { } notation.

 Button b = <button>
<text>Don't Push Me</text>
<size>80,60</size>
<location>8,8</location>
<backcolor>Salmon</backcolor>
</button>;

One issues that doesn’t seem to have been resolved is that keys in database record should really map into references in the object world and ids in the XML data. That disconnect is still there, but it’s a small one.