Common Type System—Introduction to Type Systems
| CSharp-Online.NET:Articles |
| .NET Articles |
|
| © 2006 Wiley Publishing Inc. |
Introduction to Type Systems
This chapter presents most idioms of the CTS using C#, although I do try to identify areas where there’s a mismatch between the language’s and the CTS’s semantics. Since we haven’t seen Common Intermediate Language (CIL) just yet (that comes in Chapter 3)—the language into which all managed programs are compiled—using a higher-level programming language such as C# will prove more effective in explaining the concepts, without syntax getting in the way.
As a brief example of the CTS’s diversity of languages that it supports, consider four examples, each of which has a publicly available compiler that targets the CLR: C#, C++/CLI, Python, and F#:
- C# is a (mostly) statically typed, imperative, C-style language. It offers very few features that step outside of the CLR’s verifiable type-safety, and employs a heavily object-oriented view of the world. C# also offers some interesting functional language features such as first class functions and their close cousins, closures, and continues to move in this direction with the addition of, for example, type inferencing and lambdas in new versions of the language. This is, at the time of this writing, the most popular programming language on the CLR platform.
- C++/CLI is an implementation of the C++ language targeting the CTS instruction set. Programmers in this language often step outside of the bounds of verifiable type safety, directly manipulating pointers and memory segments. The compiler does, however, support compilation options to restrict programs to a verifiable subset of the language. The ability to bridge the managed and unmanaged worlds with C++ is amazing, enabling many existing unmanaged programs to be recompiled under the CLR’s control, of course with the benefits of Garbage Collection and (mostly) verifiable IL.
- Python, like C#, deals with data in an object-oriented fashion. But unlike C#—and much like Visual Basic—it prefers to infer as much as possible and defer as many decisions until runtime that would have traditionally been resolved at compile time. Programmers in this language never deal directly with raw memory, and always live inside the safe confines of verifiable type safety. Productivity and ease of programming are often of utmost importance for such dynamic languages, making them amenable to scripting and lightweight program extensions. But they still must produce code that resolves typing and other CLR-related mapping issues somewhere between compile- and runtime. Some say that dynamic languages are the way of the future. Thankfully, the CLR supports them just as well as any other type of language.
- Lastly, F# is a typed, functional language derived from O’Caml (which is itself derived from Standard ML), which offers type inferencing and scripting-like interoperability features. F# certainly exposes a very different syntax to the programmer than, say, C#, VB, or Python. In fact, many programmers with a background in C-style languages might find the syntax quite uncomfortable at first. It offers a mathematical style of type declarations and manipulations, and many other useful features that are more prevalent in functional languages, such as pattern matching. F# is a great language for scientific- and mathematical-oriented programming.
Each of these languages exposes a different view of the type system, sometimes extreme yet often subtle, and all compile into abstractions from the same CTS and instructions from the same CIL. Libraries written in one can be consumed from another. A single program can even be composed from multiple parts, each written in whatever language is most appropriate, and combined to form a single managed binary. Also notice that the idea of verification makes it possible to prove type safety, yet work around entire portions of the CTS when necessary (such as manipulating raw memory pointers in C++). Of course, there are runtime restrictions that may be placed on executing unverifiable code. We’ll return to these important topics later in this chapter.
 
|
