Angel "Java" Lopez : Lenguajes de Programación, TDD

Mass Lenguaje de Programación (4) Lexer y Parser

lopez — Sun, 12 May 2013 08:40:21 GMT

En la implementación del lenguaje Mass, tengo una enumeración y una clase:

Un Token representa una palabra del código a procesar. El encargado de separar el código en palabras es el Lexer. Y con el Parser se transforma esa corriente de Tokens en expresiones y comandos:

El constructor de Lexer recibe un string:

public Lexer(string text)
{
    this.text = text;
}

Y ese string es procesado para separarlo en tokens. Vean que el Lexer distingue entre operadores (como +) y separadores (como los paréntesis). También toma en cuenta al fin de línea como token (en otros lenguajes, como C, un fin de línea se puede tomar como un espacio en blanco en muchas situaciones). El principal método de Lexer es NextToken, que devuelve el próximo Token del texto. En algunas pocas situaciones, se hace necesario devolver el Token consumido, y para eso está PushToken y varianes.

El Parser interamente maneja un Lexer. Le podemos pedir el próximo comando con ParseCommand, y la próxima expresión con ParseExpression. Cuando el texto en proceso se acaba, esos métodos devuelven null.

Voy a modificar el Lexer para consumir un stream de texto, para poder procesar, por ejemplo, entrada de consola

Tengo que seguir pensando si internamente, unifico comandos y expresiones, como pasa en Ruby, donde cada “comando” tiene un valor (en Mass también es así), y no solamente eso, sino que puede ser usado como expresión en el contexto de un comando.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Mass Lenguaje de Programación (3) Comandos

lopez — Sun, 28 Apr 2013 11:24:00 GMT

Anterior Post
Siguiente Post

Veamos hoy cómo están implementados los comandos en Mass (ver repo). En el proyecto de librería de clases, tengo:

Hay comandos para if, while, for, for each, etc…. Todos implementan la interfaz ICommand:

public interface ICommand
{
    object Execute(Context context);
}

Vean que es muy parecido a IExpression. Igual quise mantener comandos y expresiones por separado, por lo menos en esta primera implementación, para tener un claro delineamiento de los conceptos de base del lenguaje.

Un ejemplo típico de comando es el WhileCommand (parte del código):

public class WhileCommand : ICommand
{
    private static int hashcode = typeof(WhileCommand).GetHashCode();

    private IExpression condition;
    private ICommand command;

    public WhileCommand(IExpression condition, ICommand command)
    {
        this.condition = condition;
        this.command = command;
    }

    public object Execute(Context context)
    {
        for (object value = this.condition.Evaluate(context); 
            value != null && !false.Equals(value);
            value = this.condition.Evaluate(context))
        {
            this.command.Execute(context);
            if (context.HasContinue())
                context.ClearContinue();
            if (context.HasBreak())
            {
                context.ClearBreak();
                break;
            }
        }

        return null;
    }
}

Para Mass: cualquier valor null o false es falso. Todo lo demás es verdadero. Un tema a refactorizar: poner un método IsFalse para se usado tanto en la implementación de While como de If.

Otro ejemplo es el ForEachCommand (parte del código):

public class ForEachCommand : ICommand
{
    private string name;
    private IExpression expression;
    private ICommand command;

    public ForEachCommand(string name, IExpression expression, ICommand command)
    {
        this.name = name;
        this.expression = expression;
        this.command = command;
    }

    public object Execute(Context context)
    {
        var values = (IEnumerable)this.expression.Evaluate(context);

        foreach (var value in values)
        {
            context.Set(this.name, value);
            this.command.Execute(context);
            if (context.HasContinue())
                context.ClearContinue();
            if (context.HasBreak())
            {
                context.ClearBreak();
                break;
            }
        }

        return null;
    }
}

Vean que para Mass, todo lo que sea IEnumerable se puede usar para ser consumido por este comando. Tuve que poner algunos datos en el contexto, para saber si se había hecho un break o un continue.

Y como siempre, todo esto desarrollado con TDD: pueden ver los commits del repo.

Próximos posts: Lexer y Parser, ejemplos de Mass para scripting.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Mass Lenguaje de Programación (2) Primeras Expresiones

lopez — Sat, 27 Apr 2013 13:26:00 GMT

Anterior Post
Siguiente Post

