Angel "Java" Lopez : AjLisp

Implementando Lenguajes de Programación en Javascript, JsConf Argentina

lopez — Mon, 21 May 2012 10:47:19 GMT

Ayer, 20 de Mayo, tuve el gran gusto de presentar un tema que me gusta mucho, la implementación de lenguajes de programación, y en este caso, usando Javascript como lenguaje destino. Fue en la JSConf Argentina 2012:

http://jsconf.com.ar/

(Ya había escrito un post anunciando la conferencia) El día fue excelente, llena de interesantes charlas, muy bien organizada por @rauchg y su equipo (creo de @vulsai), tomé muchas notas, espero escribir uno o dos posts sobre el tema, en cuanto me recupere ;-) Mientras, pueden leer el post de @aijoona

http://blog.aijoona.com/2012/05/21/jsconf-ar-2012-mi-resumen/

Como ejemplo de charla, vean la de WebGL para javascripters de @gerbille:

http://www.slideshare.net/gerbille/webgl-para-javascripters

Este post contiene los enlaces y las implementaciones que visité y preparé para la charla, que tuvo poco de gráfico, y mucho, mucho de código. Debería comenzar a usar los lenguajes que presenté, para manejar temas gráficos en el cliente, por ejemplo WebGL, SVG, tal vez usar d3.js.

Mi presentación en mi Skydrive (nota: tengo que escribir la próxima presentación mía, supongo que será en el Ruby Meetup, en markdown y publicarla en HTML).

Lista de lenguajes que compilan a Javascript
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS

The JavaScript World Domination Plan at 16 Years
http://www.infoq.com/presentations/The-JavaScript-World-Domination-Plan-at-16-Years

Lisp as the Maxwell’s equations of software
http://www.michaelnielsen.org/ddi/lisp-as-the-maxwells-equations-of-software/

A Conversation with Alan Kay
http://queue.acm.org/detail.cfm?id=1039523

The Magnificent Seven
by Michael Fogus
http://fogus.me/static/preso/magnificent7/#slide1

McCarthy's Lisp in Python with macros
https://github.com/fogus/lithp

The roots of Lisp
http://www.paulgraham.com/rootsoflisp.html

Presenté AjLisp en Javascript
https://github.com/ajlopez/AjLispJs

Comenté y mostré demo de AjLogo en Javascript
https://github.com/ajlopez/AjLogoJs
Demo http://ajlopez.github.com/AjLogoJs/demo.html

Otras implementaciones de Logo en Javascript
http://www.calormen.com/Logo/
http://logo.twentygototen.org/

Recomendé ver a NetLogo http://ccl.northwestern.edu/netlogo/ (en Java) para ver hasta dónde ha llegado el tema.

Hice correr el REPL y el compilador de Clojurescript
https://github.com/clojure/clojurescript

Presenté a la AjTalk VM en C#, y desde el año pasado compila Smalltalk a Javascript
https://github.com/ajlopez/AjTalk

Este año agregué AjTalk en Javascript, con VM en bytecodes, y ejecutor de métodos compilados con AjTalk
https://github.com/ajlopez/AjTalkJs
Demo http://ajlopez.github.com/AjTalkJs/demo.html

Mostré una simple demo de clases Smalltalk compiladas a Javascript, que manejan google, y google.earth.

Levanté Amber y comenté cómo en su definición de métodos ponen Javascript nativo
http://amber-lang.net/

Visité la página de Smalltalk S8, U8
http://u8.smalltalking.net/
http://u8.smalltalking.net/browsecontributions.aspx

No pudimos ver las demos, justo en ese momento estuve sin conexión. Les comento algunos enlaces. Veamos dos:

Hay una Smalltalk S8 Console (con una compilación de V8 preparada para levantar código st)
http://u8.smalltalking.net/profile/smalltalking/125/index.html

Ver sus demos de Google Earth
http://u8.smalltalking.net/contribution.aspx?contributionId=222
(exploren las clases, creo que eran Google, GoogleEarth, GoogleEarthObject, GEDemo, etc…)

Mis posts sobre AjTalk, AjLisp, AjLogo implementations
http://ajlopez.wordpress.com/category/ajtalk/
http://ajlopez.wordpress.com/category/ajlisp/
http://ajlopez.wordpress.com/category/ajlogo/

http://msmvps.com/blogs/lopez/archive/tags/AjLisp/default.aspx
http://msmvps.com/blogs/lopez/archive/tags/AjLogo/default.aspx
http://msmvps.com/blogs/lopez/archive/tags/AjTalk/default.aspx

Mis posts sobre Javascript
http://msmvps.com/blogs/lopez/archive/tags/Javascript/default.aspx

Les agrego algunos enlaces sobre ClojureScript, que no mencioné

Introducing ClojureScript
http://clojure.com/blog/2011/07/22/introducing-clojurescript.html
de @stuartsierra

ClojureScript Rationale
https://github.com/clojure/clojurescript/blob/master/devnotes/cljs.org
de @stuarthalloway

Compiling Clojure to Javascript pt. 1 of n
http://blog.fogus.me/2011/07/21/compiling-clojure-to-javascript-pt1/
de @fogus

Ferret: An Experimental Clojure Compiler
http://nakkaya.com/2011/06/29/ferret-an-experimental-clojure-compiler/

Los enlaces que me interesaron, leí, estudié para esta charla, o los tengo pendientes:

http://delicious.com/ajlopez/clojurescript
http://delicious.com/ajlopez/javascript+parser
http://delicious.com/ajlopez/javascript+compiler
http://delicious.com/ajlopez/javascript+smalltalk

Nos leemos!

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

Ruby Buenos Aires Meetup Marzo 2012

lopez — Fri, 30 Mar 2012 11:59:16 GMT

Ayer tuve el gusto de asistir a mi segunda meetup de Ruby acá en Buenos Aires. Fue en Urban Station, un buen lugar para trabajadores móviles: pueden ir con su notebook y trabajar en una mesita, con WiFi, enchufe, pagando por hora, o alquilar salones chicos de reuniones. La gente de Ruby Argentina consiguió una sala con proyector. Llegué a las 18:20 (empeza 18:30), y me encontré con Esteban, arquitecto, programador PHP, que estaba en Ruby. Mientras esperábamos, aproveché para preguntarle por qué se usa en Arquitectura, me enteré de Build Information Modeling, ver mis enlaces http://delicious.com/ajlopez/bim. Tenía algo con ver con la charla que iba a dar, sobre AjLisp en Ruby (ver mis posts http://ajlopez.wordpress.com/category/ajlisp), porque AutoCad tuvo desde siempre AutoLisp como lenguaje de base de programación.

Poco a poco fue llegando más gente, como @soveran, @maceto, @inkel, creo que llegó @etagwerker pero no pude hablar con él.

El primer disertante fue… moi ;-). Presenté AjLisp en Ruby, ver https://github.com/ajlopez/AjLispRb. Hace dos días, encontré esta presentación:

How Emacs changed my life http://www.slideshare.net/yukihiro_matz/how-emacs-changed-my-life By Yukihiro "Matz", Ruby creator

