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.
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.
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.
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.
Well, there's a lot more to be done there and probably,
unfortunately, not quite enough effort to accomplish it. I'm a bit
more interested in a useful Scheme environment, though, not just an
exact Emacs clone. (Also, I don't know of any Emacs library except
a very recently made one (namely scheme48.el) that respects a local
'package' variable.)
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.
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.
_______________________________________________
MIT-Scheme-users mailing list
MIT-Scheme-users@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-users
