Comment about "Technical Overview of the Common Language Runtime (or why the JVM is not my favorite execution environment)"

Although JVM is one of the primary tools chosen by language researchers, it might not be good with other languages than Java. The main reasons for choosing an alternative to native compilers are:

Portability
Compactness
Efficiency
Security
Interoperability
Flexibility

JVM is an attractive option because of its high-level runtime support and the rich set of libraries. But in the other side it is important to say that it doesn't gives a way to encoding type-unsafe features of typical programming languages, such as pointers, immediate descriptors  (tagged pointers) and unsafe type conversions.

Other features that it lacks of are:

• Unboxed structures and unions (records and variant records)
• Reference parameters
• Varargs
• Multiple return values
• Function pointers
• Overflow sensitive arithmetic
• Lexical closures
• Tail calls
• Fully dynamic dispatch
• Generics
• Structural type equivalence

Another tool that has been developed is the CLI by Microsoft which has good support for imperative and statically Oriented Object languages. One of the great features the CLI has is that it maps natural-size or generic types depneding on the processor, for example, a native int would map to int32 on a Pentium processor, but to int64 on an IA64 processor. All of this is made at JIT- or run-time. This can make the program work better in different processors and it wouldn't be tedious for the person to design its program for each of the great amount of different processors in the market.

In summary the main points that are mentioned in the paper are how the CLI is better in assembling files, it supports a number of primitive types, its instructions are more polymorphic, provides a number of instructions for transferring values to and from the evaluation stack, supports types such as classes, interfaces, arrays, delegates, it has two call instructions for directly invoking methods and interfaces and another important one is that it supports tailcalls which are the only way to do recursion in languages such as Haskell, Scheme, Mercury, etc.)

Sources:

Erik Meijer, J. M. (2001). Technical Overview of the Common Language Runtime. From http://webcem01.cem.itesm.mx:8005/s201613/tc3048/clr.pdf

Building Server-Side Web Language Processors (Comment)

One of the most incredible things with programming languages is that even when it is not the same to code in one than in another, you can create a pretty much alike solution or idea. If you want to get the sum in an array you can do it in python like

sum = 0
array = [1, 2, 3, 4, 5]
for x in array:
    sum += array[x]

or in javascript (ECMAScript 2015):

var sum = [1, 2, 3, 4, 5].reduce((a, b) => a + b, 0);

And that is the main points of the paper "Building Server-Side Web Language Processors", which tries to build a language processor which is coded and maintained using web technologies. This approach can be more suitable for a person who knows more about constructing web solutions than someone that works with a terminal. As making a compiler is not a task a computer science graduate does often in most of the companies, it can be more valuable to create it while using tools that are common such as HTML, CSS, Javascript and other, so that the student can get experience in two areas.

There are many server side programming languages options to choose, it can be PHP, Node (Javascript), Python, Ruby, and if you are using a framework like ruby on rails, django or  another you can stop worrying about cross-site scripting and work more in the implementation and design, the only disadvantage is the learning curve if you don't know them. And if you decide to use web technologies to teach how to do language processors, you will have the drawback of having to give web lectures and such thing can take a little bit of time. 

If you are interested on checking some already made content you can go to: 

http://webcem01.cem.itesm.mx:8005/weblang

You will find examples for the implementation of some of the strategies used on the pdf Building Server-Side Web Language Processors, written by Ariel Ortiz.


Sources:

Ortiz, A. 2010. "Building Server-Side Web Language Processors". Retrieved 12 March 2017 from: http://webcem01.cem.itesm.mx:8005/publicaciones/weblang.pdf

Language Design and Implementation w/ Ruby and the Interpreter Pattern (Comment)

The article "Language Design and Implementation using Ruby and the Interpreter Pattern" written by Ariel Ortiz in 2008, describes the S-expression Interpreter Framework, also called (SIF), which is a tool that allows to demonstrate language design and implementation concepts. It supports integers, symbols, lists and procedures and this can be used to learn about different programming styles (functional and imperative). 

The SIF consists of 3 files:

• sif_parser.rb Scanner and parser. Required by sif.rb. 
• sif.rb Fundamental framework classes, including: Interpreter, Primitives, and Node. 
• sif_file_reader.rb Reads and interprets an s-expression source file, one expression at a time. The result of every expression is printed to the standard output, unless it's equal to Ruby's false or nil. It also catches any runtime errors. Required by sif01.rb, sif02.rb and sif03.rb.

The main part of SIF is its Interpreter.eval class method which receives a string (with one or more valid S-Expressions) and converts the data into Ruby data values, which are then evaluated using the interpreter pattern. 

We can extend SIF to have a functional language interpreter just by adding the forms quote, define, if, fn, etc. and we can do the same to create a imperative one adding instead set!, begin, etc. If you are not familiar with them you can check this (Functional Programming vs. Imperative Programming) to understand a little bit more about this two ways of programming which in summary, the Functional, is more interested in getting information and its transformations, and the Imperative is more interested in performing tasks and tracking its changes. Nevertheless, you can use whatever one you want to teach/learn with the S-Expression Interpreter Framework.

One of the core properties of SIF is that it differentiates between syntax and semantics of any language construct.

If you want to check the source code, you can click on this link:

http://webcem01.cem.itesm.mx:8005/sif/

Source:
Ortiz, A. 2008. "Language Design and Implementation using Ruby and the Interpreter Pattern". ACM. Retrieved 5th of March 2017 in: http://webcem01.cem.itesm.mx:8005/publicaciones/sif.pdf