Additions to the Slate spec

RE01 Rice Brian T. EM2
Sun, 19 Nov 2000 15:31:12 -0800

Hey Lee, Tunesers, and Slate people,

My access to the web has been sparse and fairly dismal lately, so a lot =
research and communication has been hampered. To complicate this, my =
image seems to have been corrupted by a PC-to-Mac conversion error. It =
functions, but a lot of bugs creep up unexpectedly that make normal =
very tedious. At any rate, I am getting more proficient with VIM and =
so maybe this is helpful (for coding in other languages). Also, =
Self 4.1 directly has been quite useful.

Anyway, since I'm not allowed to transfer files onto the LAN where I =
can use
e-mail, and I can't print out my notes for transcription, I'll =
what I've been working out. There are several things to address.

1. Using the lookup phase to make the system more flexible: if we allow =
quoting function to be open and flexible, then we can use the various
"modes" of quoting to distinguish between slots that are part of =
aspects (views) of an object. This could have quite a few benefits.

Keep in mind that the quoting mechanism changes could be really simple, =
(using lisp notation) "(define (quote' object) (lambda object (quote =
object foo))))". I'm suggesting that "'foo" would be a simple way to =
slots available for lookup or unavailable depending on the lookup =
specified. Probably a lot of this would be meta-programmed (Slate =
explained below).

Ex: the stack could be a slot (or set of slots) passed around with its =
unique quoting mechanism. This would essentially allow for a
continuation-passing style of programming when desired. Of course, =
would immediately say that those slots should be linearly passed =
around, and
I'd have to agree. At any rate, it allows objects to look at the =
"sender" of
the "messages" it receives and act according to that, which gives us a
handle for security without compromising the language design. Of =
it's undesirable to force users to explicitly pass the stack around all =
time, which is why we should look into the ability to compose rewrites.
(There also shouldn't be anything wrong with implementing the stack =
the low-level stack, as long as it's wrapped properly.)

2. As for linearity/nonlinearity of slots, it seems that this should be
handled by a transaction scheme at the meta-level, but how this should =
done exactly is still fuzzy for me :/. At any rate, here's some =
for the kind of transaction I'm considering:

Linear, strict (no copies) case:
Code: "<< my-secure-space private-PGP-key .... print ."
at the my-secure-space access, we're given a namespace whose lookups =
guarded, so we see something like this:
"i'd like slot private-PGP-key"
to which could be replied:
"slot not found. perhaps you don't have the right access key for this
or "accesses from your location are not allowed by this object's =
(the author could be another program, not just a user)
or perhaps it could simply add annotations to to the stack slots so =
that if
the rewrite method of that object were requested to be invoked ("."), =
it would block with a similar message.

Linear, non-strict (you get copies, you change copies, but the original =
read-only) case:
This can get elaborate, as you recall we discovered earlier considering
concurrent rewrites on the object graph. This complication will have to =
worked out later. At any rate, our "method" slots would have to work =

Nonlinear case:
Basically no interaction happens except that the object gets marked as
nonlinear so that the GC handles it appropriately.

3. All of the above affects what kind of rewrite methods the system =
have to use. as Tunes specifies, Slate's method structure consists of
objects instead of meta-objects, but the rewrite aspects are handled at =
meta-level. Because this makes rewrite essentially invisible when =
looking at
source code, it should be relatively consistent all around. For one, =
usual rewrite should essentially be the equivalent of "pop", the
counterpoint of the "pushes" that are happening when we perform =

The exceptions would be where the assignment slot ":" affects its =
slot "^", or the various cloning rewrites (ones that clone just the =
slot one
level up, two levels up, or ones that essentially clone whole =
which would be meta-programmed.

4. Object/code format. Earlier, I was averse to the idea of using =
object-initialization syntax, and I tossed out the code format with it.
However, there's a small aspect of it which I think is useful, even =
useful for Slate. Since Slate's syntax is a sequence of symbol-lookups =
application hooks, I can model code as a sequence itself. In the =
case, I could take code like the above:

"<< my-secure-space private-PGP-key .... print ^ ."

And turn it into Slate object structure: (using a totally non-syntactic

	1: '<
	2: '<
	3: 'my-secure-space
	4: 'private-PGP-key
	5: .
	6: .
	7: .
	8: .
	9: 'print
	10: '^
	11: .

Although "." would have to be distinguished from slot-access. Anyway, =
at this level where lazy evaluation counts.

Also, this simple code shape allows for meta-programming in a couple of
different ways. For one, the lookup method could generate objects on =
based on the symbol key used, and build the code for it using sequence
manipulation protocols (concatenate, insert, replace, etc.).

5. Speaking of meta-programming, there's a tiny meta-language that I've
discovered can be added to Slate. What it does is basically dynamic =
creation within the same namespace as the method object. It also allows =
to add a kind of anonymous closure-structure to Slate grammar.

Basically, we could reserve "(" and ")" slots for this purpose. "(" =
would be
a clone of the surrounding namespace, to which would be mixed-in =
characteristics that would pass around objects like closures do. ")" =
do a similar thing. I have some of the details worked out on my other
computer, but I need to work out the stack slot protocol first. As for
recursive use of "(" and ")", those would merely be the slots of those
objects looked up dynamically within the outer "(" and ")", so the =
would be understandable as far as I can tell. Perhaps other kinds of
brackets ("[]" or "{}" or "(* *)"?) would allow for variations on this

At any rate, the availability of the stack itself and the frames there =
allow Slate code to take on lexical structure using the methods I =
above. Ordinarily, it would be a minimal Forth-like system of code, =
lacks a lot of security and genericity.

That's most of what I have for now, in rough form. As I get more of =
specified, I'll add to the prototype code to see how it flies.

Thanks for the interest,

P.S. I will be back home from this long trip in two days. I'd like to =
with Tril, Far=E9, Lee, hcf, and other interested parties on IRC to =
the documentation and code development.