S-Form Interpreter

Back in the day I was having fun with Scheme Lisp for my programming languages course, I came to wonder the reason for which whoever designed the language decided to make function calls in such an odd way. In this reading I just learned that the odd way is actually called S-Expression and it seems to be that way because it is easier to implement for the language developers. After many headaches caused by the ridiculous amount of parentheses in the nested functions of my final project, I gained adversity towards whoever designed Lisp. At that time I thought it might had to do with the recursive nature of the language. 

It seems that I was right in some way since the S-Expressions come naturally at the moment of applying recursion correctly for nested functions since the parser reads relying on the context defined in Ruby as it is shown in section 2.3.

Managing contexts seems to be one of the most useful implementations within the framework, having a quick access to data outside of the function being currently parsed seems to be something that is very characteristic of Lisp-like languages. In the article it is stated that the framework is quite able to support simple functional languages using the basic functionalities such as defining, passing arguments and setting functions. 

This article gave me a better understanding on why is it that S-Expressions makes parsing simpler. It is easy to see that on the Ruby code one can parse through the expression taking the first argument of the S-Expression (that is the function)  and defining what to do with each of the remaining arguments treating them as simple indexes of the obtained regular expression. Things get complicated when dealing with recursion and scopes, and as the author states, there are some basic optimizations for recursion that cannot be implemented with the chosen approach.