I've already mentioned that for example, I want modules in a lazy-by-default Language. You can't really get that only with macros, you need more (source processing like a compiler, and possibly make some info public that's more than just identifyers). There are already people out there playing with type systems, and it's something that I'm interested in looking into after the lazyness thing; it's also something that one should be able to fit into Snow in the long term.
I agree. (as a side note, is there any code released for those type systems? I'd be very interested.) Even besides lazy code or type systems, modules have a direct impact on evaluation. For example, the following simple scenario doesn't work with gambit:
-- test.scm
(namespace ("foo#")) (##include "~~/lib/gambit#.scm")
(define a 5)
(namespace ("bar#")) (##include "~~/lib/gambit#.scm") (namespace ("foo#" a))
(eval '(display a))
--
0 james@james% gsc
[17:39] Gambit v4.1.2
(compile-file "test.scm")
#t
(load "test")
*** ERROR -- Unbound variable: a 1> ,q
It's obvious why it doesn't work - namespaces are compile time environments. I'm far from being an expert on how to fix this, and how much overhead it would occur (it doesn't seem like much, eval simply needs to respect environments for starters, which could use name mangling for fast lookup). And I respect Snow's decision to use macros, as it's much easier to make it portable. But you can't get real modules without a proper evaluator, and there's the kludge - evaluators are implementation specific.
My first things I want to tackle is lazyness and module parametrization in chjmodule; for this I want to publish a versioning repository of chjmodule real soon now™, and then go on tackling the parametrization and lazyness issues. After having succeeded at those (or while I'm (or while we are, if anybody is taking part) at them) I want to see how to integrate them with Snow.
So I think Snow is right in starting simple. It can get better with time, slowly integrating the good bits being around when people see how they fit together well.
I don't see how you could possibly integrate something like lazyness with Snow. It's completely based on macro expansion.
I suppose I'm a little worried about backwards compatibility. I'd really like Snow to use a separate config language for modules like Scheme48. I like writing my code in whatever structure I want, and then writing the interfaces in one file, the packages in another (which tie everything together, hook interfaces with groups of files), and the build instructions in a third (that's only with gambit of course).
I'm not claiming to be an expert at all (or even any) of those areas. But I'm hoping to get expertise by working through them.
I'm not claiming to be an expert either! I hope to study these issues further. I also don't mean to sound negative - Snow is a noble accomplishment, and I hope to see it improved over time!
So I've got an own humble question: could you refer me to some documentation / a paper on what you mean with "reflective tower"? Is one of the following links a good start?:
http://www.daimi.au.dk/~danvy/Papers/danvy-malmkjaer-LFP88.pdf http://portal.acm.org/citation.cfm?id=319871&coll=Portal
Unfortunately I don't have an ACM account right now. The first paper is a bit over my head, but that sounds like a very generalized version of what I was referring to (honestly, I don't know much about them besides the general description I'm about to give). You could look at Scheme48's snippet on the towers which give a little more practical description of their usage:
http://s48.org/1.7/manual/manual-Z-H-5.html#node_sec_4.9
A better term is a 'syntactic tower', and it's like a stack of evaluation environments, and are usually used to manage environments for macros. Modules should be able to import other packages for the next level in the tower (or "macro time"), and export symbols for the next level.