Que me ayudó a poner la relación entre Lisp y Ruby. Conté algo de la historia de Lisp. Y destaqué que desarrollé AjLispRb usando TDD, desde el principio, para ir practicando y aprendiendo Ruby. Hice algunas demostraciones, mostrando rápidamente lambdas, define, closures y macros. Notablemente, cuando presenté que tiene una sintaxis tipo Java Dot Notation (ver http://jscheme.sourceforge.net/jscheme/doc/javadot.html) para acceder a objetos y clases Ruby, me preguntaron si esto anda en AjLisp:

(.require @Kernel "date”)

(.today @Date)

funcionó! ;-) Ni se me había ocurrido probarlo. En realidad, en vez de “@Kernel” puedo poner “pepe”, e igual termina invocando al método “global” require, tengo que investigar por qué. Jeje… AjLispRb tiene vida propia.

Luego presentó Michel Martens, gran programador Ruby, @soveran, y jugador de Go, ver https://github.com/soveran, por ejemplo, vean su framework web Cuba https://github.com/soveran/cuba. Presentó los elementos de uso de Rack, un tema que me interesa por su historia, relación con Python y otros. Ver mis enlaces http://delicious.com/ajlopez/rack. En un tiempo, quisiera preparar una charla corta sobre el tema, para algún Ruby Meetup u otro lugar.

Y notablemente, presentó algo muy interesante, Bandicoot:

http://bandilab.org/
http://www.readwriteweb.com/hack/2011/07/new-set-based-programming-language-bandicoot.php

Su presentación en:

http://files.soveran.com/bandicoot/ (hecha con https://github.com/nakajima/slidedown, ver https://github.com/soveran/slidedown-skeleton)

Interesante. Maneja conjuntos con operadores de álgebra relacional. Hmmm… interesante Code Kata para Pascual: implementar algo en C#, usando LINQ por debajo. Mis enlaces sobre el tema http://delicious.com/ajlopez/set+programminglanguages

Michel lo usó en un proyecto. Vean que Bandicoot levanta un servidor al que se accede por HTTP, y en su lenguaje se programa los “puntos de entrada” que se exponen por ese servidor HTTP. El escribió un cliente Ruby https://github.com/soveran/rel. También comentó sobre su parser de command line https://github.com/soveran/clap (vean el uso de lambdas de Ruby ahí).

Hubo otros temas que se trataron: el anuncio de Rails Girls en Buenos Aires:

http://railsgirls.com/buenosaires

Se propuso hacer un Ruby Camp, reunirse para programar, ya sea en un lugar abierto, o en un bar, o en una casa. Se anunció que ya se comenzó a organizar la Ruby Conf de 2012.

Se repartió “merchandising”, varios conseguimos una tarjeta de promoción de Code School http://www.codeschool.com/.

Un poco antes de las 21, se levantó la reunión que siguió con comida, bebida (supongo que agua mineral solamente ;-) en otros lugares de la zona de Palermo. Lo mío es la sopita de pollo, así que regresé a mi cubil principal.

Felicitaciones a la gente de Ruby Argentina por tener una comunidad tan activa y abierta.

Nos leemos!

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

AjLisp en Ruby (2) Contexto con Nombres y Valores

lopez — Thu, 29 Dec 2011 10:20:56 GMT

Anterior Post

Una de las primeras clases que implemente en AjLispRb es el ambiente (“environment”). Esta vez lo llamé contexto: un diccionaro donde guardar pares nombre/valor, los valores de los átomos con nombre. El código:

module AjLisp
class Context
    def initialize(parent = nil)
        @parent = parent
        @values = Hash.new
    end
    
    def getValue(name)
        if @values.has_key?(name)
            return @values[name]
        end
        
        if @parent != nil
            return @parent.getValue(name)
        end
        
        return nil
    end
    
    def setValue(name, value)
        @values[name] = value
    end
end
end

La clase fue codificada usando TDD (Test-Driven Development), los primeros tests en test/test_context.rb. Algunos tests:

def test_not_defined_is_nil
    context = AjLisp::Context.new
    assert_nil(context.getValue(:foo))
end
def test_set_and_get_value
    context = AjLisp::Context.new
    context.setValue(:foo, "bar")
    assert_equal("bar", context.getValue(:foo))
end
def test_get_value_from_parent
    parent = AjLisp::Context.new
    parent.setValue(:foo, "bar")
    context = AjLisp::Context.new(parent)
    assert_equal("bar", context.getValue(:foo))
end

Inicialmente, yo usaba strings para los nombre, pero ahora estoy usando los símbolos de Ruby como :foo. Tengo un test que asegura la independencia de los valores del contexto padre y del hijo:

def test_override_value_from_parent
    parent = AjLisp::Context.new
    parent.setValue(:foo, "bar")
    context = AjLisp::Context.new(parent)
    context.setValue(:foo, "bar2")
    assert_equal("bar2", context.getValue(:foo))
    assert_equal("bar", parent.getValue(:foo))
end

Cada contexto puede tener un contexto padre. Hay un contexto “tope”, definido lib/ajlisp.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 :mlambda, FPrimitiveMLambda.instance
@context.setValue :let, FPrimitiveLet.instance
@context.setValue :define, FPrimitiveDefine.instance
@context.setValue :do, FPrimitiveDo.instance
@context.setValue :if, FPrimitiveIf.instance
@context.setValue :definef, FPrimitiveDefinef.instance
@context.setValue :definem, FPrimitiveDefinem.instance
@context.setValue :+, PrimitiveAdd.instance
@context.setValue :-, PrimitiveSubtract.instance
@context.setValue :*, PrimitiveMultiply.instance
@context.setValue :/, PrimitiveDivide.instance
def self.context
    return @context
end
# ...
end

Los nuevos contexts son creado por varias primitivas. En el comienzo, existe el contexto tope definido arriba, como:

Si tenemos que definir una función que retorna el segundo elemento de una lista, podemos usar la primitiva define:

(define second (a) (first (rest a)))

ahora tenemos en el contexto tope una nueva entrada para second:

El contexto tope tiene ahí en esa nueva entrada el valor que representa un lambda (lambda (a) (first (rest a)) (en realidad, debería aclarar que se guarda el resultado de haber evaluado el lambda, que es un closure (clausura) pero ya llegaremos al tema en próximo post).

Cuando invocamos:

(second (quote (one two three)))

un nuevo contexto se crea, con su padre apuntando al contexto tope (de nuevo, es algo más complejo, veremos clausuras). Ese nuevo contexto tiene un par nombre/valor:

Este contexto es descartado LUEGO de esta evaluaciónThat de second (puede sobrevivir indirectamente si luego de la evaluación quedó referenciado por una clausura). Cuando definimos un valor simple:

(define one 1)

el contexto tope es modificado, para tener un nuevo par nombre/valor:

Próximos temas: primitivas y formas especiales, su invocación, clausuras, macros, e invocación de métodos nativos de Ruby.

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

AjLisp en Javascript (Parte 3) Define, Lambda y Closures

lopez — Tue, 06 Sep 2011 11:05:08 GMT

Anterior Post

Veamos la definición de nuevas formas en AjLisp, mi intérprete Lisp escrito en Javascript (github repository). Un forma especial clave en AjLisp es la define:

var defineForm = new SpecialForm();
defineForm.eval = function eval(list, env)
{
	var name = list.first().name();
	var value = list.rest().first();
	var body = list.rest().rest();
		
	if (isNil(body)) {
		value = evaluate(value, env);
	}
	else {
		value = new Closure(value, env, body);
	}		
		
	environment[name] = value;
	return value;
}

Se puede usar para definir datos simples globales. Mis primeros tests:

test("Evaluate Simple Expression with Atoms", function() {
	eval("(define one 1)");
	eval("(define two 2)");
	eval("(define three 3)");
	equal(eval("one"), 1);
	equal(eval("(quote one)").asString(), "one");
	equal(eval("(list one two three)").asString(), "(1 2 3)");
	equal(eval("(first (list one two three))"), 1);
	equal(eval("(rest (list one two three))").asString(), "(2 3)");
	equal(eval("(cons one (list two three))").asString(), "(1 2 3)");
});

Pero define está preparada también para recibir tres parámetros:

(define mapfirst (fn lst)
  (if (nilp lst)
    nil
    (cons
      (fn (first lst))
      (mapfirst fn (rest lst))
    )
  )
)

El primer parámetro es el nombre de la propiedad a definir en el ambiente (environment) global. El segundo parámetro es una lista de parámetros. El tercero es la forma a aplicar. Entonces, define se puede usar para definir nuevas funciones, formas. Es equivalente a

(define mapfirst (lambda (fn lst)
    (if (nilp lst)
      nil
      (cons
        (fn (first lst))
        (mapfirst fn (rest lst))
      )
    )
  )
)

Vean el lambda. Es una forma especial:

var lambdaForm = new SpecialForm();
lambdaForm.eval = function eval(list, env)
{
    var argnames = list.first();
    var body = list.rest();
    return new Closure(argnames, env, body);
}

Tanto define (con tres parámetros) como lambda terminan creando un Closure. La clausura recibe una lista de nombres de argumentos, un ambiente (closure environment) y un cuerpo. Entonces, cuando un closure se evalúa:

function Closure(argnames, closureenv, body) {
	body = new List(doForm, body);
	
	this.eval = function(args, environment) {
		var newenv = makeEnvironment(argnames, args, closureenv);
		return evaluate(body, newenv);
	};
}
	
Closure.prototype.evaluate = Form.prototype.evaluate;
Closure.prototype.apply = Form.prototype.apply;

La parta clave es el .eval: la evalucación de closure emplea un nuevo environment, basado NO EN EL ACTUAL, sino en el closureenv, el ambiente recibido en el constructor cuando la clausura fue creada. Esta es una típica implementación en un intérprete Lisp.

Próximos temas a discutir en posts: flambda, mlambda, evaluación de macros, y el parser.

Nos leemos!

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

AjLisp en Javascript (Parte 2) Evaluación de Listas, Formas y Formas Especiales

lopez — Wed, 31 Aug 2011 11:11:00 GMT

Anterior Post
Siguiente Post

En el anterior post presenté la estructura y creación de átomos y listas. Pero ¿Cómo se evalúa una lista en AjLisp? Como en otras implementaciones de Lisp, la cabeza de la lista apunta a algo (lo que se llama una forma o forma especial) que se aplica al resto de los elementos. Este es el comienzo del proceso de evaluación de una lista:

List.prototype.evaluate = function(environment) 
{
    var form = this.first().evaluate(environment);		
    return form.apply(this, environment);
}

El primer elemento debe ser un elemento que evaluado, da un objecto con un .apply como méetodo. Hay dos clases de formas: las normales y las especiales. La implementación de Form:

function Form() {
}
Form.prototype.evaluate = function(environment) { return this; }
Form.prototype.apply = function(list, environment) 
{ 
    if (isNil(list)) return this.eval(list, environment);
    var rest = list.rest();
    if (rest != null)
        rest = rest.evaluateList(environment);
    return this.eval(rest, environment); 
}

La implementación de las especiales:

function SpecialForm() {
}
SpecialForm.prototype.evaluate = function(environment) { return this; }
SpecialForm.prototype.apply = function(list, environment) 
{ 
    if (isNil(list)) return this.eval(list, environment);
    return this.eval(list.rest(), environment);
}

¿Notan la diferencia? Los elementos del resto de la lista SON EVALUADOS en una forma normal. Al contrario, una forma especial no los evalúa. ¿Por qué esa diferencia? Las formas especiales son “primitivas” como (if <cond> <then> <else>…) donde las partes <then> <else>… pueden evaluarse o no bajo el control de la forma especial. Vean:

Special Forms in Lisp

Special forms are those expressions in the Lisp language which do not follow normal rules for evaluation. Some such forms are necessary as primitives of the language, while others may be desirable in order to improve readability, control the evaluation environment, implement abstraction and modularity, affect the flow of control, allow extended scoping mechanisms, define functions which accept a variable number of arguments, or achieve greater efficiency. There exist several long-standing mechanisms for specifying the definition of special forms: FEXPR's, NLAMBDA's, and MACRO's.

¿Ejemplos de Form? Los escribí usando instancias, redefiniendo su método eval:

var listForm = new Form();
listForm.eval = function eval(list) 
{
	return list;
}
var nilpForm = new Form();
nilpForm.eval = function eval(list) 
{
	if (isNil(list))
		return true;
		
	return isNil(list.first());
}
var listpForm = new Form();
listpForm.eval = function eval(list) 
{
	if (isNil(list))
		return true;
		
	return isList(list.first());
}

Un ejemplo de forma especial, el ‘if’:

var ifForm = new SpecialForm();
ifForm.eval = function eval(list, env)
{
	var cond = evaluate(list.first(), env);
	var then = list.rest().first();
	var elsebody = list.rest().rest();
	
	if (!isNil(cond) && cond != false)
		return evaluate(then, env);
	while (!isNil(elsebody)) 
	{
		result = evaluate(elsebody.first(), env);
		elsebody = elsebody.rest();
	}
	
	return result;			
}

Se exponen en el enviroment global:

// Environment
var environment = new Environment();
environment.list = listForm;
environment.first = firstForm;
environment.rest = restForm;
environment.cons = consForm;
environment['do'] = doForm;
environment['if'] = ifForm;
// more settings in environment

Temas para próximos posts: environments, closures, lambdas, macros, el parser y TDD.

Nos leemos!

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

AjLisp en Javascript (Parte 1) Atomos, Listas y TDD

lopez — Sat, 20 Aug 2011 10:31:00 GMT

Siguiente Post

Estoy reescribiendo mi intérprete AjLisp usando Javascript. Pienso que un intérprete Lisp es un buen proyecto para aprender un lenguaje: simple, acotado pero no trivial. Nunca hubiera comenzado este proyecto sin usar TDD (Test-Driven Development): Javascript es muy dinámico y las herramientas que estoy usando (el browser, editor de texto) son limitadas. Sin la ayuda de TDD este proyecto hubiera sido difícil de desarrollar. TDD me divierte, avances en pequeños pasos y me ayuda a explorar e implementar buen diseño.

El código (con un parse, varias formas primitivas implementadas, algo de proceso de macros, trabajo en progreso) está en GitHub:

https://github.com/ajlopez/AjLispJs

El código reside en un solo archivo: https://github.com/ajlopez/AjLispJs/blob/master/src/ajlisp.js

Estoy usando QUnit para los tests:

La implementación usa el patrón namespace:

AjLisp = function() {
// ...
}();

El namespace es el resultado de evaluar una función. Esta función retorna un objeto con los miembros públicos que quiero exponer del namespace:

return {
	// Classes
	List: List,
	Environment: Environment,
	Atom: Atom,
	Closure: Closure,
	Lexer: Lexer,
	TokenType: TokenType,
	Parser: Parser,
	
	// Functions
	makeList: makeList,
	isAtom: isAtom,
	isList: isList,
	isNil: isNil,
	asString: asString,
	evaluate: evaluate,
	
	// Top Environment
	environment: environment
}

Como es usual, un intérprete Lisp debe soportar listas y átomos. Código parcial de mi implementación de lista:

function List(first, rest) {
	function getFirst() {
		return first;
	}
	
	function getRest() {
		return rest;
	}
	
	this.first = getFirst;
	this.rest = getRest;
}
List.prototype.isAtom = function() { return false; }
List.prototype.isList = function() { return true; }
List.prototype.evaluate = function(environment) 
{
	var form = this.first().evaluate(environment);		
	return form.apply(this, environment);
}	
// ...

Noten que first y rest están encapsuladas en el closure del constructor. Son inmutables y puede accederse solamente desde funciones alist.first() y alist.last(). Debería evaluar el impacto de usar un closure en la construcción de una lista. Pero parece que es relativamente liviano.

La implementación de Atom es simple:

function Atom(name) {
	this.evaluate = function(environment) {
		return environment.getValue(name);
	};
	
	this.name = function() { return name; };
}
Atom.prototype.isAtom = function() { return true; }
Atom.prototype.isList = function() { return false; }
Atom.prototype.asString = function() { return this.name(); }
Atom.prototype.equals = function(atom)
{
	if (isNil(atom) || !isAtom(atom))
		return false;
		
	return this.name() == atom.name();
}

Su evaluación se basa en un environment (un diccionario que asocia nombres con valores, pero que pueden estar anidados: un environment puede ser padre de otro) y en el nombre del átomo. Números, strings son objetos Javascript y no necesitan ser implementados como átomos. En una implementación “clásica” de Lisp todos los elementos son SExpressions (expresiones simbólica) capaces de ser evaluadas. Ahora, yo tengo un AjLisp.evaluate que acepta cualquier objeto Javascript y detecta si puede ser evaluado en un environment:

function evaluate(x, environment)
{
	if (x === null || x === undefined)
		return x;
		
	if (x.evaluate != undefined && typeof(x.evaluate) == "function")
		return x.evaluate(environment);
		
	return x;
}

Test de Atomos:

test("Atom", function() {
	var environment = new AjLisp.Environment();
	environment.setValue("one", 1);
	var one = new AjLisp.Atom("one");
	equal(one.evaluate(environment), 1);
	ok(one.isAtom());
	equal(one.isList(), false);
	ok(AjLisp.isAtom(one));
	equal(AjLisp.isList(one), false);
	equal(one.asString(), "one");
	equal(one.equals(one), true);
	var one2 = new AjLisp.Atom("one");
	equal(one.equals(one2), true);
});

Test probando la conducta de Listas:

test("List", function() {
	var list = new AjLisp.List(1,2);
	equals(list.first(), 1);
	equals(list.rest(), 2);
	equal(list.isAtom(),false);
	equal(list.isList(),true);
	equal(AjLisp.isAtom(list), false);
	equal(AjLisp.isList(list), true);
	equal(list.asString(), "(1.2)");
	equal(list.equals(list), true);
	var list2 = new AjLisp.List(1,2);
	equal(list.equals(list2), true);
	equal(list2.equals(list), true);
	var list3 = AjLisp.makeList(1,2,3);
	equal(list.equals(list3), false);
	equal(list3.equals(list), false);
	list = AjLisp.makeList(null, null);
	ok(list.first() === null);
	ok(list.rest().first() === null);
});

Temas pendientes: implementación de environment, evaluación de listas, formas y formas especiales, el parser, lambda, mlambda, flambda…. Me divieggto como loco! ;-) ;-)

