Date: Wed, 14 Sep 2005 05:36:05 +0000 (UTC) From: Taylor Campbell <[EMAIL PROTECTED]>
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.
-
_______________________________________________ MIT-Scheme-users mailing list MIT-Scheme-users@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-users
