[gambit-list] AWS, Termite, and Snow

James Long longster at gmail.com
Sat Feb 2 18:35:28 EST 2008


> 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 at 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.

-- 
James Long
Coptix, Inc.
longster at gmail.com



More information about the Gambit-list mailing list