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

[Chris Hanson]

   Date: Wed, 14 Sep 2005 05:36:05 +0000 (UTC)
   From: Taylor Campbell <address@hidden>

   Can you elaborate on the ideas you have?

There are a few principles I have in mind.  These seem to be almost
orthogonal to what you have been concerned about, though I'll have to
read your document more carefully and think about it.

* The primary function of the module system is to link code together,
  by associating names in different code fragments.

* Names are linked together by sharing a value cell.

* Top-level environments are an internal artifact of the module
  system.  They need not exist at run time, and the debugger may or
  may not choose to present them to the user.

* An "interface" is essentially an annotated set of names.  (See the
  attached document "modules.html".)  The annotation provides
  information about the values associated with the names, for the use
  of the compiler and other tools.

* A code fragment has an associated interface that is derived from the
  source code.  This interface can be transformed according to some
  simple rules (see "modules.html"), either by declarations in the
  source or externally.  The code fragment, along with its (possibly
  transformed) interface is an "implementation".

* Specification, transform, and other manipulations of interfaces are
  a function of the linker.  There should be a linking language that
  supports these activities.

Here is my quick take on your document:

(1) Simplicity & semantic cleanliness

        yes

(2) Environment control

        yes, in general, though I don't agree with the specifics

(3) Compilation control & macro semantics

        I see this as orthogonal to the problem of naming/linking

(4) Feature control/system distribution

        I don't entirely understand this one

(5) Interactive development

        yes

(6) Separation of interface from implementation

        yes

(7) Abstraction at the module level: parameterized modules

        umm, I think so.  But I'd probably deal with this by
        programming in the linking language.

(8) Mutual reference

        mutual reference is certainly required, but I'm not sure a
        theory is needed.

(9) Purely declarative language

        maybe.  I'd have to decide this one after playing with it for
        a while.

(10) Dynamic loading support

        yes

(11) Language generality & reader customization

        more or less.  the linker operates on binary objects, not
        source, so some of this is moot.

(12) OS-independence without OS-clashing

        yes

(13) File system interaction

        I don't have a problem with modules consisting only of whole
        files, as long as they can contain multiple files.  But since
        the linker deals with binary objects, that's a separable
        issue.  If the compiler wants to support multiple binaries
        froma single file, the linker doesn't need to know.

(14) No meta-modular complexity

        I don't understand this.

(15) Interaction with compiler optimization

        yes -- the nameset annotations provide that.

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

That sounds reasonable.

   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.

I've been working on persistence in the context of web services.  I'd
like to have a naming structure that scales to shared "environments"
all over the world.

A name is a combination of an identifier and a set of properties. The properties provide additional information about the use of the identifier, such as the type of the value, or whether the value cell is read-only. One property is required, which specifies whether an identifier represents a syntactic keyword or a variable binding. All other properties are optional.

A nameset is a set of names in which no two names in the set have the same identifier. Namesets can be transformed in a few ways, as follows:

• A subset transform maps a nameset to another nameset that is a subset of the original.

• A union transform maps two namesets into a larger nameset containing all of the names in both. The given namesets must be disjoint, meaning that there is no name in one set that has the same identifier as a name in the other. (This restriction may be relaxed in the future as the model is refined.)

• An alpha transform maps a nameset to another nameset that is identical except that some of the names' identifiers might be different. The transformed nameset has exactly the same number of elements as the original.

• A restriction transform maps a nameset to another nameset with more restrictive properties on some or all of the names. What more restrictive means is hard to define in general terms, but some specific examples should help make it clearer:

  • If a property is like a type, in that it describes a class of possible values, a restriction of that type must describe a subset of the original class.

  • If a property says that a value cell is read/write, then it may be restricted to read-only. But the reverse is not allowed.

  • If the presence of a property is more restrictive than its absence (as is generally the case), then the property may be added but may not be removed. An example would be a read-only property, in which read/write is the default when the read-only property is absent.

  The underlying principle is that the properties of a name are defined by the nameset being transformed. Such properties may be restricted, since more restrictive properties still meet the original definition. But less restrictive properties permit uses that don't meet the original definition, and are consequently forbidden.