Date: Tue, 13 Sep 2005 20:19:04 -0400
From: Chris Hanson <[EMAIL PROTECTED]>
Date: Tue, 13 Sep 2005 20:11:28 +0000 (UTC)
From: Taylor Campbell <[EMAIL PROTECTED]>
As I understand it (and an MIT Scheme developer or designer should
correct me if I misunderstand), the .pkg files are intended only for
two purposes: cross-referencing information and the automated
generation of loaders for systems.
Originally, this was true. But current usage of this code is to
support modules. It's very clumsy and not at all convenient, but it
(just barely) works well enough to support the core system.
I more or less know what I would like to have in its place. And the
lack of a good module system makes my life difficult when developing
applications. But I don't have the time to work on this right now.
Can you elaborate on the ideas you have? I'm interested to hear of
approaches different from what I'm already familiar with, which is
primarily that of Scheme48. I already have a pretty good idea of what
I think a module system must entail, which I wrote down in the form of
notes for myself at <http://mumble.net/~campbell/t/module.text>. (I
apologize for some of the tone in that document and for some absent
information necessary to understand some of the remarks, which might
seem wrong without that context; I must emphasize that it was written
primarily as notes to myself, though some of the information there
presented might be of use to others.)
While this is related to the environment in which a file is
intended to be loaded, the information is not entirely analogous,
it requires more effort than is necessary to extract the desired
information, and the desired information may not even be present in
the .pkg file, since the source file might not be a regular package
in a regular system at all (e.g., the .edwin file).
Actually the .pkd (_not_ .pkg) file is pretty simple to use and
contains all the necessary linking info for those files that are
managed using that mechanism.
This is true of systems (in the specific sense), where each file
corresponds to a specific package and vice versa, but not necessarily
of other files, such as the .edwin file, as I mentioned. Perhaps, by
the way, I ought to use the term 'environment' instead of 'package'
for the local variable, since it does not specify the package that the
file corresponds to but rather the environment in which to evaluate
code from that buffer. (I believe, though, if my autodidactically
understood terminology is accurate, that the list-structured name is
that of a package, underlying which is the evaluation environment.)
Also, it might be useful anyway to provide the -*- line local
variables facility for other libraries to use.
I agree that this is useful and is a reasonable thing to do. But only
because of tradition, and for simple cases where modules aren't used.
I don't like having redundant information in the source files when
that information can be derived from the module descriptions.
Sorry, perhaps I ought to have clarified there: I was referring to a
general -*- line parser for any Edwin library to utilize, not just one
more specialized local variable (mode) that Edwin internally happens
to recognize. E.g., there might be a (DEFINE-*-LINE-HANDLER name
procedure) procedure, with which one might implement the 'package' (or
'environment') local variable like so: (DEFINE-*-LINE-HANDLER 'PACKAGE
(LAMBDA (NAME BUFFER) (SET-VARIABLE! SCHEME-ENVIRONMENT NAME BUFFER)))
If you do decide to implement some support, please support URIs rather
than lists of symbols for the package names. A standard mapping like
(foo bar baz)
==
http://www.gnu.org/software/mit-scheme/cref/foo/bar/baz
will guarantee that there is an isomorphism between cref names and
URIs. (The precise URI used isn't important, but whatever is used
must be valid URI syntax.) Later, when we have a real module system,
it will also use URIs to identify modules, and no changes will be
needed to this interface.
The latest snapshot (from yesterday) has a new URI support library in
the runtime. I plan to add a simple URI <-> object mapping function
in the near future, which can be used by any program to register names
for environments, whether or not they use modules.
Is this snapshot available anywhere? I checked the Savannah project
page, but I didn't see anything relevant in the news section. Also,
can you elaborate a little on the URI-based naming scheme you had in
mind for the module system? Having HTTP URLs name packages seems a
little strange to me; I like the system of lists of names, but perhaps
there's a more general reason.
Updating Edwin (which _is_ approximately at the level of Emacs 18) is
a major undertaking and not worth the effort. Although I like Edwin
and almost always use it in preference to Emacs, it's clear Edwin will
never be able to keep up with Emacs, given that there are hundreds or
thousands of people contributing to Emacs.
While Edwin may never be able to keep up as an Emacs clone, I think it
might still be useful for experimentation along a different track than
that of straight Emacs emulation. For example, I'm considering the
possibility of implementing some of the high-level syntax editor
facilities from Climacs <http://common-lisp.net/project/climacs/> in
Edwin, rather than the rudimentary S-expression text parser design as
copied from Emacs. (Unfortunately, I don't at the moment have the
time to do much with this; on a related note, I started implementing
my paredit.el library <http://mumble.net/~campbell/emacs/paredit.el>,
for pseudo-structurally editing Lisp code in Emacs, in Edwin, but I
don't have the time at the present moment to finish it, though I do
intend to at some point.)
A more useful thing to do is build a better interface to Emacs. There
are a variety of tightly-coupled interaction features in Edwin that it
would be nice to have in Emacs, such as variable completion and
per-buffer evaluation environments. The old Emacs interface is pretty
fragile and should probably be replaced rather than extended.
I have toyed with the notion of implementing an MIT Scheme back end
for SLIME, the Superior Lisp Interaction Mode for Emacs (for further
details about which, see <http://cliki.net/SLIME>), which I have
already written a considerable portion of a Scheme48 back end for. It
is the canonical Emacs-based Common Lisp development environment now,
and I think MIT Scheme & Scheme48 are the best suited Schemes I know
of to interacting gracefully with it. SLIME supports the features you
note here -- per-buffer evaluation environments & variable completion
--, as well as some other very useful tools like a thread browser (not
just per-REPL threads).
_______________________________________________
MIT-Scheme-users mailing list
MIT-Scheme-users@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-users