Antes de ver cómo usar el lenguaje Mass (ver repo), quisiera tratar algunos temas de implementación. Primero, una novedad: ahora hay una solución (en https://github.com/ajlopez/Mass/blob/master/Src/Mass.sln) que puede compilarse con algún Visual Studio C# Express, de libre bajada e instalación.

La solución Mass tiene un proyecto de librería de clases. Ahí hay un namespace dedicado a expresiones:

Una expresión es algo que cumple con IExpression:

  
public interface IExpression
{
	object Evaluate(Context context);
}

Un Context mantiene un diccionario de nombre/valor, para guardar las variables actuales:

  
public void Set(string name, object value)
{
	this.values[name] = value;
}

public object Get(string name)
{
	if (this.values.ContainsKey(name))
		return this.values[name];

	if (this.parent != null)
		return this.parent.Get(name);

	return null;
}

(vean de refilón, que soporta contextos anidados: cada contexto puede “heredar” de un contexto parent).

La expresión más simple es la que devuelve una constante, que puede ser cualquier valor/objecto .NET:

  
public class ConstantExpression : IExpression
{
	// ...

	private object value;

	public ConstantExpression(object value)
	{
		this.value = value;
	}

	public object Evaluate(Context context)
	{
		return this.value;
	}

	// ...
}

La siguiente expresión más simple es la evaluación de un nombre de variable en el contexto actual:

  
public class NameExpression : IExpression
{
	// ...
	
	private string name;

	public NameExpression(string name)
	{
		this.name = name;
	}

	public object Evaluate(Context context)
	{
		return context.Get(this.name);
	}
	
	// ...
}

Es necesario especificar el contexto (por ejemplo, el contexto de la función actual, de una clausura, del objeto actual, del módulo actual, etc), porque un mismo nombre puede tener distintas variables asociadas, como pasa en otros lenguajes.

Como siempre, cada una de estas clases (Expresiones, Contexto, …) fue armada usando el flujo de trabajo de TDD (ver el proyecto de tests, y la historia de commits del repo donde dejé evidencia de cómo fue el desarrollo en el tiempo).

Próximos posts: algunas expresiones adicionales, comandos, usando Mass para scripting, usando Mass desde nuestro programa .NET, etc..

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Mass Lenguaje de Programación (1) Orígenes

lopez — Mon, 08 Apr 2013 10:43:00 GMT

Siguiente Post

Durante estos días, estuve trabajando en la implementación de un lenguaje interpretado, sobre C#, llamado Mass (dedicado al bueno de @MArtinSaliaS):

https://github.com/ajlopez/Mass

La solución actual se compone de tres proyectos: una librería de clases, sus tests, y un programa de consola, mass.exe, para lanzar programas Mass

Pueden lanzar un programa escrito en un archivo hello.ms con

mass hello.ms

El clásico Hello world es entonces

println("Hello, world")

Un ejemplo con clases y objetos

class Person
	define initialize(firstname, lastname)
		self.firstname = firstname
		self.lastname = lastname
	end
	
	define getName()
		return self.lastname + ", " + self.firstname
	end
end

adam = new Person("Adam", "TheFirst")

println(adam.getName())

Un ejemplo con acceso a tipos y objectos .NET:

dirinfo = new System.IO.DirectoryInfo(".")

for fileinfo in dirinfo.GetFiles()
	println(fileinfo.Name)
end

La idea es (como en AjSharp y otras implementaciones) tener un lenguaje dinámico montado sobre un lenguaje/librería de clases. Y poder acceder a esa librería de clases desde el nuevo lenguaje. Me llevó a escribir Mass de la forma en que lo hice, el haber trabajado antes en:

- Implementar Python en C# (ver PythonSharp)

- Implementar Ruby en C# (ver RubySharp)

- El ya mencionado AjSharp (ver repo y posts)

Pero esta vez quería implementar algo que tuviera sintaxis y semántica simple. Ya estuve pensando en eso de “simple” para implementar un compilador de lenguaje simple a JavaScript ver SimpleScript

Entonces con Mass me propuse evitar:

- Múltiples comandos en la misma línea (descarté el ‘;’ de Ruby)

- Sintaxis basada en espacios en blanco, indentación (descartado Python)

- Llamadas a funciones con simplemente el nombre: se necesita explícitamente los paréntesis (descartado el Ruby clásico)

- Que las clases/valores de base (por ejemplo, enteros, strings, arreglos, etc…) tuvieran multitud de métodos (tienen los dados por la librería de clases de implementación, en este caso .NET) (descartado Ruby, que tiene casi tantos métodos nativos como PHP)

Y quise tener:

- Valores funcionales, como ciudadanos de primera clase, como en JavaScript. Vean que al tener que invocar una función con paréntesis, si o si, entonces la variable func tiene el valor funcional, y func() es la invocación explícita

- Objectos dinámicos: cada objeto puede extenderse en cualquier momento, con nuevas variables de instancia, funciones propias del objeto, como JavaScript

- Sintaxis basada en líneas: cada comando va en una línea distinta

- Sintaxis basada en palabras claves: para los comandos compuestos se usa ‘end’ para terminar un bloque

- En lo posible, una sola forma de hacer algo, en vez de múltiples maneras

- Palabras claves completas, ‘define’ en vez de ‘def’

- Clases con herencia simple (aunque la esencia de Mass bien puede expresarse sin clases, y usar librerías de clases ya escritas en .NET)

- Modificación explícita de variables fuera del alcance local (para explicar en próximos posts)

- Alcance de variables por archivo, como en JavaScript/NodeJs/CommonJS

- Módulos por archivo, con un require que permite buscar en directorios automáticamente, como en NodeJs/CommonJS

- Empaquetamiento, manejo de dependencias e instalación de esos módulos usando algo ya dado, como NPM, el manejador de paquetes de Node.js

En próximos posts, más detalles de implementación, ideas que guiaron el diseño, ejemplos. Pero ya pueden ver el código, y los ejemplos que están en los tests (sí, está todo construido paso a paso usando TDD).

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo un Intérprete en .NET (Parte 10)

lopez — Mon, 18 Mar 2013 09:50:56 GMT

Anteriores posts de la serie:

Escribiendo un Intérprete en .NET (Parte 9)
Escribiendo un Intérprete en .NET (Parte 8)
Escribiendo un Intérprete en .NET (Parte 7)
Escribiendo un Intérprete en .NET (Parte 6)
Escribiendo un Intérprete en .NET (Parte 5)
Escribiendo un Intérprete en .NET (Parte 4)
Escribiendo un Intérprete en .NET (Parte 3)
Escribiendo un Intérprete en .NET (Parte 2)
Escribiendo un Intérprete en .NET (Parte 1)

Hace unos meses que no escribo en esta serie, pero es porque he directamente escrito varios intérpretes, usando TDD, y haciendo “commits” prácticamente por tests en mi cuenta de GitHub, siguiendo las ideas de esos posts.

Intérpretes que estoy escribiendo, parecidos al descripto en los posts, son:

PythonSharp (ver los commits) (lo presenté en la PyCon Argentina 2012)

RubySharp (ver los commits)

Y para un ejemplo de un lenguaje diferente, vean una implementación de Clojure que estoy escribiendo en C#:

ClojSharp

Por ejemplo, hoy escribi un nuevo verbo de ClojSharp, la que se llama “let special form”, tienen los commits por tests de hoy:

https://github.com/ajlopez/ClojSharp/commits/master

Pueden ver uno en:

https://github.com/ajlopez/ClojSharp/commit/51c678ece96d6d1cef92f36afda8d8fc711ffd8c

donde GitHub nos muestra los cambios en el código.

Otro ejemplo, lo que hice ayer, test por test, en RubySharp:

https://github.com/ajlopez/RubySharp/commits/master

Espero que estos ejemplos les sirvan para ir viendo cómo se puede usar TDD para este tipo de proyectos. Tengo más ejemplos de otros tipos de aplicaciones en mis posts de TDD.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Code Katas en JavaScript/Node.js usando TDD

lopez — Mon, 14 Jan 2013 09:23:26 GMT

En estas semanas pasadas, he estado trabajando en ejemplos y módulos JavaScript/Node.js, usando TDD en cada paso. Practicar, practicar, practicar, el camino a la maestría.

Pueden ver mi progreso y revisar los commits que hago ante cada test. Lo que sigue es un resumen de este trabajo:

CobolScript: Ver mis posts un implementación de compilador de COBOL a JavaScript, con ejemplos de consola ejemplo web, usando MySQL y SimpleWeb.

SimplePipes: Una manera de definir pasaje de mensajes usando ‘pipes’ para conectar diferentes nodes/funciones en un grafo. Quiero extenderlo para que tenga proceso distribuido.

SimpleBoggle: Un programa que resuelve un tablero de Boggle, juega mejor que yo! Ver ejemplo de consola.

SimpleMemolap: procesamiento tipo OLAP multidimensional, pero usando un modelo en memoria. Hay ejemplo web que usa mi SimpleWeb (“dog fooding”):

SimpleChess: En progreso, define un tablero usando SimpleBoard, y ya calcula movidas. Estoy también trabajando en SimpleGo, para tener un tablero, un juego y evaluadores.

SimpleRules: Motor de reglas “forward-chaining”, hacia adelante (ahora que está de nuevo “de moda” la programación reactiva. Trabaja inspirada en algoritmo RETE-2, detectando los cambios de estado para disparar las acciones apropiadas.

SimpleScript: Ver mi post con las primeras ideas sobre este lenguaje, que compila a JavaScript, trabajo en progreso.

Py2Script: Compilador de Python a JavaScript, primeros pasos.

SimpleWeb: Una capa de “middleware”, a la Connect, con un ejemplo web:

BasicScript: Mis primeros pasos para compilar Basic a JavaScript. Quiero usarlo como lenguaje de programación para juegos en el browser.

SimplePermissions: El code kata de este sábado a la mañana ;-). Implementa Sujetos (Subjects), roles, permisos, otorgados en contexto.

SimpleFunc: Serialización/Deserialización de funciones y objectos con funciones.

SimpleMapReduce: Explorando la implementación del algoritmo Map-Reduce (y una variante, que llamo Map-Process) tanto sincrónico como asincrónico.

SimpleTuring: Implementación de una máquina de Turing.

Cellular: Implementación de autómatas de estado, lineales o de otras dimensiaones. Incluye un ejemplo de juego de la vida en consola.

Y en estos dos días pasados, agregué:

NodeDelicious: Para recuperar mis enlaces desde la cuenta de Delicious (sin tener que lidiar con el XML que devuelve directamente la API), ahora que el sitio ha sido rediseñado y no tiene paginación. La gente de Delicious sigue pensando que uno usa los enlaces como un feed (que lo viejo se pierde), pero no, muchos usamos a Delicious como un “Mis favoritos” en la nube y queremos acceder por rango de tiempo.

SimpleSudoku: Una reescritura desde 0, con TDD, de mi anterior AjSudoku, resuelve tableros de Sudoku.

Tengo que trabajar en:

SimpleDatabase: Base de datos en memoria, puede que en algún momento le agregue persistencia en archivos.

Y como siempre, todo esto es muy divertido ;-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

AjLisp en Ruby (1) Estructura, Clases y Tests

lopez — Sat, 03 Dec 2011 10:06:58 GMT

Estoy aprendiendo y practicando Ruby, y como es costumbre, lo hago escribiendo algo interesante para mí: el intérprete AjLisp (hace unos meses lo implementé en Javascript). TDD es mi amigo: escribo un test, lo ejecuto en rojo, codifico para pasarlo a verde, refactorear, y así sigue. El código de este nuevo intérprete, trabajo en progreso, en:

https://github.com/ajlopez/AjLispRb

Inicialmente (pueden ver los logs) escribí todo en un solo archivo (código y tests), siguiendo el simple y claro ejemplo:

http://kanemar.com/2006/03/04/screencast-of-test-driven-development-with-ruby-part-1-a-simple-example/

Vean que Ruby tiene un paquete ‘test/unit’ que ya viene en su instalación, listo para usar. Despues de algo de “research”, dividí el archivo en código de producción y código de pruebas. Quiero llegar a armar una gema (un paquete Ruby, distribuido por el utilitario gems), así que estudié los primeros pasos del tutorial:

http://guides.rubygems.org/

Tengo pendiente de leer y estudiar:

http://speakerdeck.com/u/pat/p/cut-polish-a-guide-to-crafting-gems
http://blog.thepete.net/2010/11/creating-and-publishing-your-first-ruby.html

Así que mi código aún no es una gema. Pero va teniendo la estructura de una:

El directorio lib contiene un solo archivo ajlisp.rb:

require 'ajlisp/list.rb'
require 'ajlisp/named_atom.rb'
require 'ajlisp/context.rb'
require 'ajlisp/string_source.rb'
require 'ajlisp/token.rb'
require 'ajlisp/lexer.rb'
require 'ajlisp/parser.rb'
require 'ajlisp/primitive.rb'
require 'ajlisp/primitive_first.rb'
require 'ajlisp/primitive_rest.rb'
require 'ajlisp/primitive_cons.rb'
require 'ajlisp/primitive_list.rb'
require 'ajlisp/primitive_closure.rb'
require 'ajlisp/fprimitive.rb'
require 'ajlisp/fprimitive_quote.rb'
require 'ajlisp/fprimitive_lambda.rb'
require 'ajlisp/fprimitive_flambda.rb'
require 'ajlisp/fprimitive_let.rb'
require 'ajlisp/fprimitive_closure.rb'
require 'ajlisp/fprimitive_define.rb'
require 'ajlisp/primitive_add.rb'
module AjLisp
@context = Context.new
@context.setValue "quote", FPrimitiveQuote.instance
@context.setValue "first", PrimitiveFirst.instance
@context.setValue "rest", PrimitiveRest.instance
@context.setValue "cons", PrimitiveCons.instance
@context.setValue "list", PrimitiveList.instance
@context.setValue "lambda", FPrimitiveLambda.instance
@context.setValue "flambda", FPrimitiveFLambda.instance
@context.setValue "let", FPrimitiveLet.instance
@context.setValue "define", FPrimitiveDefine.instance
@context.setValue "+", PrimitiveAdd.instance
def self.context
    return @context
end
def self.evaluate(context, item)
    if item.is_a? List or item.is_a? NamedAtom
        return item.evaluate(context)
    end
        
    return item	
end
end

Escribí algunas primitivas (formas normales, y formas especiales: estas últimas no evalúan sus parámetros antes de su aplicación, ejemplos: quote y define). Noten que los archivos adicionales los puse en un subdirectorio ajlisp dentro de lib, ¿por qué? Porque cuando este código sea instalado como una gema, todo el directorio lib estará disponible para require, y si hubiera un archivo ahí, se podría hacer require(‘elarchivo’). Es por eso que los archivos adicionales a ajlisp.rb se colocan en otro lado, evitando colisión de nombres. Se recomienda colocarlos debajo de lib (vean el código de gemas que tienen en su instalación de Ruby, o vean ejemplos en GitHub).

El el directorio test hay un archivo test.rb que incluye a los otros archivos de tests:

require 'ajlisp'
require 'test/unit'
require "test_list.rb"
require "test_named_atom.rb"
require "test_context.rb"
require "test_string_source.rb"
require "test_token.rb"
require "test_lexer.rb"
require "test_parser.rb"
require "test_primitive_first.rb"
require "test_primitive_rest.rb"
require "test_primitive_cons.rb"
require "test_primitive_list.rb"
require "test_primitive_closure.rb"
require "test_primitive_add.rb"
require "test_fprimitive_quote.rb"
require "test_fprimitive_lambda.rb"
require "test_fprimitive_let.rb"
require "test_fprimitive_closure.rb"
require "test_fprimitive_flambda.rb"
require "test_fprimitive_define.rb"
require "test_evaluate"

Pueden ejecutar los tests desde la línea de comando:

ruby –Ilib;test test\test.rb

En Windows, dejé el archivo runtest.cmd conteniendo esta línea. Los parámetros –Ilib;test le indican a Ruby que incluya los directorios lib y test para cuando tenga que resolver un require. De esta forma evito poner directorios explícitos (o usar __FILE__) en los require.

Algo de tests:

require 'ajlisp'
require 'test/unit'
class TestList < Test::Unit::TestCase
#...    
    def test_create_with_first
        list = AjLisp::List.new("foo")
        assert_equal("foo", list.first)
        assert_nil(list.rest)
    end
    
    def test_create_with_first_and_rest
        rest = AjLisp::List.new("bar")
        list = AjLisp::List.new("foo", rest)
        assert_equal("foo", list.first)
        assert_not_nil(list.rest)
        assert_equal("bar", list.rest.first)
        assert_nil(list.rest.rest)
    end
    
    def test_create_from_array
        list = AjLisp::List.make [1, "a", "foo"]
        assert_not_nil list
        assert_equal 1, list.first
        assert_equal "a", list.rest.first
        assert_equal "foo", list.rest.rest.first
        assert_nil list.rest.rest.rest
    end
#..
end

Cada lista en AjLisp es un objeto de esta clase, list.rb:

module AjLisp
class List
    attr_reader :first
    attr_reader :rest
    
    def initialize(first=nil, rest=nil)
        @first = first
        @rest = rest
    end
    
    def evaluate(context)
        form = AjLisp::evaluate(context, @first)
        form.evaluate(context, self)
    end
    
    def self.make(array)
        if array and array.length > 0
            first = array.shift
            
            if first.is_a? Array
                first = make(first)
            elsif first.is_a? Symbol
                first = NamedAtom.new first.to_s
            end
                        
            return List.new first, make(array)
        end 
        
        return nil
    end
end
end

Los méteodos de acceso first y rest son de sólo lectura. Gracias a la naturaleza no tipada de Ruby (facilidad que también encontré en la implementación de Javascript) la implementación de este intérprete es directa, sin mayor “ceremonia de código”.

En mis nuevos tests, ahora incluye el código DENTRO del módulo AjLisp, así me evito de escribir el prefijo AjLisp:: antes de referenciar a una clase:

require 'ajlisp'
require 'test/unit'
module AjLisp
class TestLexer < Test::Unit::TestCase
    def test_get_atom_token
        source = StringSource.new "atom"
        lexer = Lexer.new source
        token = lexer.nextToken
        
        assert_not_nil token
        assert_equal "atom", token.value
        assert_equal TokenType::ATOM, token.type
        assert_nil lexer.nextToken
    end
    def test_get_atom_token_with_spaces
        source = StringSource.new "  atom   "
        lexer = Lexer.new source
        token = lexer.nextToken
        
        assert_not_nil token
        assert_equal "atom", token.value
        assert_equal TokenType::ATOM, token.type
        assert_nil lexer.nextToken
    end
#...
end

Próximos tópicos: algunos detalles de implementación, primitives vs fprimitives, contexto (ambiente anidado con pares nombre/valor), lambdas y closures, el lexer y el parser.

Próximos pasos: completar las primitivas (let, letrec, definef, do, if…), macro (mlambda, definem, expansión de macros…)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo un Intérprete en .NET (Parte 9)

lopez — Fri, 28 Jan 2011 10:00:54 GMT

Anterior Post
Primer Post de la Serie

Esta vez, quiero agregar una pieza que falta: un composite command. El intérprete necesita una manera de ejecutar una lista de comandos, en cualquier lugar donde haya un comando: en un if/then, en el if/else, en el while, etc… Primero, escribí un test (esta version de abajo no es la versión inicial, es la final actual):

        [TestMethod]
        public void CreateAndEvaluateCompositeCommand()
        {
            BindingEnvironment environment = new BindingEnvironment();
            environment.SetValue("a", 0);
            ICommand add1 = this.MakeAddCommand("a", "a", 1);
            ICommand add2 = this.MakeAddCommand("a", "a", 2);
            CompositeCommand cmd = new CompositeCommand(new ICommand[] { add1, add2 });
            Assert.IsNotNull(cmd.Commands);
            Assert.AreEqual(2, cmd.Commands.Count);
            Assert.AreEqual(add1, cmd.Commands.First());
            Assert.AreEqual(add2, cmd.Commands.Skip(1).First());
            cmd.Execute(environment);
            Assert.AreEqual(3, environment.GetValue("a"));
        }
        private ICommand MakeAddCommand(string target, string source, int number)
        {
            IExpression add = new BinaryArithmeticBLOCKED EXPRESSION;
        }

El código mostrado es la versión ACTUAL. Durante el desarrollo, y usando TDD, escribí el código de a pasos cortos, y también apliqué refactoring. Pero la lección es: usar los tests para guiar nuestro desarrollo.

Todos los tests en verde:

Buen code coverage:

Pueden bajar la versión actual desde from InterpreterStep09.zip. Si quieren ver todos los steps, sigo enviando mi código a trunk/Interpreter en mi Google Code Project AjCodeKatas.

Próximos pasos: comando foreach, comando for, declaración de funciones, etc…

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo un Intérprete in .NET (Part 8)

lopez — Thu, 20 Jan 2011 10:27:20 GMT

Vuelvo a escribir sobre el tema: programar un intérprete, usando C# y algunas ideas de TDD. En este paso, agrego un nuevo ICommand, el WhileCommand:

Pueden bajarse la versión de este paso desde InterpreterStep08.zip. Si quieren ver todos los pasos, sigo manteniendo el códicon en trunk/Interpreter en mi Google Code Project AjCodeKatas.

El código de WhileCommand es simple:

    public class WhileCommand : ICommand
    {
        private IExpression condition;
        private ICommand command;
        public WhileCommand(IExpression condition, ICommand command)
        {
            this.condition = condition;
            this.command = command;
        }
        public IExpression Condition { get { return this.condition; } }
        public ICommand Command { get { return this.command; } }
        public void Execute(BindingEnvironment environment)
        {
            while (BooleanPredicates.IsTrue(this.condition.Evaluate(environment)))
                this.command.Execute(environment);
        }
    }

Noten que tengo ahora un nuevo BooleanPredicates. Nació de haber refctorizado el código anterior que usé en la implementación de IfCommand. Escribí en el anterior post sobre mis intenciones de hacer ese refactor. Usando TDD, escribí los tests de la nueva clase, ejemplo:

        [TestMethod]
        public void IsFalse()
        {
            Assert.IsTrue(BooleanPredicates.IsFalse(null));
            Assert.IsTrue(BooleanPredicates.IsFalse(string.Empty));
            Assert.IsTrue(BooleanPredicates.IsFalse(0));
            Assert.IsTrue(BooleanPredicates.IsFalse((short)0));
            Assert.IsTrue(BooleanPredicates.IsFalse((long)0));
            Assert.IsTrue(BooleanPredicates.IsFalse(0.0));
            Assert.IsTrue(BooleanPredicates.IsFalse((float)0.0));
            Assert.IsFalse(BooleanPredicates.IsFalse(new object()));
            Assert.IsFalse(BooleanPredicates.IsFalse("foo"));
            Assert.IsFalse(BooleanPredicates.IsFalse(1));
            Assert.IsFalse(BooleanPredicates.IsFalse((short)2));
            Assert.IsFalse(BooleanPredicates.IsFalse((long)3));
            Assert.IsFalse(BooleanPredicates.IsFalse(4.0));
            Assert.IsFalse(BooleanPredicates.IsFalse((float)5.0));
        }

Vean: el test es una especie de especificación escrita en código, que contesta: ¿Qué es lo que considero como false en mi intérprete? Luego de tener el test en verde, pude agregar su llamada en el IfCommand (que YA estaba escrito) y ver de correr los tests de ese comando, para ver que todo siguiera funcionando.

El nuevo comando WhileCommand nació de haberlo testeado, ejemplo:

        [TestMethod]
        public void EvaluateWhileCommandUsingDecrement()
        {
            BindingEnvironment environment = new BindingEnvironment();
            environment.SetValue("a", 2);
            IExpression condition = new VariableBLOCKED EXPRESSION;
        }

Podría haber agregado más tests, como qué pasa si al WhileCommand le entrego una condición null, pero, por ahora, el nuevo comando goza de buena salud. Todos los tess siguen en verde:

Buen code coverage:

Próximos pasos: comandos composite, comandos for/foreach, declaración de funciones…

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD: Comparando Smalltalk y Java

lopez — Wed, 10 Nov 2010 16:06:44 GMT

Gracias al bueno de Hernan Wilkinson (@hernanwilkinson) tenemos estos videos, que muestran su comparación de TDD (Test-Driven Development) entre dos lenguajes: Smalltalk, con un entorno dinámico, y Java, un lenguaje con tipos estáticos.

(Please visit the site to view this media)
(Please visit the site to view this media)

Pueden encontrar una discusión del tema en el thread de Foro Agiles:

http://tech.groups.yahoo.com/group/foro-agiles/message/3571

Como aclara ahí, Hernan puso comparación de tiempos, para medir y comparar. Yo no haría hincapié en ese punto. Lo más a destacar es cómo Smalltalk permite, en el medio de la prueba, completar y arreglar lo que estamos programando. Como apunta en ese thread el bueno de @jgabardini, no se usa mucho el debugger enJava, usando TDD (lo mismo afirmaría para .NET y Visual Studio): lo que vamos programando, va naciendo de a poco, por tests, digamos, incrementales. Diría que uno va avanzando por “baby steps” que disminuyen casi a cero la necesidad de depuración en el proceso.

Si bien Hernan plantea una comparación entre lenguajes dinámicos y estáticos, pienso que eligió uno muy particular como dinámico. Hacer TDD con Python, Ruby y otros lenguajes dinámicos, puede ser bastante diferente que en Smalltalk y su entorno.

Nos leemos!

Angel “Java” Lopez

Escribiendo un Intérprete en .NET (Parte 7)

lopez — Tue, 05 Oct 2010 09:22:55 GMT

Vuelta al ruedo! Un nuevo post en esta serie. En los anteriores posts, estuve escribiendo un intérprete en .NET, usando TDD (Test-Driven Development). Ya tengo un parser, un lexer, algunas expresiones y solamente un comando. Es hora de agregar un nuevo comando a mi intérprete. El nuevo comando es IfCommand:

Pueden bajarse el código fuente desde Interpreter07.zip.

La clase IfCommand implementa la interfaz ICommand. Fue armada usando TDD: escribiendo los test, haciendo que compilen, primero en rojo, luego en verde, refactor. Mis primeros tests:

        [TestMethod]
        public void CreateIfCommand()
        {
            IExpr ession condition = new ConstantExpr ession(0);
            ICommand thenCommand = new SetCommand("a", new ConstantExpr ession(1));
            ICommand elseCommand = new SetCommand("b", new ConstantExpr ession(2));
            IfCommand command = new IfCommand(condition, thenCommand, elseCommand);
            Assert.AreEqual(condition, command.Condition);
            Assert.AreEqual(thenCommand, command.ThenCommand);
            Assert.AreEqual(elseCommand, command.ElseCommand);
        }
        [TestMethod]
        public void EvaluateIfCommandWithZeroAsCondition()
        {
            IExpr ession condition = new ConstantExpr ession(0);
            ICommand thenCommand = new SetCommand("a", new ConstantExpr ession(1));
            ICommand elseCommand = new SetCommand("b", new ConstantExpr ession(2));
            IfCommand command = new IfCommand(condition, thenCommand, elseCommand);
            BindingEnvironment environment = new BindingEnvironment();
            command.Execute(environment);
            Assert.IsNull(environment.GetValue("a"));
            Assert.AreEqual(2, environment.GetValue("b"));
        }

La implementación de IfCommand:

    public class IfCommand : ICommand
    {
        private IExpr ession condition;
        private ICommand thenCommand;
        private ICommand elseCommand;
        public IfCommand(IExpr ession condition, ICommand thenCommand)
            : this(condition, thenCommand, null)
        {
        }
        public IfCommand(IExpr ession condition, ICommand thenCommand, ICommand elseCommand)
        {
            this.condition = condition;
            this.thenCommand = thenCommand;
            this.elseCommand = elseCommand;
        }
        public IExpr ession Condition { get { return this.condition; } }
        public ICommand ThenCommand { get { return this.thenCommand; } }
        public ICommand ElseCommand { get { return this.elseCommand; } }
        public void Execute(BindingEnvironment environment)
        {
            object result = this.condition.Evaluate(environment);
            bool cond = !IsFalse(result);
            if (cond)
                this.thenCommand.Execute(environment);
            else if (this.elseCommand != null)
                this.elseCommand.Execute(environment);
        }
        private static bool IsFalse(object obj)
        {
            if (obj == null)
                return true;
            if (obj is bool)
                return !(bool)obj;
            if (obj is int)
                return (int)obj == 0;
            if (obj is string)
                return string.IsNullOrEmpty((string)obj);
            if (obj is long)
                return (long)obj == 0;
            if (obj is short)
                return (short)obj == 0;
            if (obj is double)
                return (double)obj == 0;
            if (obj is float)
                return (float)obj == 0;
            return false;
        }
    }

IfCommand evalúa una expresión, que retorne un objeto. Este objeto podría no ser un booleano. Tomé la decisión de evaluar null, 0, string vacío como false (algo parecido a lo que hace PHP). El único lugar donde necesito evaluar un objeto cualquiera como verdadero o false es, ahora, en este método IfCommand.Execute. Así, esta lógica de evaluación está ahora en un método privado. Planeo refactorearlo, moverlo a otra clase, en cuanto lo necesite desde otros lugares, como cuando implemente el comando WhileCommand y otras expresiones.

Después de escribir IfCommand, necesitaba parsear comandos, no sólo expresiones. No tenía un método .ParseCommand() en la clase Parser. Mis primeros tests (hay más en el código):

        [TestMethod]
        public void ParseAndEvaluateSimpleIfCommand()
        {
            Parser parser = new Parser("if (a) b=1; else b=2;");
            ICommand command = parser.ParseCommand();
            Assert.IsNotNull(command);
            Assert.IsInstanceOfType(command, typeof(IfCommand));
            BindingEnvironment environment = new BindingEnvironment();
            command.Execute(environment);
            Assert.AreEqual(2, environment.GetValue("b"));            
        }

Luego, implementé nuevos métodos en Parser:

Parser.ParseCommand() tienen una implementación ingenua. Solamente dos clases de comandos son soportados: comandos if, y comandos de seteo de variables:

        public ICommand ParseCommand()
        {
            Token token = this.NextToken();
            if (token == null)
                return null;
            if (token.TokenType == TokenType.Name && token.Value.Equals("if"))
                return ParseIfCommand();
            this.PushToken(token);
            return ParseSetCommand();
        }
        private ICommand ParseSetCommand()
        {
            string name = this.ParseName();
            this.ParseToken(TokenType.Operator, "=");
            IExpr ession expr = this.ParseExpr ession();
            this.ParseToken(TokenType.Separator, ";");
            return new SetCommand(name, expr);
        }
        private ICommand ParseIfCommand()
        {
            IExpr ession condition;
            ICommand thencmd;
            ICommand elsecmd;
            this.ParseToken(TokenType.Separator, "(");
            condition = this.ParseExpr ession();
            this.ParseToken(TokenType.Separator, ")");
            thencmd = this.ParseCommand();
            Token token = this.NextToken();
            if (token != null && token.TokenType == TokenType.Name && token.Value.Equals("else")) 
            {
                elsecmd = this.ParseCommand();
                return new IfCommand(condition, thencmd, elsecmd);
            }
            if (token != null)
                this.PushToken(token);
            return new IfCommand(condition, thencmd);
        }

Todos los tests quedaron en verde:

Buen code coverage:

Próximos pasos: agregar más comandos (while, for, etc…), declaraciones de funciones, manejo de números reales, etc.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo un intérprete en .NET (Parte 6)

lopez — Tue, 21 Sep 2010 09:29:10 GMT

Ahora, en este paso, he agregado: procesamiento de string, expresiones binarias, expresiones aritméticas, reconocimiento en el parser de esas expresiones, usando precedencia y paréntesis.

El código puede bajarse desde InterpreterStep06.zip.

Procesamiento de Strings

El lexer ahora puede procesar strings, delimitados con dobles comillas, y reconoce el caracter de escape. Soporta strings multilineas. Para eso, fui escribiendo tests, al comienzo en rojo, y luego fui implementando la funcionalidad en el código. Algunos tests (hay más en código):

        [TestMethod]
        public void ProcessSimpleString()
        {
            Lexer lexer = new Lexer("\"foo\"");
            Token token = lexer.NextToken();
            Assert.IsNotNull(token);
            Assert.AreEqual(TokenType.String, token.TokenType);
            Assert.AreEqual("foo", token.Value);
            Assert.IsNull(lexer.NextToken());
        }
        [TestMethod]
        [ExpectedException(typeof(LexerException), "Unclosed string")]
        public void RaiseIfStringIsUnclosed()
        {
            Lexer lexer = new Lexer("\"foo");
            Token token = lexer.NextToken();
        }

Expresiones aritméticas y binarias

Agregué una nueva clase abstracta BinaryExpr ession (derivada luego de tener los tests sobre una concreta, BinaryArithmeticExpr ession):

BinaryExpr ession evalua dos expresiones, izquierda y derecha, y aplica la operación abstracta:

    public abstract class BinaryExpr ession : IExpr ession
    {
        IExpr ession leftExpr ession;
        IExpr ession rightExpr ession;
        public BinaryExpr ession(IExpr ession leftExpr ession, IExpr ession rightExpr ession)
        {
            this.leftExpr ession = leftExpr ession;
            this.rightExpr ession = rightExpr ession;
        }
        public IExpr ession LeftExpr ession { get { return this.leftExpr ession; } }
        public IExpr ession RightExpr ession { get { return this.rightExpr ession; } }
        public object Evaluate(BindingEnvironment environment)
        {
            object leftValue = this.leftExpr ession.Evaluate(environment);
            object rightValue = this.rightExpr ession.Evaluate(environment);
            return Apply(leftValue, rightValue);
        }
        public abstract object Apply(object leftValue, object rightValue);
    }

Definí operadores aritméticos, que tengo que extender en el futuro:

    public enum ArithmeticOperator
    {
        Add,
        Subtract,
        Multiply,
        Divide
    }

BinaryArithmeticExpr ession usa Microsoft.VisualBasic.CompilerServices.Operators. Estos métodos ayudantes, que agregué referenciando a la librería de VB.NET que viene con el framework, pueden sumar, restar, multiplicar, dividir dos objetos, detectando si son números:

    public class BinaryArithmeticExpr ession : BinaryExpr ession
    {
        private ArithmeticOperator @operator;
        public ArithmeticOperator Operator { get { return this.@operator; } }
        public BinaryArithmeticExpr ession(IExpr ession leftExpr ession, IExpr ession rightExpr ession, ArithmeticOperator @operator)
            : base(leftExpr ession, rightExpr ession)
        {
            this.@operator = @operator;
        }
        public override object Apply(object leftValue, object rightValue)
        {
            switch (this.@operator)
            {
                case ArithmeticOperator.Add:
                    return Operators.AddObject(leftValue, rightValue);
                case ArithmeticOperator.Subtract:
                    return Operators.SubtractObject(leftValue, rightValue);
                case ArithmeticOperator.Multiply:
                    return Operators.MultiplyObject(leftValue, rightValue);
                case ArithmeticOperator.Divide:
                    return Operators.DivideObject(leftValue, rightValue);
            }
            throw new InvalidOperationException(string.Format("Unknow operator '{0}'", this.@operator));
        }
    }

Algunos tess (más en código):

        [TestMethod]
        public void EvaluateAddExpr ession()
        {
            ConstantExpr ession leftExpr ession = new ConstantExpr ession(1);
            ConstantExpr ession rightExpr ession = new ConstantExpr ession(2);
            BinaryArithmeticExpr ession Expr ession = new BinaryArithmeticExpr ession(leftExpr ession, rightExpr ession, ArithmeticOperator.Add);
            Assert.AreEqual(3, Expr ession.Evaluate(null));
        }
        [TestMethod]
        public void EvaluateSubtractExpr ession()
        {
            ConstantExpr ession leftExpr ession = new ConstantExpr ession(1);
            ConstantExpr ession rightExpr ession = new ConstantExpr ession(2);
            BinaryArithmeticExpr ession Expr ession = new BinaryArithmeticExpr ession(leftExpr ession, rightExpr ession, ArithmeticOperator.Subtract);
            Assert.AreEqual(-1, Expr ession.Evaluate(null));
        }

Mejoras en el Parser

El Parser tiene nuevos métodos privados ParseSimpleExpr ession, ParseFactorExpr ession:

Son las implementaciones que surgieron al satisfacer los tests (más tests en el código):

        [TestMethod]
        public void ParseAndEvaluateAddAndMultiplyExpr ession()
        {
            Parser parser = new Parser("1+2*3");
            IExpr ession Expr ession = parser.ParseExpr ession();
            Assert.IsNotNull(Expr ession);
            Assert.IsInstanceOfType(Expr ession, typeof(BinaryArithmeticExpr ession));
            Assert.AreEqual(7, Expr ession.Evaluate(null));
            Assert.IsNull(parser.ParseExpr ession());
        }
        [TestMethod]
        public void ParseAndEvaluateAddAndMultiplyExpr essionWithParenthesis()
        {
            Parser parser = new Parser("(1+2)*3");
            IExpr ession Expr ession = parser.ParseExpr ession();
            Assert.IsNotNull(Expr ession);
            Assert.IsInstanceOfType(Expr ession, typeof(BinaryArithmeticExpr ession));
            Assert.AreEqual(9, Expr ession.Evaluate(null));
            Assert.IsNull(parser.ParseExpr ession());
        }

De esta manera, puedo reconocer operadores binarios, procesarlos según su precedencia, y usar paréntesis para alterar el orden de evaluación.

Todos los tests en verde:

Buen code coverage:

Próximos pasos

Me gustaría agregar proceso de números reales, definiciones de funciones, más operadores, comandos if, for.

Keep tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo un intérprete en .NET (Parte 5)

lopez — Mon, 20 Sep 2010 09:11:00 GMT

Continuando con esta serie de posts, esta vez agregaré un parser sencillo. La nueva solución:

Pueden bajar el código desde InterpreterStep05.zip. La nueva clase agregada es:

El parse puede ser construido usando un TextReader o un string:

    public class Parser
    {
        private Lexer lexer;
        public Parser(Lexer lexer)
        {
            this.lexer = lexer;
        }
        public Parser(TextReader reader)
            : this(new Lexer(reader))
        {
        }
        public Parser(string text)
            : this(new Lexer(text))
        {
        }
//...
    }

Tengo sólo dos Expr essions por ahora (ConstantExpr ession y VariableExpr ession). El método público ParseExpr ession ahora reconoce enteros y nombres(el lexer todavía no reconoce strings delimitados):

        public IExpr ession ParseExpr ession()
        {
            Token token = this.NextToken();
            if (token == null)
                return null;
            if (token.TokenType == TokenType.Integer)
                return new ConstantExpr ession(token.Value);
            if (token.TokenType == TokenType.String)
                return new ConstantExpr ession(token.Value);
            if (token.TokenType == TokenType.Name)
                return new VariableExpr ession((string) token.Value);
            throw new InvalidDataException(string.Format("Unexpected token '{0}'",
                 token.Value));
        }

El parser usa al lexer que comenté en el anterior post de la serie. Como antes, el nuevo Parser y el método ParseExpr ession fueron escritos usando TDD. Algunos tests:

        [TestMethod]
        public void ParseIntegerExpr ession()
        {
            Parser parser = new Parser("1");
            IExpr ession Expr ession = parser.ParseExpr ession();
            Assert.IsNotNull(Expr ession);
            Assert.IsInstanceOfType(Expr ession, typeof(ConstantExpr ession));
            Assert.AreEqual(1, Expr ession.Evaluate(null));
            Assert.IsNull(parser.ParseExpr ession());
        }
        [TestMethod]
        public void ParseVariableExpr ession()
        {
            Parser parser = new Parser("one");
            IExpr ession Expr ession = parser.ParseExpr ession();
            Assert.IsNotNull(Expr ession);
            Assert.IsInstanceOfType(Expr ession, typeof(VariableExpr ession));
            VariableExpr ession varexpr = (VariableExpr ession)Expr ession;
            Assert.AreEqual("one", varexpr.Name);
            Assert.IsNull(parser.ParseExpr ession());
        }

Todos los tes están en verde:

Buen code coverage:

Noten que usando TDD puedo agregar características nuevas en “baby steps” (pasos de bebé), evitando tiempos de depuración o agregar grandes fragmentos de código de una vez. Y siempre tengo al retroalimentación “verde”: cada cosa nueva que se agrega se prueba compatible con el anterior código.

Próximos pasos: agregar más expresiones (aritmética, operadores, ..) y comandos (como if, for, …), “entrenando” al parser en reconocerlas,. Luego puedo agregar al lexer el proceso de strings delimitados por dobles comillas.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo un intérprete en .NET (Parte 4)

lopez — Sat, 18 Sep 2010 10:15:29 GMT

En este post, agrego un analizador léxico, un lexer, para procesar texto y separar el código en tokens, las “palabras” de nuestra entrada.

La nueva solución:

Pueden bajar el código de InterpreterStep04.zip. Hice refactor de la versión anterior: ahora la class library Interpreter tiene tres directorios y namespaces: Commands, Expressions, Compiler.

El nuevo código es:

El TokenType es una enumeración:

    public enum TokenType
    {
        Name,
        String,
        Integer,
        Operator,
        Separator
    }

Token representa una “palabra” de nuestro lenguaje:

    public class Token
    {
        public TokenType TokenType { get; private set;  }
        public object Value { get; private set;  }
        public Token(TokenType type, object value)
        {
            this.TokenType = type;
            this.Value = value;
        }
    }

Value contiene el token detectado: su valor entero si era un entero, o su texto, si era un nombre o separador u operador.

Lexer está encargado de detectar el próximo token desde un TextReader o desde un string:

       public Lexer(TextReader reader)
        {
            this.reader = reader;
        }
        public Lexer(string text)
            : this(new StringReader(text))
        {
        }
        public Token NextToken()
        {
            int ch;
            for (ch = this.NextChar(); ch != -1 && char.IsWhiteSpace((char)ch); ch = this.NextChar())
                ;
            if (ch == -1)
                return null;
//...
        }

Lexer fue escrito en “baby-steps” (pasos de bebé), siguiendo la evolución de los test (recuerden, estoy usando TDD). Escribí un tests, y modifiqué el código para que pasara a verde, y así. Tests como:

        [TestMethod]
        public void ProcessNameWithWhitespaces()
        {
            Lexer lexer = new Lexer("  one  ");
            Token token = lexer.NextToken();
            Assert.IsNotNull(token);
            Assert.AreEqual(TokenType.Name, token.TokenType);
            Assert.AreEqual("one", token.Value);
            Assert.IsNull(lexer.NextToken());
        }
        [TestMethod]
        public void ProcessTwoNames()
        {
            Lexer lexer = new Lexer("one two");
            Token token = lexer.NextToken();
            Assert.IsNotNull(token);
            Assert.AreEqual(TokenType.Name, token.TokenType);
            Assert.AreEqual("one", token.Value);
            token = lexer.NextToken();
            Assert.IsNotNull(token);
            Assert.AreEqual(TokenType.Name, token.TokenType);
            Assert.AreEqual("two", token.Value);
            Assert.IsNull(lexer.NextToken());
        }
        [TestMethod]
        public void ProcessNameAndSeparator()
        {
            Lexer lexer = new Lexer("one;");
            Token token = lexer.NextToken();
            Assert.IsNotNull(token);
            Assert.AreEqual(TokenType.Name, token.TokenType);
            Assert.AreEqual("one", token.Value);
            token = lexer.NextToken();
            Assert.IsNotNull(token);
            Assert.AreEqual(TokenType.Separator, token.TokenType);
            Assert.AreEqual(";", token.Value);
            Assert.IsNull(lexer.NextToken());
        }

La versión actual (en este paso) del lexer solo reconoce nombres, algunos separadores como “;” y algún operador como “=”. No procesa strings delimitados, números reales u otros separadores y operadores. Mi idea es ir agregando más capacidades a medida que escriba más tests.

Todos los tests de la solución en verde:

Buen code coverage:

Próximos pasos: escribir un parser que reconozca expresiones, luego que procese comandos, y agregar comandos como if y for, así como definición de funciones. Esto es un intérprete, pero en una nueve serie de posts, podría tratar de compilarlo a código .NET nativo, usando Reflection.Emit or CodeDom.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo un intérprete en .NET (Parte 3)

lopez — Fri, 17 Sep 2010 09:30:55 GMT

Esta es la tercera parte de esta serie:

Writing an Interpreter in .NET (Part 1)
Escribiendo un intérprete en .NET (Parte 1)
Writing an Interpreter in .NET (Part 2)
Escribiendo un intérprete en .NET (Parte 2)

Hasta ahora, tenemos implementado IExpression, ConstantExpression and VariableExpression, usando un BindingEnvironment para almacenar un diccionaro de nombres-valores para las variables. Podría reimplementar este environment u otras partes si necesito nueva funcionalidad: usando TDD, es relativamente fácil agregar nuevas características, preservando las anteriores (eso pasó en la parte 2, donde al agregar BindingEnvironment cambió el Evaluate de las IExpressions.

En este post, quiero agregar comandos (pueden bajar el código desde InterpreterStep03.zip):

Esta interfaz ICommand es:

namespace Interpreter
{
    public interface ICommand
    {
        void Execute(BindingEnvironment environment);
    }
}

El método Execute recibe el estado actual, ahora representado por un BindingEnvironment. El código fue desarrollado usando TDD: no necesito nada más para implementar los tests.

Primer comando para implementar: SetCommand, que pone un valor en una variable usando el nombre y una expresión a evaluar:

Primeros tests:

        [TestMethod]
        public void CreateSetCommand()
        {
            SetCommand command = new SetCommand("foo", new 
                ConstantExpr ession(1));
            Assert.AreEqual("foo", command.Name);
            Assert.IsInstanceOfType(command.Expression, typeof(ConstantExpression));
        }
        [TestMethod]
        public void ExecuteSetCommand()
        {
            BindingEnvironment environment = new BindingEnvironment();
            ICommand command = new SetCommand("one", new ConstantExpr ession(1));
            command.Execute(environment);
            Assert.AreEqual(1, environment.GetValue("one"));
        }

El código de implementación:

    public class SetCommand : ICommand
    {
        private string name;
        private IExpression expression;
        public SetCommand(string name, IExpression expression)
        {
            this.name = name;
            this.expression = expression;
        }
        public string Name { get { return this.name; } }
        public IExpression Expression { get { return this.expression; } }
        public void Execute(BindingEnvironment environment)
        {
            environment.SetValue(this.name, this.expression.Evaluate(environment));
        }
    }

Noten que el nombre de la variable y la expresión a evaluar son entregadas en el constructor.

Ahora, los tests están en verde:

Buen coverage:

Próximo paso: agregar un lexer, analizador léxico, que toma un string o un archivo, y va separando los tokens: las “palabras” de nuestro lenguaje a interpretar. Vean que podríamos implementar todo el núcleo del lenguaje (expresiones, comandos, variables…) por un lado, en un proyecto, y la sintaxis en otro (o en varios otros, usar distintos lenjuages externos, de distintas sintaxis, para construir las instancias de un árbol de evaluación). Por simplicidad, agregaré el lexer y después el parser en el mismo proyecto.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo un intérprete en .NET (Parte 2)

lopez — Thu, 16 Sep 2010 09:41:01 GMT

En mi anterior post:

Writing an Interpreter in .NET (Part 1)
Escribiendo un intérprete en .NET (Parte 1)

Presenté expresiones y la implementación de ConstantExpression. Hoy quiero implementar una expresión de variable: una expresión que dado el nombre de una variable retorna su valor asociado. El código de este paso lo pueden bajar desde InterpreterStep02.zip. Y de nuevo, lo quiero implementar usando Test-Driven Development. El código que se bajen es el FINAL del proceso, pero espero que igual sirva como ejemplo de esta forma de desarrollo.

Pueden seguir el código de esta serie y mis progresos en mi AjCodeKata Google Project, en el trunk, dentro del directorio Interpreter. Si quieren ejemplos más complejos, también armados con TDD, ver AjSharp, AjTalk, AjLisp.

La solución de este paso:

Implementé un BindingEnvironment, un lugar donde salvar los nombres de variables y sus valores asociados:

Mis tests:

    public class BindingEnvironmentTests
    {
        [TestMethod]
        public void SetAndGetValue()
        {
            BindingEnvironment environment = new BindingEnvironment();
            environment.SetValue("one", 1);
            Assert.AreEqual(1, environment.GetValue("one"));
        }
        [TestMethod]
        public void GetNullIfUndefinedName()
        {
            BindingEnvironment environment = new BindingEnvironment();
            Assert.IsNull(environment.GetValue("undefined"));
        }
    }

Noten que especifiqué que obtener un valor no definido no da error sino que retorna null. Si hubiera decidido lanzar una excepción, mi tests hubiera debido reflejar esa decisión. Quiero que al usar un lenguaje no sea necesario definir variables, sino simplemente usarlas. Si una variable no “existe”, no está inicializada, entonces es como si tuviera null.

Después, cambié IExpression.Evaluate para que acepte un BindingEnvironment como parámetro:

    public interface IExpression
    {
        object Evaluate(BindingEnvironment environment);
    }

Escribí una nueva VariableExpression (y adapté la ya existente ConstantExpression):

Mis tests:

        [TestMethod]
        public void EvaluateIntegerVariable()
        {
            BindingEnvironment environment = new BindingEnvironment();
            IExpression expression = new VariableBLOCKED EXPRESSION;
        }

Todos los tests, ahora, están en verde:

Pero recuerden: eso es el final. Usando TDD fue pasando de rojo, a verde, a refactor.

Buen code coverage:

Próximos pasos: implementar comandos y un SetCommand: que cambie el valor de una variable. De nuevo, escribir todo eso usando TDD.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo un intérprete en .NET (Parte 1)

lopez — Wed, 15 Sep 2010 10:38:22 GMT

Hace un poco más de una semana, tuve la oportunidad de dar una charla sobre compiladores e intérpretes en .NET, en el Code Camp Buenos Aires http://www.codecamp.com.ar

Escribí varios intérpretes en .NET (AjSharp, AjTalk, AjLisp….) y sigo con ese desarrollo. Pero ahore, me gustaría ir explorando los pasos que sigo para escribir un simple intérprete, sin usar herramientas de construcción de gramáticas.

Primero, uso Driven Development. Para cada cosa que agrego en código, escribo el test, lo ejecuto en rojo, cambio el código para que quede en verde, y luego refactor. Pueden bajar el código de este primer post desde InterpreterStep01.zip). La solución es:

El punto de partida es una expression.

namespace Interpreter
{
    public interface IExpression
    {
        object Evaluate();
    }
}

Escribí una interfaz, pero podría haber escrito una primera clase concreta, y entonces, extraer la interfaz luego de tener algo andando. En este intérprete simple, una expresión es algo a ser evaludado, como

3
”foo”
3+5
fun(a)

La primera clase concreta es ConstantExpression: new ConstantBLOCKED EXPRESSION; } }

