Lambada

zOMFG!!! We were caught on video!!!

2008-08-12T12:12:00.001-05:00

XD

He aquí el video de Lambada Web Dev. Enjoy!

Dijkstra would not have liked this

2008-05-15T00:26:00.004-05:00

¡Por fin! El proyecto terminado.
Descárgalo de http://lambada.googlecode.com/files/lambada.zip o baja el cliente de svn y obtén una copia fresquesita escribiendo la siguiente línea en una terminal

svn checkout http://lambada.googlecode.com/svn/trunk/ lambada-read-only

The Pirates of CCI Valley

2008-05-12T23:16:00.004-05:00

Estuvimos trabajando en la edición del video (Julio principalmente) (6 horas)
Afinamos los Test Cases (media hora)
Intentamos correr en windows nuestra aplicación (4 horas)

Los problemas que tuvimos fueron en el último punto.
Las librerías de Haskell así como el método de instalarlas no son lo suficientemente estables. Después de mucho buscar e intentar por medio de distintos métodos (instalación manual, cabal, cabal-install, make (Cygwin)) decidimos pedirle ayuda al compañero extranjero, Tero, para realizar la instalación de nuestro framework.

Merengueando

2008-04-10T22:21:00.004-05:00

10 hours of work O_o
- Waltz server created
- Merengue interpreter created (<spill> and <serve> tags defined)
- Sample code generated (Fizz-Buzz and Primes Generator)

Our main problem was that we didn't send the headers correctly: we forgot to append the "\n\n" at the end of the header. We took a lot of time to catch the bug.

Haskell knows best

2008-04-01T19:18:00.001-06:00

Check this out, and remember to keep your hands clean.

14 horas de trabajo a lo largo de una semana

2008-03-27T13:12:00.004-06:00

- Cambios a eval, parser y lexer
- Interfaz para correr archivos
- Cambios a pruebas de unidad
- Implementación de interfaz para uso de funciones primitivas
- Implementación de 20 funciones
Total 14 horas de trabajo

Los problemas encontrados en este parte fueron que al parsear un archivo, no habíamos tomado en cuenta la existencia de la mónada "eof" en Parsec.
Los archivos fuente de salsa se parseaban incompletos y no el parser se forzaba (¿por la lazy evaluation tal vez?) a leer todo el archivo. El código quedó así:


parseExps :: GenParser Char () [Exp]
parseExps = do xs <- many1 parseExp
               skipMany space
               eof
               return xs

SALSA! may not be Happy

2008-03-05T15:26:00.009-06:00

I've noticed something interesting about the way we are using Happy to generate the parser of our language salsa, it does make a difference between parse and evaluation time.
This is the definition of the top-level function of our interpreter so far:

rep = print . showExp . extractValue . eval . (!! 0) . parse

Why is this important? Well, if salsa was a run-of-the-mill language, then there would be no problem: the compilers and interpreters of almost all the languages work that way (AFAIK).
But SALSA! is not a run-of-the-mill language, it is a lisp-like language. Lisp-like languages make no distinction between read-, compile-, or run-time. That's one of the things that made Lisp what it is.

The way Lisp implementations "interrupts" parsing is by means of the quoting functions: quote (') and quasiquote (`). When there's a quote character leading an expression, the parser just reads the expression and there's no evaluation. This is one of the first steps to do a Lisp macro.

The main problem in our interpreter arises when you quote a reserved word: if, define, let, etc... The parser reads the expression but still tries to parse it, so when you quote, lets say the symbol if, you get a "Parser Error", because the rule for if is not satisfied.
The later doesn't happen in any Scheme or Lisp interpreter. If this isn't corrected, macros that modify an existing special form won't be possible (or at least Common Lisp macros won't, I still don't know how hygienic Scheme macros work).

--------------------------------------------------------------
UPDATE
--------------------------------------------------------------

I've been trying the Parsec Monad and reading carefully this Haskell tutorial and now I think I know why the salsa interpreter had the problem above. I think (I haven't verified in any implementation yet) that the parsers for lisp-like languages just parse atoms and lists, only. Some of them provide syntactic sugar for quoting operations, but I think that's all they do. The evaluator is the program that "gives meaning" to the information stored inside the lists. That is, if the expression presented to the evaluator matches some special form, it is treated the way it should be.
In the case of our past parser, when presented with "a token" of a special form, it tried to parse the expression as such, and failed when the specific special form was not satisfied. This is no longer true, the only terminals we have are now this:

".()'

any other string is treated as a symbol, an integer or the contents of a string. No more, no less. The evaluator is now the one who gives meaning to the special forms.

Blog, sweet blog

2008-02-20T16:21:00.003-06:00

Hello, we have moved from our old wiki to Google Code and to blogger.
This will be the place where we'll be posting our activity log from now on.