To do:
- We should do garbage collection in tam_env_free !!
- you could use zero as a return value for error. Right now it's slow because
we're returning nil.
- Don't use static arrays for error reporting. Don't be lazy and use malloc and free. It's damn-slow.
- Allow the user to load modules at runtime.
- TAMObjectPrint should receive an stream (FILE *). See tam_object.h
- We are only parsing files. We have to parse strings.
- Make the lexer thread safe. Put global variables in a structure. And find out how to to this with Bison.
- The input buffer might grow a lot. Shrink it once in a while if needed.
- The used can define special symbols ("if", "define"...) but the behavior of the interpreter does not change.
- there's a TODO comment in tam_garbage.c

To keep in mind:

- objects of type procedure are not responsible for the data of the primitive procedures. The idea behind modules is that you can start doing this yourself, perhaps using a private evaluation environment with garbage collection. The user can use this data to store anyting, for example, a mutex for threads.
- If we decide to implement threads, we'll have to put exclusions in the static data shared by all the modules (tam_module.h, tam_objects.h)
- we should allow the user to override behaviors on run time (prompt, wheter to print befor evaluation, ...)
- both tam_object_used_unset and tam_object_used_set have optimizations
- should we add set!? I think we should...
- the object stack was not weel designed. There shouldn't been a type there. Isn't it nicer to use separate stacks for objects and types?

Maybe:

- now that we have "bootstrapped" we could define everyting as symbols, and
  the user will be able to overload them, just like in guile. But umb-scheme
  does not allow this. UPDATE : Well, I just noticed why lambda has to be a
  special form...
- should we support both integers and reals? Would'n it be nice to use separate stacks for objects and types?
