Technical Overview of the CLR

Technical Overview of the CLR

On their article, "Technical Overview of the CLR", authors Erik Meiker and Jim Miller compare the Common Language Runtime functions and characteristics with the JVM. First they talk about what is an intermediate language and its motivations, among which they mention portability (so there are less translators), compactness (intermediate code is usually more compact than the original one), efficiency (better use of the environment), security (it's easier to constraint security), interoperability (fundamental for software resuability) and flexibility (typesafe metaprogramming concepts).

In general, they debate how each of these factors are managed differently in CLR and in JVM, and demonstrate how CLR in general is more efficient and better than the other one. For instance, JVM doesn't implement type-unsafe featuresm like pointers and unsafe type conversion, while CLR does implement it, as it works with primitive and composite types. In bit storage, JVM is limited to 32-bit wide memory allocation, which makes bigger types like long or long long to recquire more memory blocks in order to use them. In the other side, CLR implements overflow during operations on data types, which is pretty useful in arithmetic calculations and processes.

CLI does not limit the length of branches to 64K, which is a problem for compilers generating JVM byte code. It uses enums and structs, while JVM needs to transform them to classes and class-hierarchies. This is a big advantage as we know because data oriented models are usually faster and more efficient in memory. CLM supports tailcalls as well, which allow recursion functions and models to be implemented to strictly repetitive structured languages as Haskell and Mercury.

In conclusion, CLI is more powerful and JVM, and Microsoft along with the .NET Framework developers are constantly working on it to develop more complex functions and make it more compatible and flexible with other programming languages.

Building Server-Side Web Language Processors

Building Server-Side Web Language Processors

After reading the article titled “Building Server Side Web Language Processors” written by our course professor, Ariel Ortiz, I am very intrigued by the ideas proposed by our teacher in the constant search for further evolving this course not only in our institution, but worldwide, by introducing the idea of web servers running a compiler, making it more accessible for students and giving further more context to students in the importance and utility in compilers design. The author explains the possibility of using Server-Side implementations for language processors, or more so compilers. This is due to the obvious fact that the Internet is the trend which about every technology revolves around.

So far in the semester, our practices and compilers are all run in a local pc repository. This article explains the idea of implementing a compiler running on a web server, as I previously mentioned. This would obviously recquire of a more complete and complex software development experience, since we would have to integrate different kinds of technology that we have learned in previous courses, like web and app development, and architecture and design of software. However I do think it would be a challenge to learn all that content in 4 months time, however I would be down to try it. I do think that web development is one of the best paid branches in the career, and it is also one of the most demanded ones. It is a great market, and the more tools and different experiences we can gather in the subject, the better. I do think of this as a good proposal for a topic subject or even an integrator project to make, as it involves and includes knowledge of all the career.

I do hope the next generations of my career get the opportunity to put their knowledge to test with a project like this.

Ruby and the Interpreter Pattern

Ruby and the Interpreter Pattern

After reading the technical article “Language Design and Implementation using Ruby and the Interpreter Pattern”, written by our teacher Ariel Ortiz, I can't help but feel sad because I couldn't have the chance to use the SIF tool he describes in his article in my subject of Programming Languages. The article talks about an implementation he made to evaluate different LISP expressions that are given as strings using a framework called S-Expression Interpreter Framework, and gives some examples with Ruby code to demonstrate how it works.

The principle for the interpreter pattern is that it's easier to solve some problems by creating a specialized language to understand it, and then express the results in that same language. This is all involved in both the syntactic, but more importantly the semantic analysis of compilers (the phase we are currently working in in our project). It involves a data structure that is called Abstract Syntax Tree (AST Tree), where the different operands and hierarchy of functions are organized in order to create a logic and order to the thinking and executing processes of the machine.

After the creation of the AST Tree, the framework reads a source which will be turned into a string, containing all the info of the tree. The regex API is then used to scan the string which will turn the S-Expression into their equivalent values in Ruby. Finally, the AST will be built. 

I would have liked pretty much to have the opportunity to implement and mess around with the framework in my Programming Languages course, as I mentioned at the beginning of this post. I guess it would have been interesting and could have given more context on symbol expressions and their uses. However, I do think the content of this article will be very helpful for the next phase of development for our project, and the course itself.