Angel \”Java\” Lopez on Blog

December 10, 2014

SimpleLisp (2) Compiling Lisp Values and Variables to JavaScript

Previos Post

Let’s review the project’s implementation

the Lisp compiler to JavaScript, written in JavaScript, following the workflow of TDD (Test-Driven Development). All is “work in progress”, so today I will explain part of the implementation but it could be change in the future, when new use cases were added, and new ways of doing things were implemented.

I took the decision that each Lisp symbol is a JavaScript variable. So, the compilation of a symbol is:

exports['compile symbol'] = function (test) {
    test.equal(sl.compile('a'), 'a');

The sl is the SimpleLisp module, loaded in this test file (test/compile.js)

An integer and an string are compiled to natural values in JavaScript:

exports['compile integer'] = function (test) {
    test.equal(sl.compile('42'), '42');

exports['compile string'] = function (test) {
    test.equal(sl.compile('"foo"'), '"foo"');

It’s quoted values, too:

exports['compile quoted integer'] = function (test) {
    test.equal(sl.compile("'42"), '42');

exports['compile quoted string'] = function (test) {
    test.equal(sl.compile("'\"foo\""), '"foo"');

I decided to compile Lisp nil to JavaScript null. The boolean values are the same:

exports['compile nil'] = function (test) {
    test.equal(sl.compile('nil'), 'null');

exports['compile booleans'] = function (test) {
    test.strictEqual(sl.compile('false'), 'false');
    test.strictEqual(sl.compile('true'), 'true');

But, what happens if an expression serie is compiled? I build an anonymous function, invoked without arguments, and the last expression value is returned:

exports['compile two symbols'] = function (test) {
    test.equal(sl.compile('a b'), '(function () { a; return b; })()');

Next topics: compilation of a Lisp lisp, and more quoted values, macros, ect.

Stay tuned!

Angel “Java” Lopez

November 28, 2014

SimpleScript (3) The Parser, Expressions and Commands

Previos Post

Let’s visit the Parser, that is a separated module. It starts with a simple declaration:

'use strict';

var lexer;

if (typeof lexer == 'undefined')
    lexer = require('./lexer');

var parser = (function () {
    var TokenType = lexer.TokenType;
    var binoperators = [ "+", "-", "*", "/", "==", "!=", "<", ">", "<=", ">=" ];

It uses and requires the lexer module. After this declaration, there are many expressions and commands. This is the expression “class” for a name (ie, foo):

function NameExpression(name) {
    this.isLeftValue = true;

    this.compile = function () {
        return name;

    this.getName = function () {
        return name;

    this.collectContext = function (context) {

In an upcoming post, I will describe the detection and construction of commands and expression. An expression should implement two methods: compile, that returns an string with the compiled JavaScript code associated to the expression, and collectContext, that allows the discover of used variables in an expression/command. In the above code, NameExpression declares its name to a context, an object that is recovering the used variables.

This is an IndexedExpression, composed by an expression and another one for the index (it’s like foo[42+1]):

function IndexedExpression(expr, indexpr) {
    this.isLeftValue = true;

    this.compile = function () {
        return expr.compile() + '[' + indexpr.compile() + ']';

    this.collectContext = function (context) {

The collectContext visits the internal expression (I could add the visit of the index expression, too).

There are commands, like IfCommand:

function IfCommand(cond, thencmd, elsecmd) {
    this.compile = function () {
        var code = 'if (' + cond.compile() + ') { ' + thencmd.compile() + ' }';
        if (elsecmd)
            code += ' else { ' + elsecmd.compile() + ' }';
        return code;

    this.collectContext = function (context) {
        if (elsecmd)

The distinction between commands and expressions is a formal one. Again, a command should implement compile and collectContext. The above code generates a JavaScript if command.

As usual, I followed TDD (Test-Driven Development) workflow. Partial tests example:

exports['Compile string without quotes inside'] = function (test) {
    test.equal(compileExpression("'foo'", test), "'foo'");
    test.equal(compileExpression('"foo"', test), "'foo'");

exports['Compile name'] = function (test) {
    test.equal(compileExpression("foo", test), "foo");

exports['Qualified name'] = function (test) {
    test.equal(compileExpression("", test), "");

exports['Indexed term'] = function (test) {
    test.equal(compileExpression("foo[bar]", test), "foo[bar]");

Remember: No TDD, no paradise! ;-)

Next topics: how to recognize and build expressions and commands.

Stay tuned!

Angel “Java” Lopez

November 25, 2014

SimpleLisp (1) Compiling Lisp to JavaScript

Next Post

I implemented Lisp as interpreter, using C#, Java, and JavaScript. See:

The implementation of a Lisp is a good programming exercise. Lisp is a simple and powerful language, with functions as first class citizens. And with the “twist” of implementing functions that don’t evaluate their arguments, and macros.

This time, I want to implement a Lisp, but as a compiler. I started to write a Lisp compiler in JavaScript, that generates JavaScript. The project:

As usual, I worked using the Test-Driven Development workflow. With simple use cases, I implemented the needed features. This is my first Lisp compiler, so I’m trying new implementation approaches. I know Clojure, as a basis for a Lisp compiler. I should implement:

Symbols: identifiers witn name and associated value. Now, I’m compiling them to JavaScript variables. In SimpleLisp, a symbol can be defined at top, in a let block, or as a function argument. Then, I produce a top variable (or a least, a module variable), or a local variable in let, or an argument in function.

Functions: I’m translating a normal function in Lisp to a normal function in JavaScript. The main difference is that Lisp functions returns a value, there are no commands, all are expression, as in Ruby. A list in SimpleLisp is then compiled to a function call in JavaScript.

Special Forms: Their implementation is a novelty to me. In a compiler, I could generate directly the final code for each list with a head that is an special form. So, I’m compiling directly to JavaScript any list with head if, do, let, etc… . A list (if ….) is compiled to a JavaScript if, but returning a value.

Macros: In a compiler, I could adopt a new implementation: to expand the macro at COMPILING TIME. I’m not sure yet if I can take this approach in every case. Notably, in Clojure a macro is not a functional value: a macro cannot be passed as an argument. A macro make sense only at compiling time.

A final use case: write a web site using Node.js/Express in SimpleLisp.

Stay tuned!

Angel “Java” Lopez

November 11, 2014

SimpleScript (2) The Lexer

Previous Post
Next Post

These days, I was working improving my SimpleScript compiler to JavaScript. Today, I want to comment the implementation of the lexer, the repo is

Now, the lexer code resides in a dedicated file lib/lexer.js, that expose a module, that can be consumed from Node.js and from the browser. It starts defining the token types:

var lexer = (function () {
    var TokenType = { 
        Name: 1, 
        Integer: 2, 
        Real: 3, 
        String: 4, 
        NewLine: 5, 
        Separator: 6, 
        Assignment: 7 };

Then, it defines some operatores, delimiters, and the Token, with two elements, type and value.

var separators = ".,()[]";
var assignments = ["=", "+=", "-=", "*=", "/="];
var operators = ["+", "-", "*", "/", "==", "!=", "<", ">", "<=", ">="];

function Token(value, type) {
    this.value = value;
    this.type = type;

The main job is in the Lexer “class”, with the method nextToken:

function Lexer(text) {
    var length = text ? text.length : 0;
    var position = 0;
    var next = [];

    this.nextToken = function () {
        if (next.length > 0)
            return next.pop();


        var ch = nextChar();

        if (ch === null)
            return null;

        if (ch === '"' || ch === "'")
            return nextString(ch);

        if (ch === '\n')
            return new Token(ch, TokenType.NewLine);

        if (ch === '\r') {
            var ch2 = nextChar();

            if (ch2 === '\n')
                return new Token(ch + ch2, TokenType.NewLine);

            if (ch2)

            return new Token(ch, TokenType.NewLine);

        if (isAssignment(ch))
            return new Token(ch, TokenType.Assignment);

        if (isOperator(ch))
            return nextOperator(ch);

        if (isSeparator(ch))
            return new Token(ch, TokenType.Separator);

        if (isFirstCharOfName(ch))
            return nextName(ch);

        if (isDigit(ch))
            return nextInteger(ch);

Finally, the module expose a lexer factory and the enumeration of token types:

return {
    lexer: function (text) { return new Lexer(text); },
    TokenType: TokenType

The code was developed using Test-Driven Development workflow. There is a file test/lexer.js, fragment:

function getToken(text, value, type, test) {
    var lexer = sslexer.lexer(text);
    var token = lexer.nextToken();
    test.equal(token.value, value);
    test.equal(token.type, type);
    test.equal(lexer.nextToken(), null);

exports['Get names'] = function (test) {
    getToken('foo', 'foo', TokenType.Name, test);
    getToken('foo123', 'foo123', TokenType.Name, test);
    getToken('foo_123', 'foo_123', TokenType.Name, test);
    getToken('_foo', '_foo', TokenType.Name, test);

exports['Get integer'] = function (test) {
    getToken('123', '123', TokenType.Integer, test);
    getToken('1234567890', '1234567890', TokenType.Integer, test);

Remember: no TDD, no paradise ;-)

Next topics: the parser, commands and expressions implementations, compilation to JavaScript.

Stay tuned!

Angel “Java” Lopez

October 29, 2014

TDD: Links, News And Resources (24)

Filed under: Agile Software Devevelopment, Links, Test-Driven Development — ajlopez @ 7:08 pm

Previous Post

Test-Driven JavaScript with Jasmine

On-site TDD | My Not So Private Tech Life

My Not So Private Tech Life | Johannes Link’s Travels through Software Development Space

Functional TDD: A Clash of Cultures

Skills Matter

30 Days of TDD: Day One – What is TDD and Why Should I Use It?

TDD: Why We Don’t Party Like It’s 1999

Claysnow Limited – To TDD or not to TDD? That is not the question.


Unit testing AngularJS with Visual Studio, ReSharper and TeamCity | endjin blog

Venkat Subramaniam: Succeeding with TDD: Pragmatic Techniques for effective mocking on Vimeo

Learning TDD Through Test First Teaching – YouTube

Separating Allocation from Code // Speaker Deck

Clean Coder Blog

Skills Matter

Test-driven JavaScript in practice by Christian Johansen at NDC 2011 at Oslo, Norway –

Writing meaningful, self-documenting, behavior-oriented tests – Daniel Cazzulino’s Blog

Software Craftsmen Are Arrogant, Slow, and Dogmatic | 8th Light

My Links

Stay tuned!

Angel “Java” Lopez

September 18, 2014

TDD: Links, News And Resources (23)

Previous Post
Next Post

Lo que los gurús nunca te cuentan sobre Kanban y SCRUM

Moving from Practice to Production with Test-Driven Development

TDD is TDD (And Far From Dead) – Software People Inspiring

A TDD Journey: 1-Trials and Tribulations

A TDD Journey: 2- Naming Tests; Mocking Frameworks; Dependency Injection–naming-tests-mocking-frameworks-dependency-injection/

When TDD Doesn’t Matter

Test-Driven Development… by Grzegorz Gałęzowski [PDF/iPad/Kindle]

Creating and testing Meteor applications with BDD using Velocity and Jasmine | Dr. Llama’s Blog

One Mock Per Test Considered Not Awesome at

Everyday Tales: We Call It Unit For A Reason

Programming Without Fear | The Journeyman Programmer

Applying TDD to Scalding Development |

My Links

Stay tuned!

Angel “Java” Lopez

July 26, 2014

AjKeyvs Implementing Key-Value Store in C# (1) The Project

Filed under: .NET, AjKeyvs, C Sharp, No, NoSQL, Open Source Projects, Test-Driven Development — ajlopez @ 6:40 pm

I want to implement a key-value store (as Redis) in C#, play with data structures, and practice TDD (Test-Driven Development). I started:

The current structure:

There is a class library project, AjKeyvs, that contains the collections in an in-memory repository. The interesting part of this projects is to implement arrays and sets that can be sparse, having different keys. Example, having a key 1 (one) and a key 1000000 (one million) does not imply to have an array with one million positions. At the same, I want to have a good access and update time. In other use cases, I will have string keys, like “user”, “user:1”, “user:1:email”, etc. There are use cases that need the use of sets, with union, intersection, difference, etc… For integer keys, I jave a set where a could turn a bit on or off, for the presence or absense of an element. More implementation details in upcoming post.

The library can be used in-process, but I added a server and a client program. The server listen commands sent by the clientes. All collections reside in memory. Persistence is something orthogonal to the implemented use cases. I should decide if add the persistence into the command processing, or is something to be implemented outside the project.

As usual, I followed TDD workflow.

Next topics: data structures, collections, commands, concurrency, etc.

Stay tuned!

Angel “Java” Lopez

July 13, 2014

SharpBus in C# (1) First Steps

Filed under: .NET, C Sharp, Open Source Projects, SharpBus, Test-Driven Development — ajlopez @ 11:54 am

Last month I started to write SharpBus, a simple message processor inspired by ideas from Mule Java project. See:

As usual, I’m using TDD (Test-Driven Development), implementing small use cases and API consumption, in the simplest possible way. In fact, the project is a personal exercise of TDD. I hope that some may be useful beyond that. For now, it is an example that I want to share my workflow.

You can see the progress in:

The main ideas to implement are:

- There are Messages containing Payloads and Properties (dictionary of name / value)

- There Flows that process messages

- A Flow is composed of several elements

The elements can be chained in the flow, and can be:

- A Transformer, taking a payload or complete message, and returns a transformed version

- A Processor, taking a payload or complete message, operate on them, maybe accessing the business domain, but without transformation

- Input, a payload/message producer

- Output, a payload/message consumer, at the end od the Flow process

- A Rourter, given a payload/message, it decides with Branch to follow in the Flow. Each Branch is identified by a name.

There will also be items that can issue new posts than the current, and can issue them to different flows in the system. The message producers should be able to run threads (Threads) in principle. And there will be a set of threads (Pool of Threads) attending the incoming messages and deriving them to the respective flows.

A flow can take a message and return a response (Request / Response), or it can take a message, process it without returning an answer.

Some items need complete Message and other items operate over the Payload.

The elements in the world of Mule / Java are objects. Notably, in C #, the simplest way to implement is using lambdas. So, following TDD, the early testing and deployment has come out that way. You can see in some simple tests:

As an example of send a Payload and receive an answer, using an empty Flow:

var flow = Flow.Create();

Assert.AreEqual(1, flow.Send(1));

To send a payload and transform it:

var flow = Flow.Create()
    .Transform(x => ((int)x) + 1);

Assert.AreEqual(2, flow.Send(1));

The .Transform Transform expects a Func<object, object> which may be provided at the time with a lambda. In a classic Java 7 Mule, we should provide an object that implements an interface having a method to transform the Payload. I have to think whether it is worth having a typed Transform <T> (receiving T and returns T), or Transform <T, S> (receiving and returns T S).

I decided to build the flow by code. In the Mule environment Spring is used to set up the flow using XML. I think it is time to explore this other way, build the flow by code, and put it as the "first way", ie, as the way on which everything else could be mounted. If anyone ever needed a DSL (Domain-Specific Language) for creating flows could be implemented this way by having well designed code.

Following TDD, I still have not a case of using a Message (a complete message with content (Payload) and properties (Properties, a name / value) dictionary. All of the above is to process Payload directly.

Upcoming topics: add Message Payload with the output of messages, routing, assembling branches, etc. ..

Stay tuned!

Angel “Java” Lopez

July 6, 2014

TDD: Links, News And Resources (22)

Previous Post
Next Post

Myron Marston » Thoughts on Mocking

Why Your Test Suite Sucks – YouTube

Detecting Changes in Third-Party Code – The Code Whisperer

Justin Searls: JavaScript Testing Tactics on Vimeo

TDD by example: Patterns | Nico Cortés blog

Steve Freeman On TDD: How Do We Know When We’re Done?

Unit Testing JavaScript Applications

Scan Agile 2012: Phil Calçado: Better Functional Design Through Test-Driven Development on Vimeo

The TDD That Can be Spoken Is Not the Eternal TDD

The Domain Discontinuity | 8th Light

Test Double | Our Thinking | The Failures of “Intro to TDD”

¿Está TDD muerto o más vivito y coleando que nunca? – YouTube

TDD en C# con Visual Studio y NUnit – YouTube

Learn Test Driven Development in Flask – Part 2 | /dev/notes

Python: Automated Testing with Grunt (Node.js) | /dev/notes

Tom Stuart on TDD, BDD and Ruby

Test-Driven Development by Kent Beck

e-ferro Venturas/Desventuras de “informático”: De Test Unitarios de clases a Tests Unitarios de funcionalidad, un gran paso

JUnit: A Cook’s Tour

You won’t believe how old TDD is | Arialdo Martini

(10) Learning About TDD: The Purpose of #isTDDDead

Test Isolation Is About Avoiding Mocks — Destroy All Software Blog

Mis impresiones sobre el debate #isTDDDead | Jose Armesto

My Links

Stay tuned!

Angel “Java” Lopez

July 5, 2014

TDD: Links, News And Resources (21)

Previous Post
Next Post

Test-Driven Development as Pragmatic Deliberate Practice – jbrains

12 Meses – 12 Lenguajes (Java) | AprendiendoTDD

Is TDD dead? [Part III] – YouTube

Tea-Driven Development :: How much do you refactor?

Is TDD Dead

Learn Test Driven Development in Flask – Part 1

James Shore: How Does TDD Affect Design?

How Does TDD Affect Design? | Let’s Code JavaScript

Veterans of TDD: J B Rainsberger | My Not So Private Tech Life

Is TDD dead? [Part II] – YouTube


The Little Mocker | 8th Light

The DHH Problem

Test Induced Design Damage? | 8th Light

The Curious Case of Tautological TDD – The Code Whisperer

My Personal Failures in Test Isolation — Extra Cheese

Script Junkie | Test Driven Development: Top-Down or Bottom-Up?

When Really To Use Mocks? First Ask: “What Are Mocks?” – Software People Inspiring

The pitfalls of Test-Driven Development « Otaku, Cedric’s blog

Damian Nicholson: Writing (testable | maintainable | scalable | rock solid) JavaScript on Vimeo

James Shore: Test-Driven JavaScript Master Class on Vimeo

My Links

Stay tuned1

Angel “Java” Lopez

Older Posts »

The Shocking Blue Green Theme. Blog at


Get every new post delivered to your Inbox.

Join 69 other followers