[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIT-Scheme-devel] Module system?
From: |
Taylor R Campbell |
Subject: |
Re: [MIT-Scheme-devel] Module system? |
Date: |
Mon, 31 Aug 2009 00:03:44 -0400 |
User-agent: |
IMAIL/1.21; Edwin/3.116; MIT-Scheme/7.7.90.+ |
Date: Sun, 30 Aug 2009 18:16:38 -0700
From: address@hidden (Matt Birkholz)
You did not follow the common practice of providing an initialization
procedure, like this:
(define foo)
(define (initialize-package)
(set! foo (+ bar 1)))
Quite frankly, I think that most such initialization procedures are
silly.
And you used (load-package-set "test") but did not put your package
descriptions in load order.
It should not be my job to topologically sort a partial order of
dependencies; my job should be only to identify the individual edges.
Seriously, I should not be labeling efforts as "serious" or not. I am
sure Lisps' many defsystems were all "serious", and your own desires
heartfelt. I meant only that I did not see a concrete spec., nor even
a consensus, on the horizon. Our home page lead me to believe
otherwise.
Consensus? Ha! I hardly expect that any time soon. But I hope I
haven't discouraged you from thinking about module systems -- I just
want to make sure that we don't put ourselves into a state of an
incrementally kludged CREF that works sort of well enough most of the
time that we never become motivated to do something better, or at
least I don't want us to become more entrenched in that state.
If build process automation gets you hot, you must be familiar with
the examples of edwin.sf, compiler.sf, etc. Do they not argue that
staging and re-building are tricksy and full-blown Scheme is
appropriate?
I think those are all pretty silly too. They were derived from some
basic information about the organization of the compiler and Edwin
(`what are the components of the system and their relations?'), but
rather than expressing anything close to that information, they
instead express procedural information about building the systems
(`how do I compile and load this system so that it works?'). CREF is
just not capable of expressing some of this basic information about
Edwin's and LIAR's organization, particularly concerning macros and
other compile-time dependencies.
I could use more procedures like sf-conditionally, or the
sf-with-dependencies in edwin/decls.scm -- not another defsystem.
DEFSYSTEM (of the ASDF or MK varieties) is at best a is at best a
marginal improvement over writing totally ordered load sequences,
because it relies entirely on the programmer to supply every edge in
its dependency graph, and it blindly believes them -- it has no way to
check what each edge means and whether there is any actual connection
between each edge and the relevant code. For example, DEFSYSTEM knows
nothing about definitions and uses of variables.
I have, no doubt, been too terse in this discussion. I need to write
up in a more presentable format some of my thoughts on module systems,
and an overall idea of what problems they must solve and how they can
solve them. I hope to do so some time this week, now that I have a
little time on my hands.