Re: [MIT-Scheme-users] associating environments with Scheme file buffers in Edwin

[Taylor Campbell]

   Date: Tue, 13 Sep 2005 20:19:04 -0400
   From: Chris Hanson <address@hidden>

      Date: Tue, 13 Sep 2005 20:11:28 +0000 (UTC)
      From: Taylor Campbell <address@hidden>

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