Nos leemos!

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

Presentando Programación Funcional, AjLisp y Clojure

lopez — Fri, 05 Nov 2010 15:10:26 GMT

Ayer, Jueves 4 de Noviembre, tuve el placer de compartir una charla con @MartinSalias y @RodolfoF, sobre Programación Funcional. La dimos como una charla del nuevo emprendimiento de Martin:

http://www.codeandbeyond.org/

El lugar fue las instalaciones de @Southworks, donde tuvimos proyector, sillas, sonido, y catering (incluyendo cervezas!! ;-). El evento quedó grabado, así que esperamos que Martín lo publique.

Un resumen de lo que dieron Martín y Rodolfo: Martín presentó Programación Funcional en general, comentando sobre Cálculo Lambda, Lisp y la historia de los lenguajes de programación funcional, como ML, Caml, F# y otros. Luego me tocó mi turno, más abajo doy detalles. Tercer parte, de nuevo Martín mostrando F#, y finalmente, Rodolfo mostrando que C# desde el principio es funcional, y dando ejemplos de código procedural vs funcional.

No desesperen, entonces, que todo quedará disponible para verlo en línea.

Mientras, en este post, quería dejar enlaces y comentarios breves de mi intervención en la charla.

Primero, la primera parte presentación se basó en una que ya había dado para @southworks: LambdaPresentation.pptx.