Los tests están en verde:

Buen code coverage:

Bien, es un ejemplo muy simple. Pero es un punto de partida. Próximos pasos: agregar el manejo de variables, su evaluación. Y luego, agregaré comandos, la asignaciónde valor a una variable. Podría escribir funciones, analizador léxico, parser, y más, todo usando TDD.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

CodeCamp en Buenos Aires: Intérpretes y Compiladores en .NET

lopez — Tue, 31 Aug 2010 09:21:16 GMT

El próximo sábado tendremos CodeCamp en Buenos Aires:

http://www.codecamp.com.ar

Les recomiendo una visita al blog (en la página principal) y a la agenda:

http://www.codecamp.com.ar/agenda.aspx

donde hay actividades y charlas desde la mañana hasta la tarde, sobre Azure, Entity Framework 4, .NET 4, Arquitectura de Software (por @MartinSalias), WPF, IronRuby, DynamicDataCenter, SQL Server, Silverlight, ASP.NET MVC, HyperV, WCF, SQL Azure, HTML5, Windows 7, y demos de las Células (vean por ejemplo el video de Sinergia en una Célula Microsoft)

Gracias a @masaez, que me invitó al evento, en el Track 4 (16:35), Sala Arquitectura, daré una charla sobre Intérpretes y Compiladores en .NET. Los que me leen por aquí, saben que es uno de mis temas preferidos: construir lenguajes con distintos paradigmas de programación, y para usarlos en proyectos (como AjBasic en AjGenesis). La charla es de 75 minutos, con preguntas y respuestas.

Mi idea es visitar temas como:

- Cómo construir un Intérprete, con pasos en detalle, usando TDD.
- Tokens, Lexer, Parser, Expresiones, Comandos
- Ejemplos de intérpretes, de distintos tipos de lenguajes, como AjSharp, AjTalk (bytecodes a la Smalltalk), AjLisp (más funcional), o AjIo, tendré que elegir algunos.
- Comentar los lenguajes que han sido portados a .NET
- Descubrir IL (Intermediate Language) y generar código desde nuestros programas
- Ejemplo de AST (Abstract Syntax Tree)
- La aparición de los lambda. Compilación de Expressions
- Compilación dinámica de expressions
- Dynamic Runtime Library, ejemplos de lenguajes implementados
- Y espero transmitir algo de ¿por qué más lenguajes?

Como siempre, el código, enlace, presentación que prepare, quedaran aquí publicados en próximo post.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez