Technical Overview of the Common Language Runtime

The paper makes a comparison between the Java Virtual Machine (JVM) of Java and the Common Language Infrastructure (CLI) of Microsoft .NET, arguing that although almost of the developers moved to the JVM as their vehicle for their languages it wont be the best option for all of them as it is for Java. The paper starts listing some of the attempts to develop virtual machines, intermediate languages and language independent execution platforms. It is awesome to know about this because I did not know anything about them and I suppose there may be a good reason, well the paper mentions that the reasons to watch for another options are the portability, the compactness, the efficiency, the security, the interoperability and the flexibility.

The CLI has been designed to overpass the problems that the JVM may have (for example the capability of unboxing structures and unions, etc.…), this with the help of different implementers of different languages. The paper also describes some of the parts of the architecture of the CLI in order to understand a little bit more of how it works inside, the remarked part is that in contrast to the JVM, where all storage locations are not “polymorphic”, as they are within CLI, which means that their size can me user-defined, but they are fixed for lifetime of the frame

Later, the paper describes a little bit more some of the CLI’s features, the type system section describes some of the primitive types that are supported and letting us know that they can be combined into composite types. The base instruction set section, describe some of the most representative instruction of each group, and exposes that unlike JVM, the CLI do not hard-code within the instructions the type of their arguments. Finally, the last parts are about the reference and value types, how they interact and about invoking methods. These sections describes some interesting facts about how they work, for example the ways to indirect call a function pointer.

Building Server-Side Web Language Processors

The article talks about how to build a server-side web language processor, the author give an example of this, through the building of java applets and running them with a web browser. Also the author explains that this may be desirable because some instructors at certain colleges need to teach using a compress approach, I wonder if this is something as the new educative model that the Tecnológico de Monterrey has adopted (the Tec21 model), because the description mentions that this is a union of the application of different subjects to learn about them within a single course.

The provided description for the language processors is that they “allow us to run programs or prepare them to run”.  The locations for our language processor according to the proposed architecture can be the client, and the server. And the recommended features for the language are basic configuration, compact syntax, dynamic types, garbage collector and direct support for high level collections (strings, dictionaries, etc...). The point here is to do some computations and later produce an output in the form of a HTML, XML or plain text. Then we need to consider the presentation of the code, we have to different types of elements (static and dynamic), the first way is to write static elements (html tags) within the dynamic types (language instructions), and the second way is to embed we language code inside the static notation, this is known as a template view.

To accomplish our goal is to know how http works, which is a request/response standard between a client and a server. Here are two parts, the first one, establishing a transmission control protocol (TCP) connection with a port on a host computer, and the other one with a server listening a port waiting for requests to answer them. We also need to consider the use of the different types of scopes for the variables, which can be local, page, request, session and application

Language Design and Implementation using Ruby and the Interpreter Pattern

The paper talks about how to use the S-expression interpreter framework (SIF) to teach language design and implementation, which is written on Ruby (described later on), the SIF has a simple core that can be extended (we will talk about this later, specifically about how can be extended to support functional programming or imperative programming). The “S-expressions” means symbolic expressions, and this is a parenthesized prefix notation used in lisp family languages, for example ( + a b), this is interesting because I did not remember this concept from the course where we learned Clojure ands it is good to remind it.

The SIF works as the interpreter pattern (one of patterns of the “Gang of Four”), and as I said it is written in Ruby which is an interpreted, dynamically typed language, which syntax borrows from Eiffel, Ada and Perl, and its object oriented based in spirit of Smalltalk. One of their most important components is the node class and their subclasses (I think this is related to the third phase of our project, where I saw that we will use the node class and implement subclasses from it). I did not understand one hundred percent fine how this class works, but I understand that it checks in part the syntax and semantics, something that we have already checked for our project.

Finally, the paper talks as I said before, how we can extend the functionality of the SIF to be able to use it to interpret functional programming languages, this through defining some special “forms” (quote, define, if and fn) to be capable of “reading” its grammar. And in other hand the author mentions how to extend it to be useful for imperative programming languages, defining the special “forms” (set! and begin) and a new class called “environment”.