La presentación de ayer en LispClojure.pptx (no es gran cosa, más que algunos enlaces, tiene varios slides en blanco, ver las notas, donde hay código de ejemplo).

Mostré código de cálculo lambda de mi proyecto AjLambda:

Presenting AjLambda: Lambda Calculus Implementation in C#
Presentando AjLambda: implementación de Cálculo Lambda en C#

Si quieren conocer sobre cálculo lambda, desde las matemáticas y lógica, dejé historia y enlaces que usé en

Notas sobre Cálculo Lambda

Trabajé unos minutos mostrando Lambdas en AjLisp. Posts sobre el proyecto AjLisp. Ahí van a encontrar otras implementaciones, como AjScheme, y un AjSharpure, (Work in Progress).

La parte de Clojure la basé en la más larga, detallada y excelente charla de @unclebob:

Uncle Bob Martin's "Clojure - Up Close and Personal"

Usé el ejemplo de multithreading en Clojure con transacciones en memoria:

https://github.com/sfraser/MultithreadedGameOfLife

Hace ya unos años, escribí sobre Recursos de F# y Programación Funcional.

Mis posts sobre F#
Mis posts sobre Programación Funcional

Mis enlaces:

http://delicious.com/ajlopez/functionalprogramming
http://delicious.com/ajlopez/lisp
http://delicious.com/ajlopez/f#
http://delicious.com/ajlopez/clojure
http://delicious.com/ajlopez/monads
http://delicious.com/ajlopez/lambda
http://delicious.com/ajlopez/scheme

Para los que les interesa Lisp, les recomiendo el libro y más:

Structure and Interpretation of Computer Programs
Video Lectures by Hal Abelson and Gerald Jay Sussman
Structure and Interpretation of Computer Programs adapted for the Clojure programming language
http://delicious.com/ajlopez/sicp

Algo más matemático, que mencioné al pasar:

http://delicious.com/ajlopez/categorytheory
http://www.delicious.com/ajlopez/grothendieck
Alexander Grothendieck
Nicolas Bourbaki

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

AjCoreLisp y MinimaLisp, un intérprete Lisp mínimo

lopez — Tue, 04 May 2010 09:47:46 GMT

Como mencioné en:

AjLisp family: Implementing Lisp Interpreters in C#

estuve trabajando en dos intérpretes Lisp: AjLisp y AjSharpure (un intérprete tipo Clojure). Pero quería explorar cuál es el núcleo del lenguaje, la mímima parte que debería ser implementada, para tener un intérprete Lisp.

Entonces, escribí AjCoreLisp. Pueden bajarlo del proyecto Google Code

http://code.google.com/p/ajlisp/source/browse/#svn/trunk/AjCoreLisp

Está implementado en C#. La solución:

tiene 5 proyectos:

AjCoreLisp: la librería de clases, núcleo del proyecto, implementando el lenguaje base, pero sin parser ni lexer, sólo en runtime de ejecución.

AjCoreLisp.Tests: como es costumbre, desarrollé la librería anterior usando Test-Driven Development. Este es el proyecto de tests de la librería.

MinimaLisp: Una prueba de concepto. Tiene lexer, parser, y una mínima máquina que define el ambiente inicial. Muestra el uso de la librería núcleo, construyendo un intérprete Lisp mínimo.

MiminaLisp.Console: el intérprete de consola interactivo.

MiminaLisp.Test: Tests TDD escritos para el desarrollo de MinimaLisp.

La interfaz raíz IExpression:

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

Todo Lisp tiene soporte de lista. Esta es la IList interfaz:

    public interface IList : IExpression
    {
        object First { get; }
        object Rest { get; }
        IList Next { get; }
    }

No actualización de los campos de la lista, es inmutable. Si queremos agregar que pueda cambiarse, hay que derivar de este proyecto, y poner la nueva implementación en un nuevo proyecto (como podría ser MinimaLisp u otro). Notar que tomado de Clojure la idea de tener Rest and Next: la primera retorna un objeto. Uso la segunda cuando espero que el resto de la lista sea una lista también.

Todo form (cabeza ejecutable de lista) implementa IForm:

    public interface IForm
    {
        object Apply(IEnvironment environment, IList arguments);
    }

Entonces, la clase Form implementa IForm y IExpression:

    public class Form : IForm, IExpression
    {
        private IList parameters;
        private IIdentifier parameter;
        private IList body;
        private IEnvironment environment;
        public Form(IList parameters, IList body, IEnvironment environment)
        {
            this.parameters = parameters;
            this.body = body;
            this.environment = environment;
        }
        public Form(IIdentifier parameter, IList body, IEnvironment environment)
        {
            this.parameter = parameter;
            this.body = body;
            this.environment = environment;
        }
// ....
        public object Evaluate(IEnvironment environment)
        {
            return this;
        }
        public virtual object Apply(IEnvironment environment, IList arguments)
        {
            IEnvironment newenv;
            
            if (this.parameter != null)
                newenv = this.MakeNewEnvironmentList(arguments);
            else
                newenv = this.MakeNewEnvironment(arguments);
            return Machine.EvaluateBody(this.body, newenv);
        }
// ....
    }

Noten que Form no evalúa sus argumentos. Este es el trabajo de la clase derivada Function:

    public class Function : Form, IExpression
    {
        public Function(IList parameters, IList body, IEnvironment environment)
            : base(parameters, body, environment)
        {
        }
        public Function(IIdentifier parameter, IList body, IEnvironment environment)
            : base(parameter, body, environment)
        {
        }
        public override object Apply(IEnvironment environment, IList arguments)
        {
            return base.Apply(environment, BaseForm.EvaluateList(arguments, environment));
        }
    }

Como es usual, macros tienen una “vuelta de tuerca”: evalúan su cuerpo, pero entonces, evalúan el valor retornado:

    public class Macro : Form, IExpression
    {
// ...
        public override object Apply(IEnvironment environment, IList arguments)
        {
            object value = base.Apply(environment, arguments);
            value = Machine.Resolve(value, environment);
            return Machine.Evaluate(value, environment);
        }
    }

(Machine.Resolve está relacionado con una implementación de Delayed Evaluation, que uso para conseguir una especie de Tail Recursion). Ok, bastante código fuente por ahora. Miren el código del proyecto para más detalles. El punto principal es que AjCoreLisp implementa pocas primitivas:

El enlace de primitivas al ambiente actual es el trabajo del MinimaLisp Machine:

        public MinimalMachine()
        {
            this.Environment.SetValue("first", new First());
            this.Environment.SetValue("rest", new Rest());
            this.Environment.SetValue("cons", new Cons());
            this.Environment.SetValue("quote", new Quote());
            this.Environment.SetValue("define", new Define());
            this.Environment.SetValue("lambda", new Lambda());
            this.Environment.SetValue("flambda", new FormLambda());
            this.Environment.SetValue("mlambda", new MacroLambda());
            this.Environment.SetValue("let", new Let());
            this.Environment.SetValue("letrec", new RecursiveLet());
            this.Environment.SetValue("eval", new Evaluate());
            this.Environment.SetValue("if", new If());
            this.Environment.SetValue("do", new Do());
            this.Environment.SetValue("nil?", new IsNil());
            this.Environment.SetValue("list?", new IsList());
            this.Environment.SetValue("equal?", new IsEqual());
        }

Basado ese conjunto de primitivas, pude escribir más funciones:

(define list x x)
(define definem 
  (mlambda x 
    (list 
      'define 
      (first x)
      (cons 'mlambda (rest x))
    )
  )
)
(define mapfirst (fn lst)
  (if (nil? lst)
    nil
    (cons 
      (fn (first lst)) 
      (mapfirst fn (rest lst))
    )
  )
)
    
(define mapcond (fn lst)
  (if (nil? lst)
    nil
    (if (fn (first lst))
      (cons 
        (first lst) 
        (mapcond fn (rest lst))
      )
      (mapcond fn (rest lst))
    )
  )
)
(define append (x y) (if (nil? x) y (cons (first x) (append (rest x) y))))
  
(definem cond lst
  (if (nil? lst)
    nil 
    (list 
      'if 
      (first (first lst)) 
      (cons 'do (rest (first lst))) 
      (cons 'cond (rest lst))
    )
  )
)
(define atom? (x)
  (cond 
    ((nil? x) t)
    ((list? x) nil)
    (t t)
  )
)
(definem and lst
  (if (nil? lst)
    t
    (list 
      'if 
      (first lst)
      (cons 'and (rest lst))
      nil
    )
  )
)
(definem or lst
  (if (nil? lst)
    nil
    (list 
      'if 
      (first lst)
      t
      (cons 'or (rest lst))
    )
  )
)
(define not (x)
  (if x
    nil
    t
  )
)
(definem backquote (lst) 
  (cond 
      ((nil? lst) nil)
        ((atom? lst) (list 'quote lst))
        ((equal? (first lst) 'unquote) (first (rest lst)))
        ((and (list? (first lst)) (equal? (first (first lst)) 'unquote-slice)) (list 'append (first (rest (first lst))) (list 'backquote (rest lst))))
        (t (list 'cons (list 'backquote (first lst)) (list 'backquote (rest lst))))
  )
)
(definem while lst
  (list 'if (list 'not (first lst)) nil (cons 'do (rest lst)) (cons 'while lst))
)

Me gusta mi implementación de backquote (para usar en expansión de macros), un mini “tour-de-force” de este lenguaje. Estos tests dan verde (notar el uso de unquote y unquote-slice):

this.EvaluateAndCompare("(backquote (a b c))", "(a b c)");
this.EvaluateAndCompare("(backquote (a (b c) d))", "(a (b c) d)");
this.Evaluate("(define x '(b b))");
this.EvaluateAndCompare("(backquote (a (unquote x) c))", "(a (b b) c)");
this.EvaluateAndCompare("(backquote (a ((unquote x)) c))", "(a ((b b)) c)");
this.EvaluateAndCompare("(backquote (a (unquote-slice x) c))", "(a b b c)");
this.EvaluateAndCompare("(backquote (a ((unquote-slice x)) c))", "(a (b b) c)");
this.EvaluateAndCompare("(backquote (a (unquote-slice x) (unquote-slice x) c))", "(a b b b b c)");

No hay soporte de números. Escribí algunos tests usando implementaciones tipo Peano:

(define succ (x)
  (cons x nil))
  
(define pred (x)
  (first x))
(define add (x y)
  (if (nil? x)
    y
    (add (pred x) (succ y))
  )
)

Hace un rato que no toco y mejoro el código, pero mi próximo paso podría ser refactorizar AjLisp (intérprete más completo) para basarse o tomar ideas de este intérprete núcleo. Ahora, tengo una idea más clara de lo que es necesario, esencial, y de lo que es accesorio en un intérprete Lisp.

Y me divertí escribiendo esto ":-)

Nos leemos!

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

Refactoreando AjLisp: un intérprete Lisp escrito en C#

lopez — Sun, 10 Jan 2010 11:50:51 GMT

En estos días estuve reimplementando el núcleo de mi intérprete Lisp de código abierto AjLisp. Había escrito sobre la anterior versión en el 2008:

AjLisp: a Lisp interpreter in .NET
AjLisp: un intérprete Lisp en .NET

Es trabajo en progreso. Pueden bajar el código de:

http://code.google.com/p/ajlisp/source/browse/#svn/trunk/AjLisp

(hay otras dos implementaciones en ese repositorio, en desarrollo: AjScheme, un Lisp tipo Scheme, y AjSharpure, que intenta seguir las ideas de Clojure). Debería escribir sobre esas implementaciones. Este post es el inicial en una serie sobre AjLisp. Es una corta introducción al estado actual del proyecto.

El principal cambio en esta nueva versión: el intérprete puede manejar objetos y valores nativos. La alternativa hubiera sido apuntar a esos objetos a través de “wrappers”, alguna clase que implemente SymbolicExpression o similar. Pero elegí manejar directamente objetos nativos. Para eso, cambié las primitivas y clases relacionadas para que recibieran como argumentos objetos en vez de IExpression. Sigue habiendo una interfaz IExpression, defined como:

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

El ValueEnvironment (planeo cambiarle el nombre a BindingEnvironment, y derivarlo de alguna interfaz tipo IBindingEnvironment) mantiene una asociación anidada de nombres y valores:

Hay un interfaz IFunction:

    public interface IFunction
    {
        object Apply(List arguments, ValueEnvironment environment);
    }

que debería ser implementada por cualquier form expression (la cabeza de una lista a evaluar).

Las dos clases principales que representan los tipos núcleo del AjLisp son identificadores y listas:

Todo el proyecto fue armado siguiendo Test-Driven Development, así que no tuve problemas en cambiar la versión anterior: tenía toda una batería de tests que me ayudó en el proceso de refactoring. Este es el estado actual de los test:

Debería escribir sobre:

- La implementación de ValueEnvironment
- Manejo de objetos nativos
- El tipo List y su evaluación
- Evaluación de Identifier
- Las primitivas implementadas
- El Lexer y el Parser
- Operaciones numéricas
- Números racionales (AjLisp puede manejar pares enteros numerador/denominador)

Ahora, luego de lo que aprendí desarrollando estos proyectos (AjLisp, AjScheme, AjSharpure), estoy escribiendo un núcleo mínimo AjCoreLisp, para mostrar cuáles son las primitivas mínimas para crear un intérprete Lisp. Armado con esa implementación, me gustaría explorar alternativas de compilación, en vez de ser sólo intérprete. Mi primer candidato es Dynamic Language Runtime. Otro podría ser la producción de código C# directo. Sería demasiado encarar esa exploración sobre un intérprete “más grande”. Primero, entonces, estudiaré sobre compilar un intérprete con menos primitivas, más condensado.

Nos leemos!

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

La familia AjLisp: implementado intérpretes Lisp en C#

lopez — Tue, 05 Jan 2010 10:15:27 GMT

En los últimos meses, estuve activo escribiendo intérpretes Lisp. Desde los ochenta, me gusta escribir ese tipo de intérpretes. Uno de mis ejercicios preferidos cuando estudio un nuevo lenguaje de programación, es escribir un intérprete Lisp en ese lenguaje (otro ejercicio es escribir un intérprete del lenguaje en estudio).

En el 2008, publiqué un código escrito en C#, AjLisp:

AjLisp: a Lisp interpreter in .NET
AjLisp: un intérprete Lisp en .NET

A la mitad del 2009, comencé a investigar Clojure. Dedicí explorar las nuevas ideas de ese lenguaje, reinplementánlo en C# (el Clojure original está escrito en Java, pero hay una versión en .NET, que compila usando DLR, Dynamic Language Runtime). Clojure compila a bytecodes Java. Mi versión es sólo un intérprete (debería estudiar y aprender sobre DLR o compilación .NET, y sobre cómo pasar el árbol de mi intérprete a código compilado). El resultado de todo esto es “work in progress”, se llama AjSharpure (se llamaba AjClojure, pero tuve que cambiar el nombre). Pueden ver el código, en desarrollo, en:

http://code.google.com/p/ajlisp/source/browse/#svn/trunk/AjSharpure

Inicialmente, mi idea era portar “uno a uno” el código de Java del Clojure original, pero me dí cuenta al tiempo que su código base no es fácilmente leíble, no tiene test en código, ninguna especificación acerca de la conducta esperada de docenas de clases y centeneares de métodos. Así que paré el desarrollo, y repensé el camino a seguir. Tomé coraje, olvidé el código inicial, y comencé de nuevo, de abajo hacia arriba, usando a fondo Test-Driven Development (TDD), implementando pieza por pieza, para ir consiguiendo parte por parte la conducta esperada externa del lenguaje, en vez de seguir de cerca su implementación interna.

Ahora está algo tranquilo el desarrollo de AjSharpure, porque estoy estudiando formas de implementar lo que me falta, como variables, Shared Transactional Memory, y otros temas, como References. Mientras, volví a mi versión 2008 de AjLisp. Escribí una nueva versión en 2009, haciendo un refactoring importante, armado de lo que había aprendido con AjSharpure. Ahora, tiene acceso y manejo de objetos y valores nativos. El trunk está en:

http://code.google.com/p/ajlisp/source/browse/#svn/trunk/AjLisp

No hay un Lisp “base”, y hay DOS principales dialectos: Common Lisp y Scheme. No me gustan algunas cosas de Common Lisp (debería escribir un post sobre mi razones), así, que para conocer más sobre Clojure y otros Lisp actuales, comencé a escribir AjScheme, un intérprete que implementa mucho de lo que es la referencia de Scheme (renuncié a implementar definición de macros como en el Scheme original, uso mis más conocidas mlambdas y expansión de macros):

http://code.google.com/p/ajlisp/source/browse/#svn/trunk/AjScheme

El AjLisp nació siguiendo un viejo libro de Christian Queinnec (un libro de los ochenta, no uno de sus más nuevos). No pude encontrar el código del libro en la web. Queinnec incluía en el texto el código de un intérprete Lisp escrito en su propio Lisp. No tengo el libro acá (lo tengo en mi segundo cubil). Me puse a investigar sobre lo mínimo que necesita ser implementado en un Lisp básico. Así que estos días estoy trabajando en el AjCoreLisp:

http://code.google.com/p/ajlisp/source/browse/#svn/trunk/AjCoreLisp

No tiene parser ni lexer. La idea es implementar un intérprete mínimo usando AjCoreLisp como la base: el resultado es MinimaLisp, y está incluido en ese trunk. Estoy implementando las mínimas primitvas, y estoy tratando de escribir el resto de las forms más comunes como funciones o macros. Una decisión “geek” ;-) : implementar la expasión de macros con backspace escribiéndola como una macro! El resultado en:

http://pastie.org/765371

Una vez que tenga AjCoreLisp/MinimaLisp estabilizado, haré refactor de AjLisp, AjScheme, para usar el kernel más pulido, pero agregaré como primitivas las forms más usadas. Debería medir el impacto de implementar forms más usadas como macros, en lugar de primitivas. Tengo confianza en poder hacer todos esos cambios, porque todo lo escrito está vigilado por una batería de tests (el haber seguido TDD y tener tests me ha salvado el día muchas veces, cuando he refactorizado mucho del código base).

Como próxima misión: escribir posts sobre estos diferentes intérpretes, variaciones sobre un leit-motiv: las hermosas ideas del lenguaje Lisp.

Para los que quieran estudiar más sobre Lisp, mis enlaces sobre el tema:

http://delicious.com/ajlopez/lisp
http://delicious.com/ajlopez/scheme
http://delicious.com/ajlopez/clojure
http://delicious.com/ajlopez/commonlisp

Nos leemos!

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

Lord of the REPLs (Read Eval Print Loops) y CodePad

lopez — Wed, 16 Sep 2009 09:34:07 GMT

En estos días, estuve trabajando escribiendo lenguajes interpretados. Mi primer interés es Clojure, estoy trabajando en una implementación de las ideas de Clojure en C#, escribiendo desde 0, pueden ver lo que estoy haciendo en:

http://code.google.com/p/ajlisp/source/browse#svn/trunk/AjSharpure

El año pasado escribí un intérprete Lisp AjLisp- a Lisp interpreter in .NET, AjLisp – un intérprete Lisp en .NET, que quiero mejorar, pero en las últimas semanas me dediqué más a escribir un intérprete tipo Scheme:

http://code.google.com/p/ajlisp/source/browse#svn/trunk/AjScheme

Con tanta actividad con lenguajes “lispy”, investigué sobre otras implementaciones. Mis descubrimientos fueron agregados, como es usual, a mi delicious:

http://delicious.com/ajlopez/lisp
http://delicious.com/ajlopez/clojure
http://delicious.com/ajlopez/scheme

Una de las joyitas que encontré, es esta Google App Engine:

http://code.google.com/p/lotrepls/

LotREPLs is a multi-lingual read-eval-print-loop in your browser powered by Google App Engine and the Java runtime. It's a technical demo, not something to do serious work with. The following languages are supported:

BeanShell

Clojure

JavaScript

Python

Ruby

Scala

Scheme

Pueden probara en línea en:

http://lotrepls.appspot.com/

Podemos ingresar un comando, y ver el resultado de la evaluación, sin instalar nada en la máquina local.

Otra aplicación similar, que soporta C, C++, D, Haskell, Lua, Ocaml, PHP, Perl, Python, Ruby, Scheme, Tcl, es:

http://codepad.org/

codepad.org is an online compiler/interpreter, and a simple collaboration tool.
Paste your code below, and codepad will run it and give you a short URL you can use to share it in chat or email.

Podemos ingresa el código, y se puede referenciarse por URL, para compartir con otros desarrolladores:

Si seguimos así, un día, todas nuestras herramientas estarán en el browser… :-)

Nos leemos!

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

Popularidad de Lenguajes de Programación

lopez — Wed, 08 Jul 2009 09:50:06 GMT

Me temo que AjLisp y AjBasic lo usamos yo y nadie más… snif… :-). Pero hay lenguajes más populares que esos. Ya es clásica la lista de TIOBE Software:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

donde aparece Java como el lenguaje más popular, lo que no me asombra. Pero sí me llama la atención la popularidad de C y C++, que deben tener su gran uso en el ambiente Unix, Linux, y otros. Como cuarto, encuentro hoy, Julio de 2009, a PHP, que lo entiendo: la mayor parte del código de sitios dinámicos está en PHP, lejos quedaron los años del predominio del venerable Perl. Y recién en sexto y séptimo lugar, está Visual Basic (parece que agrupan el de .NET y el clásico), y C#. Vean que al final de la lista, aparecen lenguajes con mínimos porcentajes, pero aparecen: RPG, Pascal, Abap, Lisp/Scheme. Más abajo, en la misma página encontraran la lista de posición 21 a 50, donde aparecen COBOL, Objective-C, Fortran, Logo, Prolog, Ada (todavía anda por ahí? :-), Scala, Erlang…. y esta es la lista de 51 a 100:

ABC, AD, Algol, Alpha, Applescript, Beta, Boo, C shell, cg, Clean, Cobra, cT, Curl, Dylan, Eiffel, Euphoria, Factor, Fan, Icon, IDL, Inform, Io, Lingo, MAD, Magic, Maple, Mathematica, MAX/MSP, MOO, MUMPS, Natural, Oberon, Occam, Oz, PL/I, Postscript, PowerBuilder, Progress, Q, R, Revolution, REXX, S-lang, SIGNAL, SPSS, SuperCollider, VBScript, Verilog, VHDL, XSLT

Notable lista, recomendaría tantos lenguajes de esa lista, simplemente para aprender nuevas formas de programar (notable que aparezca todavía MUMPS, REXX, tendría que ver con más detalle a Io). Esta lista de popularidad se basa en el examen de búsquedas en Google, hace un tiempo pasaron a agregar MSN y Yahoo.

Pero en estos días, encontré otra página:

http://langpop.com/

con información de ranking de popularidad, pero con agrupadas con distintas fuentes, como Yahoo Search, search en Google Code, Freshmeat, Craiglist, Amazon.

En lo que veo hoy ahí, julio de 2009, según Yahoo Search C es más popular que Java. Pero para Craiglist, primero PHP, segundo SQL (!!!), en Amazon ganan C, C++ y C#, por encima de Java. Y así, noto dispersión de los resultados, dependiendo de la fuente.

La popularidad de un lenguaje importa. No tanto para entender el lenguaje (muchos lenguajes “boutique” tienen interesantes conceptos, a estudiar con detalle), sino para tener una idea de qué tecnología ha sido adoptada por la comunidad, pero habría que ver más allá: por qué la eligieron, y en qué tipo de proyectos. Dudo que haya muchas aplicaciones desktop, en PHP.

Resumen: gran cantidad de lenguajes, hay lenguajes viejos, desde COBOL y Smalltalk, y más “nuevos” como Boo, Ruby, Python. Y `cuatros grandes grupos: Java, C/C++, lenguajes .NET (VB.NET, C#), PHP, como claros grupos líderes.

Pienso que, como desarrolladores de software, debemos tener contacto con esos cuatro grupos, y además, con alguno de los “otros”, para aprender otras ideas y formas de programar.

No me enojo si intentan ver AjLisp o AjBasic… :-)

Nos leemos!

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

AjLisp: un intérprete Lisp en .NET

lopez — Thu, 31 Jul 2008 13:30:41 GMT

Soy un entusiasta de escribir intérpretes, especialmente del tipo Lisp. Mi primer intérprete Lisp fue escrito al principio de los 80, usando el lenguaje assembler de un Intel 808x. Era un trabajo muy "geek". Una de las características más "tricky" de implementar es un recolector de basura (garbage collector). Por suerte, desde mediados de los 90 tenemos Java y su librería de clases como una tecnología ampliamente disponible con un garbage collector decente. En este siglo, .NET es la nueva plataforma de lenguajes con GC..

En el 2005, Martin Salias y yo dimos un TechNight, aquí en Buenos Aires, Argentina, para la oficina local de Microsoft. Trató sobre lenguajes implementados en .NET. Fue la primera vez que presenté F#, así como P# y otros. Despues de esa charla, la misma noche viajé a Mar del Plata, para dar otra charla sobre ASP.NET. Mar del Plata es una bella ciudad, en frente del océano Atlántico, a la que trato de volver cada año. Entonces, era mi primer visita luego de treinta años. En el viaje, "nació" AjLisp.

Esa versión era un intérprete Lisp escrito en Visual Basic .NET. El pasado domingo, lo porté a C# (usando alguna opción de menú de SharpDevelop, ¿alguna otra herramienta que conozcan?). El código original fue usado hace unas semanas en mi post sobre VPL:

Lisp-like interpreter using DSS and VPL
Intérprete tipo Lisp usando DSS y VPL

La nueva versión C# version está publicada en Google Code en:

http://code.google.com/p/ajlisp/

Me gusta Google Code: tiene soporte de SVN, asi que uso mi cliente local TortoiseSVN para enviar los cambios en el proyecto.

La solución

Tiene tres proyectos:

AjLisp: el proyecto núcleo, una librería, que puede ser invocada desde otra aplicación.

AjLisp.Tests: Todos los tests, usando NUnit 2.2.8. Si no tienen NUnit, pueden remover el proyecto de la solución.

AjLisp.Console: un simple programa de consola.

Los tipos

Una interfaz base es IAtom:

    public interface IAtom
    {
        bool IsAtom();
    }

Otra es IList:

    public interface IList
    {
        SymbolicExpression First
        {
            get;
            set;
        }

        SymbolicExpression Rest
        {
            get;
            set;
        }

        bool IsList();
    }

Todos los tipos derivan de una SymbolicExpression:

namespace AjLisp.Types
{
    public abstract class SymbolicExpression : IList, IAtom
    {
 ....

Implementé los tipos comunes a usar en un Lisp, como List, Atom, Identifier, Function (para invocar a primitivas y funciones generadas por lambdas), True, Nil...:

Existe una clase Environment para mantener valores asociados a nombres. Cada Environment tiene un Environment padre, para mantener una lista de ambientes con valores.

La clase Interpreter es la principal a manejar: tiene un Environment y define algunos nombres para las primitivas iniciales:

    public class Interpreter
    {
        private Environment environment = new Environment();

        public Interpreter()
        {
            Define("nil", Nil.Value);
            Define("t", True.Value);
            Define("cons", new SubrCons());
            Define("first", new SubrFirst());
            Define("car", new SubrFirst());
            Define("rest", new SubrRest());
            Define("cdr", new SubrRest());
            Define("list", new SubrList());
            Define("quote", new FSubrQuote());
            Define("append", new SubrAppend());
            Define("cond", new FSubrCond());
            Define("atom", new SubrAtom());
            Define("eval", new SubrEval());
            Define("null", new SubrNull());
            Define("lambda", new FSubrLambda());
            Define("progn", new FSubrProgN());
            Define("flambda", new FSubrFLambda());
            Define("nlambda", new FSubrNLambda());
            Define("mlambda", new FSubrMLambda());
            Define("numberp", new SubrNumberP());
            Define("functionp", new SubrFunctionP());
            Define("idp", new SubrIdP());
            Define("define", new FSubrDefine());
            Define("definef", new FSubrDefineF());
            Define("definen", new FSubrDefineN());
            Define("definem", new FSubrDefineM());
            Define("eq", new SubrEq());
            Define("if", new FSubrIf());
            Define("let", new FSubrLet());
            Define("lets", new FSubrLetS());
            Define("set", new SubrSet());
            Define("consp", new SubrConsP());
            Define("less", new SubrLess());
            Define("greater", new SubrGreater());
            Define("plus", new SubrPlus());
            Define("difference", new SubrDifference());
            Define("times", new SubrTimes());
            Define("quotient", new SubrQuotient());
            Define("remainder", new SubrRemainder());
        }

....

Uds. pueden escribir sus propias primitivas y agregarlas a este constructor.

Las primitivas

El intérprete tiene las primitivas usuales:

Hay primitivas, que antes de su invocación, evalúan los argumentos recibidos. Son las que derivan de Subr:

    public abstract class Subr : Function
    {
        public abstract SymbolicExpression Execute(SymbolicExpression args, Environment env);

        public override SymbolicExpression Apply(SymbolicExpression form, Environment env)
        {
            return Execute(form.Rest.Evaluate(env), env);
        }
    }

form.First es la función, y form.Rest es la lista de argumentos. Para evaluar el form, Function usa un objeto Environment.

Otras primitivas no evalúan sus argumentos, derivan de FSubr:

    public abstract class FSubr : Function
    {
        public abstract SymbolicExpression Execute(SymbolicExpression args, Environment env);

        public override SymbolicExpression Apply(SymbolicExpression form, Environment env)
        {
            return Execute(form.Rest, env);
        }
    }

Una de las primitivas más interesantes, es la implementación de lambda, llamada FSubrLambda:

    public class FSubrLambda : FSubr
    {
        public override SymbolicExpression Execute(SymbolicExpression args, Environment env)
        {
            return new SubrClosure(args.First, env, args.Rest);
        }
    }

Crea un Closure, una manera de recordar el Environment actual para usarlo en una futura invocación de la expresión lambda. Implementé también NLambda, FLambda, MLambda: N es por NonSpread (maneja su lista de argumentos como si fuera un solo argumento), F es cuando no son evaluados los argumentos antes de la invocación, y M es por Macro (tengo que revisar hasta donde implementé esta "feature").

Los tests

Toda la funcionaliad está cubierta por tests. Configuré el proyecto AjLisp.Test para ejecuter NUnit GUI:

La consola

AjLisp.Console es un simple programa de consola. Pueden ingresar una expresión y la evalúa:

Es tan simple, que hay que usar Control-C para salir... ;-).

Próximos pasos

Hay tanto para hacer. Quiero mejorar algunos puntos:

Reescribir interfaces y clases de base
Manejar e invocar objetos .NET nativos
Tratar a Reales y Enteros por separado (hoy a ambos, al operar, los trata como valores double)
Revisar Macro expansion
Mejor consola
Librería de ejemplos
Un manual mínimo

La idea es llegar a extender este mini lenguaje para ser usado como la base programación de agentes distribuidos. Sería bueno portarlo a Java. Entonces, la conducta de los agentes y su estado puede ser escrito en este lenguaje, y viajar a distintos nodos de la grilla, de forma independiente a la plataforma.

Bueno, son sueños. Ahora, el estado actual: está funcionando, y me divertí escribiéndolo. Disfruten!

(Este artículo es una traducción a Spanish, desde el Anglish (Angel's English) original:
AjLisp- a Lisp interpreter in .NET

)

Angel "Java" Lopez
http://www.ajlopez.com/en

Intérprete tipo Lisp usando DSS y VPL

lopez — Wed, 11 Jun 2008 14:22:24 GMT

Este fin de semana estuve programando algunas primitivas de un intérprete Lisp usando DSS Service Compoenntes. El núcleo del intérprete fue derivado de mi trabajo previo con AjLisp, un intérprete que todavía no publiqué. Escribí el ejemplo usando Visual Studio 2008 con el CTP v2.0 de Microsoft Robotics Developer Studio. El ejemplo está publicado en mi Skydrive como DssLisp.zip.

La solución

Consiste de dos proyectos: una librería de clases llamada AjLisp (una versión revisada de mi intérprete original en VB.NET):

y un proyecto C# de Dss Service, que tiene varios service components implementados:

No tiene manifiesto inicial. El proyecto está pensado para ser usado desde diagramas de Visual Programming Language (VPL).

Varios de estos componentes reciben y retornan una SymbolicExpression, el tipo base de mi intérprete. Veamos por ejemplo, los mensajes del componente Rest, que dada una lista devuelve la misma lista sin el primer elemento:

    [DataContract()]
    public class ExecuteRequest
    {
        [DataMember]
        public SymbolicExpression Expression;
    }

    [DataContract]
    public class ExecuteResponse
    {
        [DataMember]
        public SymbolicExpression Result;
    }

Para compilar estos componentes, deben ajustar las referencias y directorios del proyecto DSS (ahora apuntan a mis directorios locales y a mi instalación local de Microsoft Robotics Developer Studio).

Usando VPL

Hay tres programas VPL incluidso en los ejemplos. Usan los componentes compilados de la solución. Tuve un problema con estos programas VPL. No pude ejecutarlos desde la opción de Run. Hay que usar Build -> Compile as a Service, y ahora, lanzarlos con Run -> Run Compiled Services. Creo que el origen del problema es que al armar el diagrama estoy mapeando mensajes propios, no solamente tipos primitivos o Strings. Para recompilar los diagramas, tienen que ajustar las propiedades en cada proyecto VPL:

El primero, DssLispVpl1, calcula (first '(a b c)):

Hay dos componentes LispParser y LispToString, que ayudan a convertir de string a SymbolicExpression y viceversa.

El segundo diagrama es DssLispVpl2:

Usa el componente LispAppend para concatenar dos listas predefinidas como Data.

El tercero es un min intérprete DsspLispInterpreter:

Tengo que mejorar el tratamiento de errores. Ahora, si ocurre una excepción, no devuelve un Fault, y encontes se genera una causality, que hace que el programa se interrumpa.

Podría implementar contratos genéricos, y reusarlos en los componentes, por ejemplo, un contrato GenericBinaryOperation.

Problemas

Fallé completamente cuando quise escribir una Activity, para implementar una función Reverse de una lista. La actividad se llamaba a sí misma recursivamente, pero en el código generador retornaba desde la última invocación recursiva, sin pasar por las intermedias. El problema es causado porque en todo ese proceso se utiliza la misma instancia de actividad, y al retornar por una puerta el resultado, TODOS los procesos pendientes de esa actividad están escuchando por esa puerta (eso es lo que veo que pasa). Otra piedra en el camino es que las actividades solo aceptan valores primitivos o string como datos en el mensaje de entrada. Puedo solucionar el problema, generando el código de la actividad, levantando la solución, y cambiando los parámetros que trata de, digamos, string a SymbolicExpression.

Un componente interesante, es el componente Uncons, que retorna DOS expresiones simbólicas en su mensaje de respuesta: dada una lista, retorna su cabeza y su cola. Esos dos miembros de la respuesta pueden ser procesados luego en paralelo en dos ramas del diagrama.

Conclusiones

Como en otros posts y ejemplos, encontré la orquestación de componentes DSS via VPL como algo poderoso e interesante, pero le faltan algunas cosas, como el soporte de un objeto genérico o tipos nuestros. Creo que se puede implementar varias primitivas de lenguajes funcionales y usar a VPL para programar sobre ellas. VPL tendría problemas con la recursividad (o no encontré una forma aceptable de hacerla funcionar). Este ejercicio, podría expandirse a otras ideas:

- Manejar una pipeline/tubería para procesar un mensaje genérico (puedo usar un object como DataMember en un mensaje, siempre y cuando no lo envía a otro Host de DSS)
- Tener balanceo de carga
- Serializar/deserializar objetos entre hosts
- Implementar algún workflow o patrones de integración de aplicaciones usando VPL

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com