*start*
00593 00112 US
gvMsgID: Horning.pa $ 3#14@ 1-Sep-82 9:19:00 PDT
Categories: interscript-t-sep82-dec82
Date: 1 Sept. 1982 9:19 am PDT (Wednesday)
From: Horning.pa
Subject: Re: Forward Compatibility on Node Types
In-reply-to: Ayers' message of 31-Aug-82 16:02:24 PDT (Tuesday)
To: Ayers
cc: Interscript
Bob,
Is the proposal that the ordering relationship be strictly numeric? PARA-10$
includes PARA-9$, etc.
I foresee a demand (which should probably be resisted), for subversions
(PARA-1.1$), incompatible alternatives that are both incompatible (PARA-1A$,
PARA-1B$), etc.
Jim H.
*start*
01144 00112 US
gvMsgID: Horning.pa $ 3#14@ 1-Sep-82 9:30:00 PDT
Categories: interscript-t-sep82-dec82
Date: 1 Sept. 1982 9:30 am PDT (Wednesday)
From: Horning.pa
Subject: Re: Motivation: Forward Compatibility on Node Types
In-reply-to: Ayers' message of 31-Aug-82 18:55:18 PDT (Tuesday)
To: Ayers
cc: Interscript
Bob,
[I should have read the whole correspondence before answering.]
There is also possibility
4. Use marks as originally contemplated. Leave the definition of PARA$
unchanged, and add the mark COLOR$ to nodes with color.
Old editors can accept new scripts, but will not be able to edit PARA$
COLOR$ nodes (although they can continue to edit PARA$ nodes that don't
have COLOR$, and to display PARA$ COLOR$ nodes).
New editors can accept and edit both, since they "automatically" "know"
that they can treat the PARA$ like PARA$.
Arrangement 4. is not only more bountiful than arrangement 3, it doesn't require
a linearization of something that is sure to be a lattice. It has the drawback that
PARA$COLOR$GRAPHICS$BARCHARTS$THREED$ is somewhat longer and
clumsier than PARA-43$.
Jim H.
*start*
00764 00113 US
gvMsgID: McGregor.pa $ 3#14@ 1-Sep-82 10:15:40 PDT
Categories: interscript-t-sep82-dec82
Date: 1-Sep-82 10:15:40 PDT
From: McGregor.pa
Subject: Re: Motivation: Forward Compatibility on Node Types
In-reply-to: Horning's message of 1 Sept. 1982 9:30 am PDT (Wednesday)
To: Horning.pa
cc: Ayers, Interscript
I strongly approve of Jim's suggestion to use marks. They provide all of the functionality of proposals 1-3 without the problem of assigning ordered versions if several editors all want to add new functionality to paragraphs. E.g. PARA-43$ has both color and texture, PARA-42$ only had color and $PARA-41$ only had texture.
The verbosity of PARA$COLOR$GRAPHICS$BARCHARTS$THREED$ probably goes away with encoding schemes.
Scott.
*start*
00557 00113 US
gvMsgID: Mitchell.PA $ 3#14@ 1-Sep-82 10:30:00 PDT
Categories: interscript-t-sep82-dec82
Date: 1 Sept. 1982 10:30 am PDT (Wednesday)
From: Mitchell.PA
Subject: Re: Motivation: Forward Compatibility on Node Types
In-reply-to: McGregor's message of 1-Sep-82 10:15:40 PDT
To: McGregor
cc: Horning, Ayers, Interscript
I agree, and the verbosity goes away by using something like:
r ← 'PARA$ COLOR$ GRAPHICS$ BARCHARTS$ THREED$'
once and then simply invoking r as necessary:
{r <Now is the time for ... Interscript>}
Jim M.
*start*
00468 00110 US
gvMsgID: Ayers.PA $ 3#14@ 2-Sep-82 11:16:47 PDT
Categories: interscript-t-sep82-dec82
Date: 2-Sep-82 11:16:47 PDT (Thursday)
From: Ayers.PA
Subject: Draft Concepts and Facilities
To: JMoyer
cc: Interscript
The (fragmentary) draft Concepts and Facilities that is to be sent to Charles' subcommitee can be found as McKinley > PubliC Ayers > InterS C and F 1sept82.
It is formatted for each document in the folder to be printed two-sided.
Bob
*start*
00689 00110 US
gvMsgID: Ayers.PA $ 3#14@18-Sep-82 11:28:04 PDT
Categories: interscript-t-sep82-dec82
Date: 18-Sep-82 11:28:04 PDT (Saturday)
From: Ayers.PA
Subject: Seybold Report on Publishing: Watchtower/IBM Publishing System
To: Interscript
Recommended reading: a twelve page report in the current Seybold on the Watchtower (Jehovah Witness printing arm) designed and developed publishing system that is now available as a "installed user program" from IBM.
Features: styles a la GML, page-layout via boxes and text flow from box to box, tables, math, horizontal and vertical justification via TEX-like "penalties", fancy run-around (e.g. around a circular picture ...
Bob
*start*
00727 00110 US
gvMsgID: Ayers.PA $ 3#14@21-Sep-82 14:21:47 PDT
Categories: interscript-t-sep82-dec82
Date: 21-Sep-82 14:21:47 PDT (Tuesday)
From: Ayers.PA
Subject: Found in a Ms ...
To: Interscript
From the "First Working Draft" of X3J6's "Computer Languages for the Processing of Text"
Section 15: Formatting:
"... Any who expect two different implementations of this standard to produce
identical output on identical devices from identical input will be disappointed.
It may be possible to guarantee that the output form will be the same, but
differences in widowing, hyphenation, kerning and other such procedural items
will make it unlikely that page and line breaks occur in the same places."
Bob
*start*
00450 00110 US
gvMsgID: Ayers.PA $ 3#14@28-Sep-82 16:45:04 PDT
Categories: interscript-t-sep82-dec82
Date: 28-Sep-82 16:45:04 PDT (Tuesday)
From: Ayers.PA
Subject: Private Tags ??
To: Mitchell
cc: Horning, Ayers
I see that tag ::= universal "$"
I thought that we could have "wellknown" tags like TEXT$ and also private tags like graphicsframe$ and we told them apart based on upper-case-ness.
Was this just a delusion of mine?
Bob
*start*
00467 00112 US
gvMsgID: Horning.pa $ 3#14@28-Sep-82 17:45:00 PDT
Categories: interscript-t-sep82-dec82
Date: 28 Sept. 1982 5:45 pm PDT (Tuesday)
From: Horning.pa
Subject: Re: "Node" => "Span" ??
In-reply-to: Ayers' message of 28-Sep-82 16:34:58 PDT (Tuesday)
To: Ayers
cc: Interscript
Bob,
Reads OK to me. I'd been playing with "Group" or "Unit," but "Span" is pretty
neutral (therefore, likely to be trouble-free), unless you're a SNOBOL hacker.
Jim H.
*start*
00438 00110 US
gvMsgID: Ayers.PA $ 3#14@28-Sep-82 16:34:58 PDT
Categories: interscript-t-sep82-dec82
Date: 28-Sep-82 16:34:58 PDT (Tuesday)
From: Ayers.PA
Subject: "Node" => "Span" ??
To: Interscript
I've never liked the word "node" in the language [node ::= "{" item* "}"]. It seems to computer-ese and not enough document-ese.
How about "span"? I'm starting to write the standard and "span" reads much more naturally.
Bob
*start*
00339 00113 US
gvMsgID: Mitchell.PA $ 3#14@29-Sep-82 9:48:00 PDT
Categories: interscript-t-sep82-dec82
Date: 29 Sept. 1982 9:48 am PDT (Wednesday)
From: Mitchell.PA
Subject: Re: "Node" => "Span" ??
In-reply-to: Ayers' message of 28-Sep-82 16:34:58 PDT (Tuesday)
To: Ayers
cc: Interscript
I think "span" is a fine term.
Jim M.
*start*
00347 00112 US
gvMsgID: Horning.pa $ 3#14@28-Sep-82 17:46:00 PDT
Categories: interscript-t-sep82-dec82
Date: 28 Sept. 1982 5:46 pm PDT (Tuesday)
From: Horning.pa
Subject: Re: Private Tags ??
In-reply-to: Ayers' message of 28-Sep-82 16:45:04 PDT (Tuesday)
To: Ayers
cc: Mitchell, Horning
Bob,
If so, I've suppressed the memory.
Jim H.
*start*
00791 00110 US
gvMsgID: Ayers.PA $ 3#14@28-Sep-82 17:07:22 PDT
Categories: interscript-t-sep82-dec82
Date: 28-Sep-82 17:07:22 PDT (Tuesday)
From: Ayers.PA
Subject: Untagged nodes
To: Interscript
A while back, we discussed the untagged node. Example:
{ TEXT$ <cat dog > { font.italic←TRUE <unicorn> } < fox bat> }
where the utility of the untagged node is precisely that the "}" pops local changes to the environment.
I suggest that we shouldn't use a node for this purpose, but use some more lightweight mechanism [up arrow and down arrow in the syntax?].
Even if we DO use a node like this, I propose to CALL it something else. E.g. call a 'real' node a "span" as in "text span" and call the untagged node used for push-pop purposes a "interval"? "descent"? "chunk"?
Bob
*start*
00430 00112 US
gvMsgID: Horning.pa $ 3#14@28-Sep-82 17:49:00 PDT
Categories: interscript-t-sep82-dec82
Date: 28 Sept. 1982 5:49 pm PDT (Tuesday)
From: Horning.pa
Subject: Re: Untagged nodes
In-reply-to: Ayers' message of 28-Sep-82 17:07:22 PDT (Tuesday)
To: Ayers
cc: Interscript
?
Why not "untagged span"? Or are you proposing that the weight of the
mechanism should differ by more than the presence/absence of tags?
*start*
00824 00113 US
gvMsgID: Mitchell.PA $ 3#14@29-Sep-82 9:54:00 PDT
Categories: interscript-t-sep82-dec82
Date: 29 Sept. 1982 9:54 am PDT (Wednesday)
From: Mitchell.PA
Subject: Re: Private Tags ??
In-reply-to: Ayers' message of 28-Sep-82 16:45:04 PDT (Tuesday)
To: Ayers
cc: Mitchell, Horning
I see no reason why private tags shouldn't be universal ids (i.e., like Lisp
atoms). You are perfectly free to use a private tag like GRAPHICSFRAME$. I
don't see any need to tell them apart, since there will undoubtedly be public
tags that a given editor doesn't understand either.
You might worry that a private tag might conflict with a future, legitimate, but
unrelated public tag (e.g., GRAPHICSFRAME$). In that case, one could use some
simple convention like PRIVATEGRAPHICSFRAME$ to ensure uniqueness.
Jim M.
*start*
00695 00113 US
gvMsgID: Mitchell.PA $ 3#14@29-Sep-82 10:00:00 PDT
Categories: interscript-t-sep82-dec82
Date: 29 Sept. 1982 10:00 am PDT (Wednesday)
From: Mitchell.PA
Subject: Re: Untagged nodes
In-reply-to: Horning's message of 28 Sept. 1982 5:49 pm PDT (Tuesday)
To: Horning
cc: Ayers, Interscript
This is in response to Jim Horning's comment about untagged spans.
I think we should reserve untagged spans for simple nesting and scope. This is
a need that has cropped up from time to time. If untagged spans could also
denote spans with private meanings but no tags, I think it would cause trouble.
So I vote for using them solely for grouping a sequence of (sub)spans.
Jim M.
*start*
06009 00110 US
gvMsgID: Ayers.PA $ 3#14@29-Sep-82 10:45:30 PDT
Categories: interscript-t-sep82-dec82
Date: 29-Sep-82 10:45:30 PDT (Wednesday)
From: Ayers.PA
Subject: On "Pure Subsets"
To: Mitchell
That was really the same conversation as the one on forward compatibility. Horning's suggestion of "PARA$ COLOR$" seems to have been the best one.
----------
Date: 31-Aug-82 16:02:24 PDT (Tuesday)
From: Ayers.PA
Subject: Forward Compatibility on Node Types
To: Interscript
I propose that we allow for smooth extensibility of our standard node types.
If we name our paragraph node a PARA-0$, then we can, later, define a PARA-1$ which incorporates everything in a PARA-0$ with some new goodies.
Then an editor which "understands" a PARA-1$ node can easily know that it also "understands" all PARA-0$ nodes just by considering that they are the same as a PARA-1$.
Bob
----------
Date: 31 Aug. 1982 5:37 pm PDT (Tuesday)
From: Mitchell.PA
Subject: Re: Forward Compatibility on Node Types
In-reply-to: Ayers' message of 31-Aug-82 16:02:24 PDT (Tuesday)
To: Ayers
cc: Interscript
If you just call them PARA0$ and PARA1$ the current language will even allow
it. It sounds like a fine idea (but I immediately have visions of PARA43$. Why
is that?).
Jim
----------
Date: 31-Aug-82 17:55:39 PDT (Tuesday)
From: Ayers.PA
Subject: Re: Forward Compatibility on Node Types
In-reply-to: Mitchell's message of 31 Aug. 1982 5:37 pm PDT (Tuesday)
To: Mitchell
cc: Interscript
Yes, I understand that the language allows it.
What I was trying to suggest was that we institutionalize, via the semantics in the standard, that PARA23$ MUST define a strict superset of PARA22$. This would allow editors to implement back-compatibility without a bound-in list of the flavor "NEWPARA$ is a superset of PARA81$ is a superset of PARA$ ..."
That's all.
Bob
---------
Date: 31-Aug-82 18:55:18 PDT (Tuesday)
From: Ayers.PA
Subject: Motivation: Forward Compatibility on Node Types
In-reply-to: Karlton's message of 31-Aug-82 17:58:04 PDT (Tuesday)
To: Karlton
cc: Interscript
Suppose that, after the Interscript standard is approved, we see the need to add a new semantic (say "color") to the PARA$.
We have three choices:
1. Update to a new INCOMPATIBLE version (Interscript83) of the standard which
has "color" in a PARA$.
Old editors (that understood Interscript82) would not be able to
accept any Interscript83 documents.
New editors that wanted to continue to process Interscript82
would contain special compatibility code.
2. Update to a new COMPATIBLE version of the standard by introducing a new
node, the PARAX$, which is like a PARA$ but with "color."
Old editors can accept new scripts, but will not be able to edit PARAX$s.
New Editors will contain special code reminding them that they can,
luckily, display and edit PARA$s with the same module that plays with PARAX$s.
3. Arrange things so we can update to a new compatible version of the standard
with a PARA-1$, which is like a PARA-0$ but with "color."
Old editors can accept new scripts, but will not be able to edit PARA-1$s.
New editors can accept and edit both, since they "automatically" "know"
that they can treat the PARA-1$ like a PARA-0$.
Arrangement three seems the most bountiful.
Bob
----------
Date: 1 Sept. 1982 9:19 am PDT (Wednesday)
From: Horning.pa
Subject: Re: Forward Compatibility on Node Types
In-reply-to: Ayers' message of 31-Aug-82 16:02:24 PDT (Tuesday)
To: Ayers
cc: Interscript
Bob,
Is the proposal that the ordering relationship be strictly numeric? PARA-10$
includes PARA-9$, etc.
I foresee a demand (which should probably be resisted), for subversions
(PARA-1.1$), incompatible alternatives that are both incompatible (PARA-1A$,
PARA-1B$), etc.
Jim H.
----------
Date: 1 Sept. 1982 9:30 am PDT (Wednesday)
From: Horning.pa
Subject: Re: Motivation: Forward Compatibility on Node Types
In-reply-to: Ayers' message of 31-Aug-82 18:55:18 PDT (Tuesday)
To: Ayers
cc: Interscript
Bob,
[I should have read the whole correspondence before answering.]
There is also possibility
4. Use marks as originally contemplated. Leave the definition of PARA$
unchanged, and add the mark COLOR$ to nodes with color.
Old editors can accept new scripts, but will not be able to edit PARA$
COLOR$ nodes (although they can continue to edit PARA$ nodes that don't
have COLOR$, and to display PARA$ COLOR$ nodes).
New editors can accept and edit both, since they "automatically" "know"
that they can treat the PARA$ like PARA$.
Arrangement 4. is not only more bountiful than arrangement 3, it doesn't require
a linearization of something that is sure to be a lattice. It has the drawback that
PARA$COLOR$GRAPHICS$BARCHARTS$THREED$ is somewhat longer and
clumsier than PARA-43$.
Jim H.
----------
Date: 1-Sep-82 10:15:40 PDT
From: McGregor.pa
Subject: Re: Motivation: Forward Compatibility on Node Types
In-reply-to: Horning's message of 1 Sept. 1982 9:30 am PDT (Wednesday)
To: Horning.pa
cc: Ayers, Interscript
I strongly approve of Jim's suggestion to use marks. They provide all of the functionality of proposals 1-3 without the problem of assigning ordered versions if several editors all want to add new functionality to paragraphs. E.g. PARA-43$ has both color and texture, PARA-42$ only had color and $PARA-41$ only had texture.
The verbosity of PARA$COLOR$GRAPHICS$BARCHARTS$THREED$ probably goes away with encoding schemes.
Scott.
----------
Date: 1 Sept. 1982 10:30 am PDT (Wednesday)
From: Mitchell.PA
Subject: Re: Motivation: Forward Compatibility on Node Types
In-reply-to: McGregor's message of 1-Sep-82 10:15:40 PDT
To: McGregor
cc: Horning, Ayers, Interscript
I agree, and the verbosity goes away by using something like:
r ← 'PARA$ COLOR$ GRAPHICS$ BARCHARTS$ THREED$'
once and then simply invoking r as necessary:
{r <Now is the time for ... Interscript>}
Jim M.
*start*
00466 00113 US
gvMsgID: Mitchell.PA $ 3#14@ 2-Sep-82 18:12:00 PDT
Categories: interscript-t-sep82-dec82
Date: 2 Sept. 1982 6:12 pm PDT (Thursday)
From: Mitchell.PA
Subject: Part of a document model for Karlton's Interscript implementation
To: Mitchell
cc: Interscript, Mitchell
span := [ | preSp←0 size←NIL postSp←0]
box := [ | x ← span y←span]
pageFrame := [box| x.size←8.5*inch y.size←11*inch]
placement := [ | n←FLUSH s←RAGGED w←FLUSH e←RAGGED]
*start*
01178 00110 US
gvMsgID: Ayers.pa $ 3#14@ 9-Sep-82 17:57:42 PDT
Categories: interscript-t-sep82-dec82
Date: 9-Sep-82 17:57:42 PDT (Thursday)
From: Ayers.pa
Subject: Character Numbers
To: Interscript
We state that the charcaters in the text are, effectively, numbers .. positive integers.
Let's bound them. Otherwise someone will create a script with the character "1234567890987654321234567890123456789 " in it and complain about the editor that doesn't handle it.
Proposal:
1. We allow only characters in [0..65535]
2. Within that range, we (as the Japanese Industrial Standard does) allow only characters that are either:
a. In [40B..176B] or in [240B..376B] (ISO graphic positions)
b. Such that their high order byte and their low order byte are both
in [40B..176B] or in [240B..376B].
The above happens to match the current Xerox Character Set Standard.
[Note: What JIS did was to arrange things so that any non-ISO646 character was a sixteen bit character such that each half appears to be a ISO646 character. Thus they avoid all difficulties with a byte turning out to be a control code.]
Bob
PS: Meeting Friday is at 3:30 in 100G as usual.
*start*
01663 00112 US
gvMsgID: Lampson.PA $ 3#14@ 5-Oct-82 19:23:00 PDT
Categories: interscript-t-sep82-dec82
Date: 5 Oct. 1982 10:23 pm EDT (Tuesday)
From: Lampson.PA
Subject: Re: External References in Scripts
In-reply-to: GCurry.ES's message of 29-Sep-82 11:00:56 PDT (Wednesday)
To: GCurry.ES
cc: Mitchell, Interscript
Interpress has an encoding notation which allows a distinct file to be included,
using an installation-specific convention for naming. The semantics is defined to
be identical to textually including the file (possibly after some
installation-specific transformation) in the master. This seems like a reasonable
way of handling voice and fax information, which logically is part of the
document. The basic idea is that the separation is strictly an encoding device,
and has no impact on the standard. It is possible to make a convention that, for
instance, something included must be a complete node, or whatever else might
make it easy to skip over the inclusion. The naming conventions are strictly
those of the installation, and the implementation should provide a way of making
a script in which all the inclusions are replaced by copies, for transmission to
non-cooperating installations. Of course, "installation" doesn't necessarily mean a
single site, just a single naming environment and set of conventions for turning
the inclusion into legal tokens.
I think the proper way to handle style sheets is by a notion of parameterization,
as is done in System Modelling. A parameterized script is turned into a complete
script only when arguments are supplied for the parameters. But I haven't tried
to think this through.
Butler
*start*
01124 00112 US
gvMsgID: Horning.pa $ 3#14@ 6-Oct-82 9:54:00 PDT
Categories: interscript-t-sep82-dec82
Date: 6 Oct. 1982 9:54 am PDT (Wednesday)
From: Horning.pa
Subject: Re: External References in Scripts
In-reply-to: Lampson's message of 5 Oct. 1982 10:23 pm EDT (Tuesday)
To: Lampson
cc: Interscript
Butler,
I think I agree with most of that.
The "natural" way to parameterize a script is by using identifiers without explicit
local bindings. Their values will be taken from the (installation-dependent)
global context. Again, a fully bound script can be produced simply by copying
the bindings for all free identifiers from the global context into the script.
Might it be natural to view "the file system" as a globally bound identifier, too?
Then access to a component would be just like the use of any other qualified
name, e.g., FILESYS.filename. The only problem I see with this way of
formalizing external references is that it requires a standardized form of file
name. (I seem to recall that at one point in the distant past this was the
justification for including quoted strings as id's.)
Jim H.
*start*
01346 00113 US
gvMsgID: Mitchell.PA $ 3#14@ 6-Oct-82 10:23:00 PDT
Categories: interscript-t-sep82-dec82
Date: 6 Oct. 1982 10:23 am PDT (Wednesday)
From: Mitchell.PA
Subject: Re: External References in Scripts
In-reply-to: Lampson's message of 5 Oct. 1982 10:23 pm EDT (Tuesday)
To: Lampson
cc: GCurry.ES, Mitchell, Interscript
I agree about the inclusion issue. My proposal is that a node (now being called
a "span") tagged as INCLUDE$ would be replaced by the script that it names, but
at the same level as the INCLUDEd span, not nested within it. This will allow
sets of standard definitions to be included with the result being visible at the
same level as the INCLUDE$ span.
Proposed standard:
Tag: INCLUDE
Contents: a file name specified as a string constant. Depending on the
installation, this may correspond to a print name or a UID for the external script.
Semantics: {INCLUDE$ <name>} is replaced by the body of the script in the
named file, with the standard heading ("Interscript/Interchange/1.0 {") and
trailer ("} ENDSCRIPT") stripped off leaving just the internals of the root span of
the included script. E.g., whien included, the following script results in the
sequence "default.font ← TimesRoman10" replacing the INCLUDE$ span:
Interscript/Interchange/1.0
{ default.font ← TimesRoman10 } ENDSCRIPT
Jim M.
*start*
01986 00111 US
gvMsgID: GCurry.ES $ 3#14@29-Sep-82 11:00:56 PDT
Categories: interscript-t-sep82-dec82
Date: 29-Sep-82 11:00:56 PDT (Wednesday)
From: GCurry.ES
Subject: External References in Scripts
To: Mitchell.pa
cc: Interscript.pa
Jim,
Interscript currently decrees that scripts are self-contained. That seems to cause problems in two concrete situations (described below). This message wonders what recourses we have.
STYLES DATABASE - Is it now the case that Cedar (and later, Star) documents will refer to a styles database for stylistic information. The information may very well be invoked in a document by reference, rather than by value; the intent may be for style editing to happen in the database, rather than in the document. I don't think we have any way to represent this kind of document.
VOICE AND FAX IN DOCUMENTS - We are now considering (have prototypes of) voice and facsimile frames in documents. Voice and FAX information is so large that it is very difficult to treat in the same way as other, smaller document components. This is leading us to consider strategies such as voice/FAX servers, which would be responsible for managing the bulk, digitized information. Voice/FAX information in document would REFER to uniquely named readonly originals on a given server. I don't think we can represent these documents either.
THE GENERAL PROBLEM - seems to be that we are already beginning to work in a "distributed document"s world, where components are readable shared (e.g., voice, fAX) or even writable shared (e.g., styles in a database).
We will encounter some of the same problems you sought to avoid in Interscript (e.g., file system concerns) while not having to deal with others (rigorous specification).
We will either have to relax our assumptions about the self-containedness of scripts or agree to limit our implementations to those without external references. Neither of those seems very pleasant. Any ideas?
Gael
*start*
02197 00111 US
gvMsgID: GCurry.ES $ 3#14@ 6-Oct-82 14:27:19 PDT
Categories: interscript-t-sep82-dec82
Date: 6-Oct-82 14:27:19 PDT (Wednesday)
From: GCurry.ES
Subject: Re: External References in Scripts
In-reply-to: Lampson.PA's message of 5 Oct. 1982 10:23 pm EDT (Tuesday)
To: Lampson.PA
cc: GCurry, Mitchell.PA, Horning.pa, Interscript.PA
I paraphrased your suggestion for my own understanding and drew some conclusions; is the following what you intended?
ILLUSTRATING YOUR SUGGESTION WITH AN EXAMPLE - Suppose there are two "installations", A and B. A document D is created in installation A. Suppose its ENCODING (representation) has two parts, SUPER and SUB; the SUPER part contains a reference to SUB. The VALUE of the document is an Interscript (as defined in Mitchell and Horning's August document) and may be calculated at any INSTANT by textual substitution with other simple transformations. The encoding is installation-specific. If the document must leave the installation, it leaves as its VALUE (i.e., as a single Interscript). Installation B, which receives the Interscript, may then encode the document according to its own conventions (including breaking it into parts).
CONSEQUENCES (?) - The reference from SUPER to SUB is NOT STRUCTURE which must be preserved. That is, it would not be possible to support (with Interscript) a scheme which permitted independent editing of SUPER and SUB. In particular, it would not be possible to support databases of shared, editable document components, where the value of a document at an instant was derived from the "latest" value of its components.
I can see utility to this editable database kind of approach, but it also seems more difficult to manage across installation boundaries, since it relies on the ability of the evaluator of a document to be able to get the latest version of a referenced document component.
Databases of readonly document components would be consistent with your suggestion, however.
ALTERNATIVES(?) - might be to permit true references within installations which can support them, but to "dereference" them as a document crossed an installation's boundaries.
Gael
*start*
00405 00112 US
gvMsgID: Horning.pa $ 3#14@ 8-Oct-82 13:17:00 PDT
Categories: interscript-t-sep82-dec82
Date: 8 Oct. 1982 1:17 pm PDT (Friday)
From: Horning.pa
Subject: Re: External References in Scripts
In-reply-to: Karlton's message of 7-Oct-82 12:08:56 PDT (Thursday)
To: Karlton
cc: Interscript
Phil,
"Would an invocation (INCLUDE["...."]) be more consistent?"
It certainly would.
Jim H.
*start*
00437 00110 US
gvMsgID: Ayers.PA $ 3#14@12-Oct-82 14:32:29 PDT
Categories: interscript-t-sep82-dec82
Date: 12-Oct-82 14:32:29 PDT (Tuesday)
From: Ayers.PA
Subject: 31 August Document: BNF page 21
To: Mitchell
cc: Ayers
What does it mean to allow a 'node' as a 'rhs' ??
Foo ← { TAG$ < content > 1.0 27 assign ← ment }
[Note no quotes anywhere] This is allowed since 'rhs' can be a 'content'
and 'content' can be a 'node'
*start*
00651 00113 US
gvMsgID: Mitchell.PA $ 3#14@12-Oct-82 16:11:00 PDT
Categories: interscript-t-sep82-dec82
Date: 12 Oct. 1982 4:11 pm PDT (Tuesday)
From: Mitchell.PA
Subject: Re: 31 August Document: BNF page 21
In-reply-to: Your message of 12-Oct-82 14:32:29 PDT (Tuesday)
To: Ayers
cc: Mitchell
After you say
Foo ← { TAG$ < content > 1.0 27 assign ← ment }
you can then invoke Foo in a node and its value will there appear; e.g.,
{Foo <random text> Foo}
is equivalent to
{ { TAG$ < content > 1.0 27 assign ← ment } <random text> { TAG$ < content >
1.0 27 assign ← ment } }
Does this answer your question or raise any more?
Jim M.
*start*
00481 00110 US
gvMsgID: Ayers.PA $ 3#14@12-Oct-82 16:16:27 PDT
Categories: interscript-t-sep82-dec82
Date: 12-Oct-82 16:16:27 PDT (Tuesday)
From: Ayers.PA
Subject: Re: invoke Foo in a node and its value will there appear
In-reply-to: Your message of 12 Oct. 1982 4:11 pm PDT (Tuesday)
To: Mitchell
cc: Ayers
I thought that I did that with
Foo ← "{ TAG$ < content > 1.0 27 assign ← ment }"
rather than with
Foo ← { TAG$ < content > 1.0 27 assign ← ment }
Bob
*start*
00697 00113 US
gvMsgID: Mitchell.PA $ 3#14@13-Oct-82 10:04:00 PDT
Categories: interscript-t-sep82-dec82
Date: 13 Oct. 1982 10:04 am PDT (Wednesday)
From: Mitchell.PA
Subject: Re: invoke Foo in a node and its value will there appear
In-reply-to: Your message of 12-Oct-82 16:16:27 PDT (Tuesday)
To: Ayers
cc: Mitchell
The difference between
Foo ← "{ TAG$ < content > 1.0 27 assign ← ment }"
and
Foo ← { TAG$ < content > 1.0 27 assign ← ment }
is that in the latter, ment is invoked and evaluated in the current context,
whereas in the former, it (and anything else needing evaluation in the node
value) is evaluated in the context extant whenever Foo is invoked.
Jim M.
*start*
00552 00112 US
gvMsgID: Karlton.PA $ 3#14@ 7-Oct-82 12:08:56 PDT
Categories: interscript-t-sep82-dec82
Date: 7-Oct-82 12:08:56 PDT (Thursday)
From: Karlton.PA
Subject: Re: External References in Scripts
In-reply-to: Mitchell's message of 6 Oct. 1982 10:23 am PDT (Wednesday)
To: Mitchell
cc: Lampson, GCurry.ES, Interscript
I am uneasy about the suggestion that we have a special case in which the {}s do not have the semantics of popping the values assigned within that span. Would an invocation (INCLUDE["...."]) be more consistent?
PK
*start*
01089 00110 US
gvMsgID: Ayers.PA $ 3#14@11-Oct-82 14:27:17 PDT
Categories: interscript-t-sep82-dec82
Date: 11-Oct-82 14:27:17 PDT (Monday)
From: Ayers.PA
Subject: Strawman to kick around!
To: deLaBeaujardiere, GCurry.es, McGregor, Mitchell
cc: Interscript
OK, gang, here it is. Yours truly's attempt at defining the "well known" document constructs like TEXT and PARAGRAPH and PAGE -- the "document model".
I claim that the proposal is reasonably "complete" -- you really can create a script for your favorite document -- no "loose ends." On the other hand, you may think that choices that I made are lousy.
It is available as McKinley > PubliC Ayers > I Script Stand'd S4.
I am mailing copies to the "To" list, Star mail to Jean-Marie and Gael, paper mail to Scott and Jim.
How about the five of us get together late this week and talk things over? How about Friday from 10 to 11, with maybe another session after lunch depending?
Direct questions welcome via net or phone; I've stared at it so long that it's hard to tell from here how understandable it all is.
Bob
*start*
00618 00110 US
gvMsgID: Ayers.PA $ 3#14@31-Oct-82 19:26:04 PST
Categories: interscript-t-sep82-dec82
Date: 31-Oct-82 19:26:04 PST (Sunday)
From: Ayers.PA
Subject: On Content as Bindings
To: Mitchell, McGregor
cc: Ayers
As I'm rewriting section four, I notice that when we convert from Paragraph content "width" to a binding to "width", we don't get to take defaults.
The Paragraph that wants a "width" of [0,infinity] (the normal case) has to do a binding, lest it get screwed by some binding nearer the root.
The default binding could be subsumed into the expansion of "Para$", but still its a cost.
Bob
*start*
00504 00113 US
gvMsgID: McGregor.pa $ 3#14@ 1-Nov-82 8:51:37 PST
Categories: interscript-t-sep82-dec82
Date: 1-Nov-82 8:51:37 PST
From: McGregor.pa
Subject: Re: On Content as Bindings
In-reply-to: Ayers' message of 31-Oct-82 19:26:04 PST (Sunday)
To: Ayers.pa
cc: Mitchell
I'm in favor of including defaults to solve you width binding problem in the expansion of Para$. I expect most interscript readers to be clever and efficient when expanding standard abbreviations like Para$.
Scott.
*start*
01837 00113 US
gvMsgID: Mitchell.PA $ 3#14@ 1-Nov-82 9:09:00 PST
Categories: interscript-t-sep82-dec82
Date: 1 Nov. 1982 9:09 am PST (Monday)
From: Mitchell.PA
Subject: Re: On Content as Bindings
In-reply-to: Ayers' message of 31-Oct-82 19:26:04 PST (Sunday)
To: Ayers
cc: Mitchell, McGregor
For the record, I think it is a bad idea to consider the precise position of
unnamed contents as important and to somehow indicate their absence by
omitting one. The only relationship between unnamed contents that is
reasonable is that of immediate sequencing, but not that of absolute position.
In my view of the world, therefore, we never did get to "take defaults" by
omitting a piece of unnamed content. You could get that effect if you put the
width in as content (which I also think unwise) and then invoked something
like default.width at the correct position to cause the default value to appear.
Well, of course, you can perfectly do that if you use a binding for width. You
are no worse off. Placing the width as content also removes it from
considerations of scope because it has no name, but, again, you can get the same
effect with a binding (remembered I promised that named contents are not a
problem). So, again, you are no worse off. It seems to me the two cases are
roughly equivalent on this issue.
Note that a PARA$ node that wants a "width" of [0,infinity] only has to do a
binding if the EDITOR THAT IS EXTERNALIZING the script knows that there is
a binding between it and the root THAT IS DIFFERENT than what it wants for
the given PARA$ node. It can supposedly find this out from its own data
structures during externalization.
Alternatively, the default binding could be subsumed into the expansion of
PARA$ as you suggest, supposedly as something like
"box.horizontal.size←default.size".
Jim M.
*start*
01299 00110 US
gvMsgID: Ayers.PA $ 3#14@31-Oct-82 20:59:10 PST
Categories: interscript-t-sep82-dec82
Date: 31-Oct-82 20:59:10 PST (Sunday)
From: Ayers.PA
Subject: New(er) "Section 4"
To: deLaBeaujardiere, GCurry.es, Mitchell, McGregor
cc: Ayers
I've just sent a draft out to you-all. Paper mail to PARC, Star mail to SDD. It's also available in McKinley > PubliC Ayers.
It is only partly baked, but I wanted to get it out so that Scott could mull things over while he's vacationing in Dallas.
I tried to incorporate all of the action items of our last two meetings, but didn't get to these:
1. Define and allow "stickouts" and sibling overlap.
2. Incorporate outstanding issue list at front of draft
(the typewriter-typeface internal issues are still there)
A new issue: having replaced the "content" values for things like "width" and "sibling-distance" with bindings, there is no effective defaulting. So most any box has to make a whole bunch of uninteresting assignments like
containeeMinimums ← [0,0,0,0]
My plan: I'd like to fix this section up a bit with your inputs, add a few pages of prose, and send it out to Interscript.dl. Think it's baked enough to give the dl a peek?
Bob
PS: It is fairly likely that I'll be in ElSeg this coming Thursday and Friday.
*start*
00878 00115 US
gvMsgID: Johnston.DLOS $ 3#14@16-Feb-82 6:52:00 PST
Categories: interscript-t-sep82-dec82
Date: 16 Feb. 1982 8:52 am CST (Tuesday)
From: Johnston.DLOS
To: Ayers.PA
Subject: Margins & Tabs & Multi-columns
Categories: Save
cc: Mitchell.PA,Horning.PA,Johnston.DLOS
In reading about margins and tabs, I have a question as to whether the handling
of multiple columns is considered in InterDoc, and if so, how? I haven't been
able to read through all the material available yet, but the question about
relative margins posed by Ayers got me to think about our aborted project for
multiple columns on the 860. Our approach there was to define an absolute left
page margin, and then each column carried its own relative margins and tabs,
which allowed columns to be inserted or deleted without any impact on existing
columns. How do you handle this?
Rick
*start*
00431 00113 US
gvMsgID: Mitchell.PA $ 3#14@ 1-Sep-82 17:03:00 PDT
Categories: interscript-t-sep82-dec82
Date: 1 Sept. 1982 5:03 pm PDT (Wednesday)
From: Mitchell.PA
Subject: Phil's forcing function
To: Mitchell
indirections separate issue from tags, but part of safety rules
only assign to assignable attributes (specified for each tag)
each tag must say what the relevant attributes are
[private-only identifiers]
*start*
00755 00110 US
gvMsgID: Ayers.PA $ 3#14@21-Sep-82 11:03:47 PDT
Categories: interscript-t-sep82-dec82
Date: 21-Sep-82 11:03:47 PDT (Tuesday)
From: Ayers.PA
Subject: Interscript "Boxes" and how they Arrange Themselves
To: Mitchell, Horning
cc: Ayers
One of the things that got left out of the "Concepts and Facilities" was a discussion of the layout parameters of the "boxes".
The C&F talked about how the boxes are filled, but did not describe the metrics associated with each box, nor the semantics of those metrics.
You-all (especially JimH?) seemed interested in this last month.
Is the time ripe for a "strawman" proposal on box metrics?
Would it be appropriate for you-all (with my secretarial assistance, perhaps) to generate one?
Bob
*start*
01410 00110 US
gvMsgID: Ayers.PA $ 3#14@29-Sep-82 10:06:02 PDT
Categories: interscript-t-sep82-dec82
Date: 29-Sep-82 10:06:02 PDT (Wednesday)
From: Ayers.PA
Subject: "Untagged Node" Motivation
To: Horning
cc: Interscript
The proposal suggested that we might find a new name (and perhaps a new syntax).
The motivation for a new name:
I'm writing up the standard and I get to a place where I would like to write something like
"A text node may not contain any imbedded nodes"
Since we wish to allow the "untagged node" for push/pop purposes, the "any" in the above really refers only to tagged nodes. So we have to qualify it:
"A text node may not contain any tagged imbedded nodes"
Then, to avoid someone reading the above and thinking that 'contain' means direct containment, I have to further qualify:
A text node may not contain any tagged imbedded nodes at any level"
Now this is awkward enough, but it gets worse when we want to allow an X node to (directly) contain only Y nodes [Y nodes can be children of an X, but Z nodes cannot]:
"An X node may directly contain only Y nodes and untagged nodes.
Untagged nodes directly contained within a X node, or untagged
nodes whose closest tagged ancestor node is an X node, may
contain only untagged nodes or Y nodes."
Most of this horrible verbage will go away if the "untagged node" becomes a non-node.
*start*
04088 00112 US
gvMsgID: Farrell.pa $ 3#14@30-Sep-82 18:51:30 PDT
Categories: interscript-t-sep82-dec82
Date: 30-Sep-82 18:51:30 PDT (Thursday)
From: Farrell.pa
Subject: uppercase / lowercase: what's the difference?
To: SDD-AD↑, @[iris]<Morrison>Styles>StylesInterest.dl, SDD-CUSP↑
cc: Farrell.pa
Reply-To: Farrell.pa
From several angles, it seems to be getting urgent to clarify Star's position on case of letters. The CUSP project is extending its design into the realm of text and properties, and the usefulness of these facilities will be severely restricted if case is not handled in a reasonable fashion. At the same time, Jerry Morrison's Styles design is beginning to grapple with items like setting headers in small caps. I don't know that the Interscript project will be affected, but that seems quite possible. Integration of Star & the Mesa Development Environment looks like another arena. There may be more.
For the sake of recipients of this message who don't want to be involved in this discussion, I will collect the first round of responses & publish them to folks who indicate interest; the rest of you can delete & continue now.
The basic question (from my vantage point) is, what do we say it means to make a letter uppercase or lowercase? Note that the positions I describe here may be implemented in multiple fashions; in particular, saying that upper- and lower-case forms of a letter are in some sense identical doesn't mean they have to have the same caracter code. There seem to be two positions and an ill-defined middle ground; they all have problems.
1) A # a; upper- and lowercase letters are different characters.
Mesa believes this; so does ASCII. Unfortunately, it gives the wrong answer in most interesting cases. The default option for FIND is to ignore case. RP and CUSP currently can't express the option, so they too ignore case. In general, we don't want "ZAP" to sort ahead of "aardvark" in English. As Jean-Marie has argued, if we're going to attend to case at all in a comparison, it should operate at a lower level than characters: "the" < "The" < "this" (accepting for now J-M's contention that lowercase comes first).
2) A = a; case is a property.
I have argued this before; I believe Joe Becker has too, in the Character Code standard. It gives a reasonable model for comparisons that may or may not care; it permits use of an existing Star paradigm in a consistent fashion (for instance, selecting a span of text & raising it to uppercase).
This position causes serious problems for SameAs (you *DON'T* want to clobber everything to be the same case as your model!) It may also get in the way of higher level properties such as Jerry Morrison is trying to work into Styles: Interactions with SmallCaps may be intelligible; AllCaps has serious problems, if you want to recover the original appearance of text when you turn that off. Finally, the user's keyboard actions are going to have to stay the way things are; this leaves a really obnoxious conflict with the way you set other properties -- which is to say, we can't really treat it as a property all the way, because we can't force users to change the way they set case in typing. and do we want text typed after a capital letter to start out upper case?
3) Neither of the above.
It's something like a property, but not quite. A = a, but the distinction between them is not a property. This has two problems: Star likes to talk about the world in terms of objects and their properties; it's ugly (at best) to be introducing new types into the world. Second, this leaves us with the whole specification & education problem. If they're not separate characters, and case isn't a property, what is it? Is it unique in its third state, or are there other aspects of text which also fall in this middle gorund? Does each domain (Cusp, RP, Find, Styles, ...) define it anew from its own viewpoint? Is it it kosher to have one domain (say, Cusp) say "well for our purposes, it's a property" and have another say it's a thing all its own?
*start*
02259 00111 US
gvMsgID: GCurry.es $ 3#14@13-Oct-82 7:29:38 PDT
Categories: interscript-t-sep82-dec82
Date: 13-Oct-82 7:29:38 PDT (Wednesday)
From: GCurry.es
Subject: Re: External References in Scripts
In-reply-to: Mitchell.PA's message of 6 Oct. 1982 10:23 am PDT (Wednesday)
To: Mitchell.PA
cc: Lampson.PA, GCurry, Interscript.PA
Jim,
I like the INCLUDE proposal, but still have some questions about it:
RELATIONSHIP TO ENCODING - Do you view this strictly as an encoding device? Is it fair to replace the invocation with its value without loss of information (i.e., is the name of the file structure?). If the file name is not "official" Interscript structure, but we tend to preserve it by convention, are we relying on the encoding to carry some interchange semantics?
INTERNALIZING A SCRIPT WITH INCLUDES - What happens when we internalize a script and an INCLUDEd name is busy? Can the INCLUDEd name be busy? If it can be shared, there will be a chance that it will not be immediately readable. I am only worried about this when the INCLUDEd name is not accessible because someone else is EDITING it (rather, the value to which it is bound). This seems strange because the (shared) document component is being edited even though the document is not. What happens if the INCLUDEd name cannot be found in the environment?
INCLUDED DOCUMENTS VS. INCLUDED DOCUMENT COMPONENTS - How much structure do we require on the value bound to an INCLUDEd name? Your proposal suggested that the value be a well-formed Interscript. We can talk about scripts being well-formed at layer 1 (meaning they satisfy the syntax and semantic rules, if any) and about them being well-formed at layer 2 (meaning they satisfy additional constraints imposed by that layer of the standard - e.g., every document has exactly one DOCUMENT$ node). How to we ensure that the reduction of a file with INCLUDEs results in a well-formed file? I see two alternatives in the general case: (a) permit the values bound to INCLUDEd names to be well-formed Interscript layer 1 fragments, (b) extend the naming scheme so it not only names a file (containing a well-formed layer 2 script) but also names a component of the document described by that file.
Gael
*start*
03108 00113 US
gvMsgID: Mitchell.PA $ 3#14@ 3-Nov-82 12:36:00 PST
Categories: interscript-t-sep82-dec82
Date: 3 Nov. 1982 12:36 pm PST (Wednesday)
From: Mitchell.PA
Subject: How an editor internalizes a script
To: Interscript.pa
cc: , Mitchell
At a document modelling meeting last Friday, October 29, Bob Ayers, Scott
McGregor, and I worked out the following method by which an editor can
internalize scripts.
A little background will help: You should imagine that a script is completely
"compiled" into an abstract tree form in which bindings, pieces of contents, etc.
are all in the most basic form. Any expressions will have been evaluated, the
marks and links for a node will have been collected, etc. Basically, a node in
the tree will contain a sequence of bindings and unnamed contents. (Of course,
we intend that we will not actually have to build such a tree and will be able to
produce a document from a script "as we go", but this model simplifies thinking
about the problem, just as it does for compilers).
What I want to describe is how an editor then walks around this tree to produce
another structure, which is the script's representation as a document in the
editor's internal format, whatever that may be. Here is the algorithm for a single
node with a single mark that the editor understands:
When the right bracket of the node is reached, use its mark, M, to call the
relevant procedure, ConvertM, for converting the node into the editor's internal
format. ConvertM proceeds to build its data structure (probably one or more
records with fields corresponding to relevant attributes) by asking for the values
of relevant attributes in the context of the node (just inside the right bracket)
and lading its data structures with these values. Note that it is immaterial to this
process whether the relevant attributes are bound locally or in some outer scope;
all that matters is that it is possible to ask for the value of an attribute and get
one (it may be NIL if the attribute is not defined in the scope of this node).
What about the node's contents? Well, those were collected in a list in a
right-to-left fashion as each piece was evaluated. If a piece of content is just a
simple value, this evaluation was simple. If a piece of content is a node, this
evaluation mechanism was applied to it recursively and yielded a handle on the
resulting data structure to be used when building the data structures for this
parent node.
If a node has multiple marks, it is not clear what to do. What if the editor has
more than one conversion routine that might be applicable to the node? E.g.,
suppose the editor can handle mark sets (A), (B), and (B C), and a node has
marks A, B, and C. Which (subset) of ConvertA, ConvertB, or ConvertBC
should it invoke and in what order? I expect that this problem will not arise in
practice because marks will not be combined in random combinations, and
because an editor will be able to place an ordering on mark sets to enable it to
pick a conversion routine, but I am not certain. Your suggestions are welcome.
Jim Mitchell
*start*
02902 00113 US
gvMsgID: Mitchell.PA $ 3#14@16-Nov-82 13:42:00 PST
Categories: interscript-t-sep82-dec82
Date: 16 Nov. 1982 1:42 pm PST (Tuesday)
From: Mitchell.PA
Subject: Interscript meeting with BWL
To: Ayers
cc: Horning, Mitchell
Bob,
I have reserved 13.00-15.00 this Thursday with Butler to talk about Interscript. I
propose that you, Jim Horning, and I get together with Butler to thrash out the
issue of relevant attributes (and their possible declaration) and safety rules for
Interscript-conforming editors. This seems a natural follo-on to our discussion
last Friday morning as well as to the last discussion among Lampson, Horning,
and me. Can you make it?
Attached are some sketchy notes from our last discussion on this topic.
Jim M.
-------------------
Date: 18-Oct-82 17:51:36 PDT
From: Horning.pa
Subject: Board Transcription: Relevant Attributes
To: Mitchell, Lampson
cc: Horning.pa
"How do you know which attributes are relevant to a node whose tag(s) you
don't understand?"
0) The basis for the safety rules is the fact that each node is created by an editor
that understands all its tags. The validity of its invariant will be maintained by
any editor that preserves the values of its contents and all its relevant attributes.
1) In principle, each script must contain "declarations" for all the tags it
contains--although many declarations might be subsumed by a reference to a
certain level of the standard.
PARA = (foo height justified)
2) A tag's declaration may refer to other tags (a form of subclassing).
BAZ = PARA + (x y height)
The interpretation is drawn from the "predicate" view of types: the invariant of
BAZ is implied by the invariant of PARA, except possibly for terms involving (x
y height).
3) Quoted expressions can be tagged to indicate THEIR relevant attributes. We
considered restricting quoted expressions so that no other variables appeared free.
q ← 'PARA$ cont%'
This would restrict
-the use of q% to contexts where the relevant attributes of PARA$ were
suitably bound, and
-the binding of cont in such contexts to expressions in which at most (foo
height justified) were free.
4) The statement of the safety rules will be in terms of analysis of the "free
variables" (either appear explicitly or are relevant to a tag, and are not
bound)--should we perhaps use the term "parameters"?
5) The specifications of tags in the standard will contain more information than
the declarations in scripts: The invariants implied will be stated (formally or
informally), and at least some of the implications will be made explicit (to create
a "free variable logic").
Recap: An edit is safe if it does not result in a node whose invariants cannot be
guaranteed
-because its tags are all understood, or
-because its contents and relevant attributes are all the same as a given
node with those tags.
Jim H.
-------------------
*start*
02514 00110 US
gvMsgID: Ayers.PA $ 3#14@15-Nov-82 11:50:52 PST
Categories: interscript-t-sep82-dec82
Date: 15-Nov-82 11:50:52 PST (Monday)
From: Ayers.PA
Subject: Minutes of Fridays (12nov82) Meeting
To: deLaBeaujardiere, GCurry.es, Mitchell, McGregor
cc: Ayers
1. Mitchell (?) proposed that the "Box" span be separated from the "Para" span. Suggested that this would allow for a repeating box to serve as the container for a sequence of (similar) paragraphs.
2. Scott was against mentioning "widow control" and the like in the verbiage on paragraph layout. He believes that this sort of thing is (purely) an editor function.
This got us off into discussing Tioga "glue" and that got us
(somehow) discussing bindings ...
3. Mitchell (the 'owner' of the language) asserts that bindings can be distributed by an editor, and that this is not an alteration of (the content of) a script. E.g. an editor can accept a script
{ PARA$ font.points ← 12 { TEXT$ <foo> } { TEXT$ < goo> } ... }
and emit the script
{ PARA$ { TEXT$ font.points ← 12 <foo> } { TEXT$ font.points ← 12 < goo> } ... }
and it hasn't done anything wrong.
After much (sometimes loud, sorry about that) discussion, we noted that an editor that wished to not allow the above rearrangement could alter the original script to
{ PARA$ temp ← 'font.points ← 12' temp% { TEXT$ <foo> } { TEXT$ < goo> } ... }
Some of the attendees felt that the usage where the binding cannot be moved is really the editing world's normal case. If so, we should revisit and maybe put some sugar on the latter example.
5. Getting back to Scott and Tioga 'glue', we took up his suggestion that he (Tioga) be allowed to simply mention the 'glue' via a binding, and NOT warn anyone by retagging the PARA$ as also a TIOGAPARA$.
But this conflicts with Horning's rules about an editor moving/copying a span. If it does not know all about the movee, it must test whether "all the relevent attributes are the same in the target location". This makes it very useful to easily acertain what the relevent attributes are.
We noted that there are three flavors of binding <=> node connection
1. Binding is totally irrelevent.
2. Binding is relevent, but NOT an invarient on the content.
3. Binding is an invarient on content: changing content may invalidate binding.
We suggested (but did not bake) that we might add, to the syntax, an arrangement that allowed one to call out the flavor #2 and #3 bindings for any node-tag.
Bob
*start*
00818 00112 US
gvMsgID: Lampson.PA $ 3#14@20-Oct-82 19:19:00 PDT
Categories: interscript-t-sep82-dec82
Date: 20 Oct. 1982 10:19 pm EDT (Wednesday)
From: Lampson.PA
Subject: Re: Board Transcription: Relevant Attributes
In-reply-to: Horning's message of 18-Oct-82 17:51:36 PDT
To: Horning
cc: Mitchell, Lampson
2) "Declarations" could be optional in their absence the ability to edit a node
containing anything not understood is severely limited.
3) I sort of believe that this treatment of quoted expressions is adequate. However,
I think you have gone beyond what we thrashed out. Would you care to give a
more detailed explanation of why this scheme works.
4) I am opposed (I think) to calling free variables parameters. Things are
confused enough already in this non-lambda-calculus language.
Butler
*start*
01117 00113 US
gvMsgID: Mitchell.PA $ 3#14@23-Nov-82 14:59:00 PST
Categories: interscript-t-sep82-dec82
Date: 23 Nov. 1982 2:59 pm PST (Tuesday)
From: Mitchell.PA
Subject: Interscript semantics meeting - Thursday, Nov. 18/82
To: Horning, Lampson
cc: Ayers, Mitchell
Here is a summary from my whiteboard of what we talked about last Thursday.
The following aspects of the language do not affect the "structure" of a script:
the order of the tags in a span
abbreviations (invocations not in the RHS of a binding)
the order of target links in a span
scope of bindings (this was what took most of the time to decide)
The following semantic constructs do contribute to the structure of a script:
Spans {}
LINKS ↑
Tags $
Order of contents
Bindings
--------------------------------------------------------------------------
variables appearing on the RHS of bindings (all have an implicit %
attached)
indirections %
Structural indirections (the things below the dashed line) are the only
structure-contributing constructs that are not reflected in the surrent semantics
(and need to be).
Jim M.
*start*
01183 00113 US
gvMsgID: Subhana.PA $ 3#198@ 7-Dec-82 11:36:54 PST
Categories: interscript-t-sep82-dec82
Date: 7 Dec. 1982 11:37 am PST (Tuesday)
From: Subhana.PA
Subject: What Interscript requires in an editor's data structures (11/24/82)
To: Mitchell
cc: Subhana
Script Parse---Decorated--Document
Normalized
Trees
←
NODAL STRUCTURE
- marks
- target links
- mark-specific representation for attributes
- list of contents
- list of indirections to check if reevaluation is necessary (includes both
bindings and indirections) [play the thesis game]
: do any indirections need to be evaluated?
If so, evaluate in each context [=node,pg]s'n where it occurs in this
node.
[if there's a selection on any of the contents derived from an indirection, what
should be done?]
Type of contents
rope, integer, real, atom, Boolean, node, indirection, binding with
indirection (could do all bindings this way except that most don't change
indirectly after internalization)
An indirection:
- expression
- ref to node containing it
What about indirections that are supposed to affect a set of nodes?
e.g. {. . .a%{}{}. . .}
--Jim Mitchell
*start*
03253 00113 US
gvMsgID: gcurry.es $ 60#161@ 9-Dec-82 10:51:31 PST
Categories: interscript-t-sep82-dec82
Date: 9-Dec-82 10:51:42 PST (Thursday)
From: gcurry.es
Subject: Some Comments on the 8/31 Interscript Document
To: Mitchell.pa
cc: , gcurry.es
Jim,
I have been looking at Interscript as a description language for property sheets in a user-interface protocol, and have built a little parser, but in so doing read the August document more carefully than previously. This message points out candidates for typos and places where I had difficulty.
TYPOS
p21. reference to Appendix D should be to C instead.
p29. The delimiter rules at the top of the page exclude the empty delimiter following identifiers if the next char is "-" and for integers if the next char is "F" and "-". Are these particular exclusions necessary?
p29. are brackets really tokens, or simply characters which are used to form string literal tokens
p29. According to the definition given, illegal tokens which start with uc chars and contain lc chars can be constructed. A rule which allows universals to end with empty delimiters when the next char was a lc char would eliminate the possibility (with some cost in readability?).
p29. There seems to be an extra quote at the end of the "bracket" production, and the "=" token should probably be ":=".
DIFFICULTIES
I was trying to use the reference encoding.
I was trying to do a recursive descent parser without backup, and using lookahead for a small number of TOKENS (like 2). I wanted to separate the syntactic processing from the semantic processing in order to make it easy to write other kinds of Interscript applications (like my property sheet application, or a formatter). I wanted to use recursive descent in order to permit semantic processing to control the amount of work done at lower levels, esp the scanner:
1. for certain applications, there is no need to calculate internal forms of literals (multiplication for integers etc is slow on the DLion).
2. applications which don't "understand" a particular node, perhaps should be able to scan over it without resolving all the tokens in the node.
I also wanted to use recursive descent in order to be able to use the stack for context storage.
I had problems in two places:
1. distinguishing between selections and vectors, since both can start
( term, and
2. with "name"s in general, since they were multi-token objects as presented.
In order to workaround the first, I took the liberty of changing the syntax of
vectors FROM (...) TO <...> AND strings FROM <...> to "...". This was just a quick and dirty change on my part; there might be good reasons for not doing this.
In order to workaround the second, I pushed the "name" non-terminal into the scanner to make it a token (even though that might not be good from the point of view of processing name semantics).
I am not sure that these were necessary, but it does seem like a good idea to ensure that Interscript can be processed left-to-right, without backup, by a recursive descent parser with small number of token lookahead.
Comments?
Gael
I'm in PA today, and will probably be in building 33 to talk with Doug Brotz later today if you want to talk about this.
*start*
01200 00114 US
gvMsgID: mitchell.pa $ 3#171@ 8-Dec-82 10:55:33 PST
Categories: interscript-t-sep82-dec82
Date: 8-Dec-82 10:55:52 PST
From: mitchell.pa
Subject: What Interscript requires in an editor's data structures (11/24/82)
To: Mitchell
Parse Alpha
Script -----> Decorated -----> Document
Normalized
Trees
NODAL STRUCTURE
- marks
- target links
- mark-specific representation for attributes
- list of contents
- list of indirections to check if reevaluation is necessary (includes both
bindings and indirections) [play the thesis game]
Alpha:
do any indirections need to be evaluated?
If so, evaluate in each context ( =[node,position]) where it occurs in this
node.
[editor question: if there's a selection on any of the contents derived from an indirection, what
should be done?]
Type of contents
rope, integer, real, atom, Boolean, node, indirection, binding with
indirection (could do all bindings this way except that most don't change
indirectly after internalization)
An indirection:
- expression
- ref to node containing it
What about indirections that are supposed to affect a set of nodes?
e.g. {. . .a%{}{}. . .}
--Jim Mitchell
*start*
02871 00113 US
gvMsgID: Subhana.PA $ 3#198@ 7-Dec-82 11:14:21 PST
Categories: interscript-t-sep82-dec82
Date: 7 Dec. 1982 11:14 am PST (Tuesday)
Sender: Subhana.PA
Subject: Reversing my field (or) The medium and the message
From: Horning
To: Mitchell
cc: Horning, Subhana
I've been reflecting on our difficulty in sorting out what is "content" and
what is "attribute." I've come to the somewhat surprising conclusion that the
best (perhaps the only) principle for sorting them out is to look at the script,
NOT the standard.
The distinguishing property of attributes is that they distribute over
content (within their scope, to which they are relevant). I now believe that it is
ONLY this non-local binding, and not any "semantic" property, that
distinguishes them. [Consider the Juniper tree poem, whose margin is certainly
content, and a page in a font sampler, whose content is the family name--
everything else being inherited.]
Thus, my current position is that every tag defines a set of relevant
attributes, some of which will be extracted (in any particular case) from content
and others from the environment. Interscript must define the semantics of
attribute distribution uniformly, so that particular scripts (or nodes within
scripts) may treat the same attribute differently.
There seem to be three reasonable ways to associate content with an
attribute
- by name margin←10
- by type <text> {Boundary $ . . . }
- by position {Cartesian$ 7.0 9.25},
but only one for extracting an attribute from the environment (name). Also, it
seems that a content value should always override an environment value, if
present--else why include it in the content?
Thus, each tag's definition is similar to a record definition: an ordered
collection of name, type (type=primitive type | tag | union | list) pairs. A node
is evaluated by converting its explicit content into further bindings (using type
and order within type to discriminate) and then completing the record value by
looking up all unbound "relevant," i.e., in the definition, attributes in the
containing environment.
Note that distributing an attribute binding to all of the nodes in its scope
to which it is relevant is a value-preserving but structure-losing operation.
The (uniform) equivalent for Look? is to evaluate the non-manifest
attributes of the node, and present the list of bindings as text. This would also
be a simple editing interface, although low-capability editors may have
difficulty checking the invariants, or rendering the result, except as a binding
list.
In the environment
{x0←0 y0←1 x1←10 y1←20 = caption←<Hi>. . .
if the relevant attributes of Box$ are
x0,x1,y0,y1: Integer; caption: Text
then all of the following nodes evaluate to the same result
{Box$ 0 1 10 20 <Hi>}
{Box$}
{Box$ <Hi> 0 1}
{Box$ y1←20}
--Jim Horning
*start*
00685 00113 US
gvMsgID: Horning.pa $ 3#203@17-Dec-82 16:55:52 PST
Categories: interscript-t-sep82-dec82
Date: 17-Dec-82 16:55:56 PST
From: Horning.pa
Subject: Re: Indirection semantics, canonical form, and names of relevant attributes
In-reply-to: mitchell's message of 15-Dec-82 17:04:40 PST
To: mitchell.pa
cc: Horning, Lampson
Jim,
That seems to capture the essence. I trust that we will be able to reconstruct the detail next time it is needed.
One slight caveat: your notes suggest that they deal only with bindings where the RHS is quoted. I believe that the same principles cover non-quoted RHSs (i.e., that indirection and quoting are orthogonal issues).
Jim H.
*start*
07797 00113 US
gvMsgID: Mitchell.PA $ 3#14@15-Feb-82 18:04:00 PST
Categories: interscript-t-sep82-dec82
Date: 15 Feb. 1982 6:04 pm PST (Monday)
From: Mitchell.PA
To: Interdoc.PA
Subject: First cut at defining some marks and attributes
Categories: Save
The following is my first try at an answer to that age-old question, "What is a
paragraph?" It is only half, not fully baked, but it might be a reasonable place
to begin. Your comments and questions are earnestly solicited.
Jim M.
------------------------------------------------------------------------
Conventions used:
<<material in brackets like these are comments or questions>>
Example: <<the term record is used to describe a value which is an environment with Outer=NIL>>
------------------------------------------------------------------------
Primitive nodes:
A string value <sequence of characters> is syntactic sugar for a node of the form
{CHAR$ c0 c1 ... cN}
where the ith character (i in [0..N]) of the original string constant has been
mapped into a number, ci.
Examples: <abcdefg> is the same as {CHAR$ 97 98 99 100 101 102 103}
------------------------------------------------------------------------
Text nodes:
Mark: TEXT
Contents: the evaluated contents of a TEXT node can only be a sequence of
strings of text (or, equivalently, a sequence of CHAR nodes). It cannot contain
any other kind of nested subnodes.
Examples: {TEXT$ <Now is the time for ... party!>}
{TEXT$ <Now ><is ><the ><time ><for ><... ><party><!>}
------------------------------------------------------------------------
Margins:
Margins are represented by values all with the following common structure:
margins = [ | left←0.0 right←0.0 relative←F]
If relative=T, this means the margins are to be interpreted relative to margins at
outer levels. Non-negative values indicate offsets to the right, and negative
values indicate offsets to the left. <<this bothers me in that it seems that it
introduces a level of semantics that every implementation must support, but
which is above the base language.>><< if relative is not present in a margins
record (environment), its value is the atom "relative", which should be treated as
F>> This is used in the following definition for a paragraph.
------------------------------------------------------------------------
Mark: PARAGRAPH
Contents: The contents of a PARAGRAPH node can be a mixed sequence of text
strings and arbitrary subnodes. If a PARAGRAPH node is also marked as TEXT,
then its evaluated contents must comprise a sequence of strings of text.
Relevant Attributes and Constraints:
margins = [ | left←0.0 right←0.0 relative←T first←0.0] -- distance
Margins for a paragraph are relative to the margins current in the environment
of a node with the mark PARAGRAPH$. "Left" specifies how much the left
margin of the paragraph is offset relative to the current left margin; "right"
specifies how much the right margin is offset relative to the current right
margin; and "first" specifies how much the first line of a paragraph is offset
relative to the current left margin.
The values are all distances in the standard Interdoc units.
Note: left, right, and first are independent of each other.
align = [ | horizontal←FlushLeft -- IN (FlushLeft Centered FlushRight)
justified←F -- Boolean
vertical←FlushTop] -- IN (FlushBottom Centered FlushTop)
"Align" specifies how a paragraph is aligned in some frame and has three
components, "horizontal", "justified", and "vertical".
The horizontal component specifies whether the paragraph is FlushLeft: the text
of the paragraph is to be displayed aligned against the left or first margin, as
appropriate; FlushRight: the text of the paragraph is to be displayed aligned
against the indented right margin; or Centered: each line of text should be
centered between the paragraph's left and right indented margins.
The "justified" component acts as a modifier for the horizontal component. A
paragraph for which align.justified=T specifies that its text is to be displayed
aligned against its left or first and right margins. If align.justified=F, then the
right (left) edge of a FlushLeft (FlushRight) paragraph will be displayed
raggedly.
The vertical component specifies whether the paragraph is FlushTop: the text of
the paragraph is to be displayed aligned against the top margin of its enclosing
frame (if any); FlushBottom: the text of the paragraph is to be displayed aligned
against the bottom of its enclosing frame; or Centered: the body of the paragraph
should be centered between its enclosing frame's top and bottom margins.
<<might use something like (-1, 0, 1) in place of (FlushLeft Centered FlushRight)
and (FlushBottom Centered FlushTop)>>
------------------------------------------------------------------------
spacing = [ | top←12*pt
between←3*pt
bottom←0*pt]
"Spacing" specifies how much white space is to be used when displaying a
paragraph.
Spacing.top is the amount of space that is to appear before the first line of text of
the paragraph.
Spacing.between is the number of spaces between lines of the paragraph. It is
applicable to internal spaces only (i.e., it is not added to spacing.top to determine
the total top space before the paragraph, nor to spacing.bottom to give the total
space following the last line of the paragraph). It is independent of the size(s)
of font(s) used for text in the paragraph.
Spacing.bottom is the amount of space that is to appear below the last displayed
line of text of the paragraph.
------------------------------------------------------------------------
hyphenate←F
This attribute specifies whether <<and how?>> words in the text of the paragraph
are to be hyphenated. Notice that this is properly an attribute of the paragraph
and not of the text in it.
------------------------------------------------------------------------
tab = [ |
position←0
alignment←FlushLeft -- IN (FlushLeft Centered FlushRight
Decimal)
]
A tab is a record containing a position for the tab and a tab alignment. The
position is a distance relative to the paragraph's left margin. The alignment
specifies how the tabbed text, i.e., the text affected by the tab, is to be placed.
The tabbed text consists of the paragraph contents up to but not including the
end of the paragraph, another tab character, or a newline character, whichever
occurs first.
The definitions of the alignment values are
FlushLeft: the tabbed text will be left justified at the tab's position;
Centered: the tabbed text will be centered about the tab's position;
FlushRight: the tabbed text will have the right edge of its rightmost character
at the tab's position; or
Decimal: the tabbed text, which may contain zero or more decimal points, is
placed so that the left edge of the leftmost decimal point following a
numeric character in the tabbed text is at the tab's position. If there is no
such decimal point in the tabbed text, the text is positioned as if a decimal
point followed its last numeric character. If there are no numeric characters
in it, the tabbed text is positioned as if Centered had been specified.
A paragraph has a "tabs" attribute to describe the tab values associated with it.
This value is a sequence of tab records.
------------------------------------------------------------------------
Examples:
{PARAGRAPH$ TEXT$ align ← [| horizontal←FlushLeft]
margins ← [| left←inch right←inch]
<Now ><is ><the ><time ><for ><... ><party><!>
}
------------------------------------------------------------------------
*start*
02895 00113 US
gvMsgID: Mitchell.PA $ 3#14@25-Feb-82 15:55:00 PST
Categories: interscript-t-sep82-dec82
Date: 25 Feb. 1982 3:55 pm PST (Thursday)
From: Mitchell.PA
To: Horning.PA,Guttag.PA,Donahue.PA
Subject: How to present the Interdoc transcription semantics - Version 1.0
Categories: Save
cc: Mitchell.PA
Here are the contents of my whiteboard after today's meeting, with extra
comments thrown in as my memory dictates and as my stamina allows tonight:
Literals
Boolean: T, F
string: <A sequence of ascii characters in angle brackets>
integer: ..., -3,-2,-1,0,1,2,3,...
hex integer: AA AB AC ... BA BB ... PN PO PP
real
{ literal }
the simplest documents, e.g.,
{} -- an empty document
{NIL} -- also an empty document
{<>} -- the empty string=NIL, so this is also empty
{<This is the sole content of this document>}
{TRUE}
{ literal* }
contents in left-to-right order, e.g.,
{<This> < is > <the> < sole > <content> < of> < this> < document>}
{<This> < is > <the> < sole > <content> NIL <of> < this> < document> NIL}
-- NILs disappear
{TRUE TRUE TRUE}
{2.7 3.2 7.5} -- a coordinate sequence, perhaps
{ (literal | node)* }
nested nodes are used to represent the dominant hierarchical structure in
a document, e.g.,
{
{<This>}
{< is >}
{<the> < sole > <content>}
{< of>
{< this> < document>}
}
}
Marks
means of attaching one or more properties to a node
marks provide a node's "aspects", e.g.,
{$Sentence
{$Subject $Pronoun <This>}
{$Verb < is >}
{$Object $NounPhrase <the> < sole > <content>
{$AdjectivalPhrase < of> < this> < document>}
}
}
{$Cartesian 2.7 3.2 7.5} -- a coordinate sequence
Nodes and links
a means of denoting associations among nodes other than those implied by
the dominant hierarchy
introduce Contents,Links,Marks,Sources,Targets functions
Examples:
{$Sentence theSubject@! theObject@!
{$Subject $Pronoun <This> theSubject@}
{$Verb theSubject! < is > theObject!}
{$Object $NounPhrase <the> < sole > <content> theObject@
{$AdjectivalPhrase < of> < this> < document>}
}
}
Variables in the global environment and nodes with variable invocations
there is a global, pre-existing environment with certain names defined;
these variables can be named in the script to obtain their values as
contents
Examples:
{ ... <Signed this > DATE < in the county of ...> ... }
Simple bindings in the global environment (e.g., LeftMargin := 10)
Declared VARs at the root node only
Nested environments and VARs
introduce identifier lookup rule
introduce R, B
Decorated tree as the semantic model
Local bindings and const
Simple expressions: + * /
Conditionals
Environments as values
qualified names, e.g., a.b ← foo
invocation
Quoted expressions
invocation
Node values
Function application
built-in functions: LT, EQ, ...
*start*
01243 00113 US
gvMsgID: Mitchell.PA $ 3#14@14-May-82 14:58:00 PDT
Categories: interscript-t-sep82-dec82
Date: 14 May 1982 2:58 pm PDT (Friday)
From: Mitchell.PA
To: Horning.PA
Subject: semantics of Interscript without environments
Categories: Save
cc: Mitchell.PA
Here are the contents of my whiteboard. Comments and questions follow them.
-------------------
X: (reduced) exp -- context
RR: x * e -> (reduced) exp -- with node structure
R: x * e -> (reduced) exp
L: x * id -> exp -- the Lookup function
C(R(x,e)) projects to contents
Lab(R(x,e)) projects to labels
RR(x, e) = append(x, R(x, e))
RR({item*}, e) = { item* R({item*}, e) }
R(x, Nil) = Nil
R(x, item item*) = R(RR(x, item), item*)
R(x, label) = label
R(x, "'" item "'") = item
R(x, {item*}) = {R(x, item*)}
R(x, id "←" rhs) = id←R(x, rhs)
R(x, id.name "←" rhs) = id←{inner(id%) name←R(x, rhs)}
R(x, literal) = literal
R(x, id) = R(x, L(x, id))
R(x, name "%") = name%
L(Nil, id) = Universal(id)
L({item* id' "←" rhs}, id) = IF id=id' THEN rhs ELSE L({item*}, id) -- eval ids!!
L({item* nonbindingItem}, id) = L({item*}, id)
L(x, id.name) = L(L(x, id), name)
L({item* name' "%"}, name) = L({item* R(item*, name')}, name)
C, Lab similarly
-------------------
*start*
01410 00112 US
gvMsgID: Horning.PA $ 3#14@14-May-82 17:40:56 PDT
Categories: interscript-t-sep82-dec82
Date: 14-May-82 17:40:56 PDT
From: Horning.PA
To: Mitchell.PA
Subject: Re: semantics of Interscript without environments
Categories: Save
cc: Horning.PA
I think that we want to call R and L something else; maybe Normalize and Value?
We can drop the curlies around a context.
There is no consistency in quoting terminals.
X: (normalized) exp -- context
NC: x, e -> (reduced) item* -- the Normalization into context function
N: x, e -> (reduced) exp -- the Normalization function
V: x, id -> exp -- the Lookup function
C(N(x, e)) projects to contents
L(N(x, e)) projects to labels
NC(item*, e) = item* N(item*, e)
N(x, Nil) = Nil
N(x, item item*) = N(NC(x, item), item*)
N(x, label) = label
N(x, {item*}) = {N(x, item*)}
N(x, id "←" e) = id "←" N(x, e)
N(x, id "←" "'" item* "'") = id "←" item*
N(x, id.name "←" rhs) = id "←" {inner(id "%") N(x, name "←" rhs)}
N(x, literal) = literal
N(x, id) = N(x, V(x, id))
N(x, name "%") = name "%"
V(Nil, id) = Universal(id)
V(item* id' "←" rhs, id) = IF id=id' THEN rhs ELSE V(item*, id) -- eval ids!!
V(item* {, id) = V(item*, id) -- here's where we go to the containing scope
V(item* nonbindingItem, id) = V(item*, id)
V(x, e.id) = V(V(x, e), id)
V(item* name' "%", name) = V(item* N(item*, name'), name)
C, L similarly
*start*
03861 00112 US
gvMsgID: Horning.pa $ 3#14@ 8-Jul-82 16:04:00 PDT
Categories: interscript-t-sep82-dec82
Date: 8 July 1982 4:04 pm PDT (Thursday)
From: Horning.pa
Subject: Generalized Boxes, Boundaries, and Spaces
To: Interdoc
This is to record the outline of some tentative conclusions that Jim Mitchell and I
reached in a discussion of Generalized Boxes this afternoon, triggered by concern
about whether Interscript could handle both Tioga's and Star's treatment of
paragraph top and bottom leading.
First, we convinced ourselves that the problem is real, and cannot simply be
legislated out of existence by deciding that one or the other is wrong. We
concluded this after enumerating a number of other similar phenomena that will
have to be dealt with, too [see below].
We also concluded that it is not reasonable to expect two editors with arbitrarily
different geometric models to exchange scripts so that each would render
precisely according to the other's model. Rather, the standard should identify a
small set of "standard layout attributes" for cross-editor renderings. Each editor
should provide definitions for these properties (or at least, for acceptable
approximations) in terms of the values of attributes in which it traffics;
conversely, each editor should be prepared to translate any incoming standard
layout attributes into acceptable approximations in terms of the attributes it uses.
(Of course, it would be nice if compatible families of editors actually trafficked
in standard attributes, but that is a probably an insuperable political problem--as
Tony Hoare says, you can only realistically standardize when the choice doesn't
matter.)
Next, we tried to group the two kinds of behavior, to see whether we could
abstract any general principles. Do not put too much weight on the particular
terms used; they are nonce identifiers.
BOUNDARIES - around SPACES - between
----------------------- ------------------
Page margins Character spacing
Columns (relative to margins)
(graphics) Frames Line leading
Paragraph margins Tioga paragraph leading
Paragraph indents (top and bottom)
Star paragraph leading Star paragraph leading
(relative to other paras) (relative to page margins)
Tabs
Both refer to geometric properties of the layout, and ensure a certain amount of
white space. The distinguishing characteristic seems to be that the white spaces
in the first column may not overlap (and hence are additive), while those in the
second column can (and hence maximize). For example, character spacing is
there because the "last" space on a line can overlap into the paragraph, column,
and page margins.
Most often, items in both columns will be specified by dimensions relating them
to other boundaries (containing and/or contained). We have been using the term
"offset" for a dimension in the first column, and "separation" for one in the
second.
Of course, not everything can be specified independently. Some thought needs to
be given to
Defaulting unspecified dimensions.
Deriving implicit dimensions from explicit dimensions and geometrical
constraints.
E.g., A pair of boundary lines may be related by up to two offsets and two
separations (one of each from each). The minimum distance allowed between
them is
MAX(offset[1]+offset[2], separation[1], separation[2])
Consider the following example: a paragraph style has top and bottom offsets of
15 points, and separations of 20 points.
Two consecutive paragraphs on a page are separated by at least 30 points.
At the top of a page, a new paragraph is 15 points down from the page margin.
Within a bordered frame with 0 offset and separation, a new paragraph is 20
points down.
More thought is needed. This is sent now partly to transcribe my whiteboard,
and partly to get you all thinking about these issues.
Jim H.
*start*
01799 00112 US
gvMsgID: Horning.pa $ 3#14@30-Sep-82 18:27:00 PDT
Categories: interscript-t-sep82-dec82
Date: 30 Sept. 1982 6:27 pm PDT (Thursday)
From: Horning.pa
Subject: Re: semantics of Interscript without environments
To: Mitchell
cc: Horning.PA
Queries:
-item vs. exp
X = item* -- context (normalized)
item -- as per grammar
id -- as per grammar
N: X, item -> item -- Normalization of item
NL: X, item* -> item* -- Normalization of item list
V: X, id -> item -- Value lookup
C: item -> item | Nil -- Project onto content, if present
CL: item* -> item* -- Project onto contents
NC: X, item* -> item* -- Normalized contents
L: item -> item | Nil -- Project onto label, if present
LL: item* -> item* -- Project onto labels
NL: X, item* -> item* -- Normalized labels
N(x, literal) = literal
N(x, id) = N(x, V(x, id))
N(x, label) = label
N(x, "{" item* "}" ) = "{" NL(x, item*) "}"
N(x, name "%") = name "%"
N(x, id "←" e) = id "←" N(x, e)
N(x, id "←'" item* "'") = id "←" item* --?? bracket item* ??
N(x, id.name "←" rhs) = id "←{" inner(x, id "%" ) N(x, name "←" rhs) "}"
where inner = ???
NL(x, Nil) = Nil
NL(x, item item*) = NL(x N(x, item), item*)
V(Nil, id) = Universal(id)
V(item* id' "←" rhs, id) = IF id=id' THEN rhs ELSE V(item*, id)
V(item* "{" , id) = V(item*, id) -- here's where we go to the containing scope
V(item* nonbindingItem, id) = V(item*, id)
V(x, e.id) = V(V(x, e), id)
V(item* name' "%", name) = V(item* N(item*, name'), name)
-- follow indirections for value lookup
C(content) = content
C(label) = Nil
C(binding) = Nil
CL(Nil) = Nil
CL(item item*) = C(item) CL(item*)
NC(x, e) = CL(N(x, e))
L(label) = label
L(content) = Nil
L(binding) = Nil
LL(Nil) = Nil
LL(item item*) = L(item) LL(item*)
NL(x, e) = LL(N(x, e))
*start*
01701 00113 US
gvMsgID: Mitchell.PA $ 3#14@15-Oct-82 13:58:00 PDT
Categories: interscript-t-sep82-dec82
Date: 15 Oct. 1982 1:58 pm PDT (Friday)
From: Mitchell.PA
Subject: Boxes, paragraphs, and lines
To: Mitchell
default.size := [ | min←0, max←infinity]
default.interval := [ | preSp←0 size←default.size postSp←0]
default.vec := [ | rho←0 theta←0]
unitVec := [default.vec | rho←1 ]
unitDown := [unitVec | theta←270]
default.coordRotation := 0*degree
default.positions := [ | n←0*meter e←NIL s←NIL w←0*meter]
box := [ | horizontal ← default.interval
vertical←default.interval
layoutProceeds←unitDown
coordRotation←default.coordRotation
positioning←default.positions]
USpage := [box| horizontal ←
[default.interval |
size←[default.size | min←8.5*inch max←min]]
vertical ← [default.interval |
size←[default.size | min←11*inch max←min]]
]
BravoParaBox := [box| vertical ← [default.interval | preSp←18*pt]]
BravoLineBox := [box| vertical ← [default.interval |
preSp←12*pt size←[ | min←10*pt max←min]]
]
TiogaLineBox := [BravoLineBox| vertical.preSp←0]
-- now do this using BOX$, REPEATS$, and BREAKS$
{BOX$ box←box}
{BOX$ box←BravoParaBox {BOX$ box←BravoLineBox REPEATS$}
Ayers' model (slightly transformed):
default.positioning := [ | fromSiblings ← (0 0 0 0) fromContainer ← (0 0 0 0)
locations ← (0 0 0 0)]
{BOX$
area←[ | height←default.size width←default.size]
positioning←default.positioning
layoutProceeds←unitDown
*start*
02101 00110 US
gvMsgID: Ayers.PA $ 3#14@16-Oct-82 13:36:56 PDT
Categories: interscript-t-sep82-dec82
Date: 16-Oct-82 13:36:56 PDT (Saturday)
From: Ayers.PA
Subject: Interscript Design Review Meeting of 15 Oct 82: Notes
To: deLaBeaujardiere, GCurry.es, Mitchell, McGregor
cc: Ayers
Thanks for your fruitful participation. Here are my notes on the "issues" and "difficulties" and action items.
Issues
Are boxes appropriate for layout.
Yes.
If so, how fine grain? Is the "line" a reasonable stop?
Line box is ok (some reservations). We should NOT go finer-grain than lines.
Can we perturb Star.
Yes, but probably can't transform it. Need to be up-front with Star folk.
Important to capture user intent.
We agreed.
Difficulties
Assignment inside a target (line) box [e.g. to alter font-on-first-line].
Arrangement as described is bogus. We will go with a binding to "FontFiddle".
Coloring LINK usage.
Alter language to allow a source or target to be a rhs to an assignment
or named content.
Where is "language" property attached.
Anywhere, via binding of "Language". [a "paragraph's language" is the
binding upon entry to pargraph; a "word's language" is the binding in
effect at its characters].
Clipping at container edge.
1. We should allow stick-outs to be defined, e.g. via negative margins.
2. Stick-outs don't clip.
Overlap of siblings.
1. Overlap ok, if specified via box layout.
2. Z-plane via depth-first box-tree traversal.
3. Boxes may be "opaque" or not.
[This still needs work]
PFCs [we didn't discuss]
Action Items:
I will publish these notes,
I will alter "section 4" of the standard and re-distribute, hopefully
early next week.
Will include an attached "outstanding issue" list.
Will include more illustration of box's "container" and "sibling" margins.
Will fix up content (named, not positional).
Will fix up "NIL" content values.
[I have a meeting from noon Mon thru Wed afternoon (!); this may not get out
'til late in the week;]
Jim M says "There will be named content and we'll work it out"
Bob
*start*
02209 00112 US
gvMsgID: Horning.pa $ 3#14@18-Oct-82 17:51:36 PDT
Categories: interscript-t-sep82-dec82
Date: 18-Oct-82 17:51:36 PDT
From: Horning.pa
Subject: Board Transcription: Relevant Attributes
To: Mitchell, Lampson
cc: Horning.pa
"How do you know which attributes are relevant to a node whose tag(s) you don't understand?"
0) The basis for the safety rules is the fact that each node is created by an editor that understands all its tags. The validity of its invariant will be maintained by any editor that preserves the values of its contents and all its relevant attributes.
1) In principle, each script must contain "declarations" for all the tags it contains--although many declarations might be subsumed by a reference to a certain level of the standard.
PARA = (foo height justified)
2) A tag's declaration may refer to other tags (a form of subclassing).
BAZ = PARA + (x y height)
The interpretation is drawn from the "predicate" view of types: the invariant of BAZ is implied by the invariant of PARA, except possibly for terms involving (x y height).
3) Quoted expressions can be tagged to indicate THEIR relevant attributes. We considered restricting quoted expressions so that no other variables appeared free.
q ← 'PARA$ cont%'
This would restrict
-the use of q% to contexts where the relevant attributes of PARA$ were suitably bound, and
-the binding of cont in such contexts to expressions in which at most (foo height justified) were free.
4) The statement of the safety rules will be in terms of analysis of the "free variables" (either appear explicitly or are relevant to a tag, and are not bound)--should we perhaps use the term "parameters"?
5) The specifications of tags in the standard will contain more information than the declarations in scripts: The invariants implied will be stated (formally or informally), and at least some of the implications will be made explicit (to create a "free variable logic").
Recap: An edit is safe if it does not result in a node whose invariants cannot be guaranteed
-because its tags are all understood, or
-because its contents and relevant attributes are all the same as a given node with those tags.
Jim H.
*start*
00818 00112 US
gvMsgID: Lampson.PA $ 3#14@20-Oct-82 19:19:00 PDT
Categories: interscript-t-sep82-dec82
Date: 20 Oct. 1982 10:19 pm EDT (Wednesday)
From: Lampson.PA
Subject: Re: Board Transcription: Relevant Attributes
In-reply-to: Horning's message of 18-Oct-82 17:51:36 PDT
To: Horning
cc: Mitchell, Lampson
2) "Declarations" could be optional in their absence the ability to edit a node
containing anything not understood is severely limited.
3) I sort of believe that this treatment of quoted expressions is adequate. However,
I think you have gone beyond what we thrashed out. Would you care to give a
more detailed explanation of why this scheme works.
4) I am opposed (I think) to calling free variables parameters. Things are
confused enough already in this non-lambda-calculus language.
Butler
*start*
04507 00111 US
gvMsgID: Ayers.PA $ 60#91@ 4-Jan-83 14:41:57 PST
Categories: interscript-t-sep82-dec82
Date: 4-Jan-83 14:43:37 PST (Tuesday)
From: Ayers.PA
Subject: FYI
To: Mitchell
------------------------------
Date: 2-Jan-83 20:15:31 PST (Sunday)
From: Lauer.PA
Subject: Interscript in OS 5.0 Star
To: DeSantis.es, Harslem.es, Nikora.es
cc: Ayers, Kabcenell.es, Lauer
I would like to try to articulate a strategy for Interscript implementation and its relationship to OS 5.0 Star. This would be both a subject for discussion and a constraint that the Star redesign would have to consider. This message, of limited distribution, is my first attempt to explain my thoughts.
Interscript should be the lingua franca of editable documents on the network. First class citizens of the network should both speak and understand Interscript as a matter of preference. Citizens of the network who don't understand Interscript are definitely second class. While a subset of citizens speaking a different format can communicate among themselves, members of that subset cannot expect that the rest of the world will necessarily speak their language nor that documents that they wish to read or edit will necessarily be available in their form. Instead, they have to appeal to a conversion service which knows how to translate between Interscript and the other form. Note that a citizen is not prohibited from mailing or storing a document in his own language, but he accepts the risk that others will not be prepared to understand him.
In general, SDD's strategy should be to NOT provide automatic conversion of document formats to and from Interscript in the basic services of the network. In particular, the mail service should NOT be required to determine what sort of client it has, then locate and invoke an appropriate conversion service to satisfy the needs of that client. Instead, it is the client systems responsibility to cause the conversion to happen when needed. Whether or not this is visible to the user is a matter of the design of the individual clients systems. Very primitive clients may force their users to explicitly mail documents to conversion services; but better implementations should provide automatic or semi-automatic conversion, either within the same system element or by invoking a service.
Star should be the model first-class citizen. It should speak Interscript as a matter of preference in all documents stored or mailed externally. That is, Interscript should be, as a matter of policy, the external document format of Star. Star workstations should communicate with each other in Interscript, not the internal format (if that be different).
From the practical point of view, it is unlikely that Star can fully implement Interscript or that the Interscript standard will have evolved to the point where it can fully describe a Star document. This is okay. It is reasonable that the introduction of Interscript be evolutionary, starting with, say, the main body of text of a document and gradually expanding in later releases to include graphics, equations, and other facilities included in Star documents. That is, some of the parts of a document implementation might be in a private format for some temporary period, provided that they are hidden by legal Interscript escape sequences. HOWEVER, the Interscript architecture and strategy must be included in the redesigned Star from the beginning.
Given this strategy, there are a number of issues that must be discussed and resolved:
1. Should the internal and external document formats of Star be different? or is it reasonable that Star can directly manipulate an Interscript document? [My intuition is that internal and external document formats ARE different. This is based on observations of Bravo and other editing subsystems around here.]
2. Assuming that internal and external formats are different, when should the conversion be done? Some possibilities are:
at the time the document is opened or closed (makes open very
slow)
at the time the document is prepared for editing (e.g., when the
user presses the 'edit' button and again when he 'saves')
when the document is transmitted onto the network or to a floppy
(but this means looking inside of each folder and doing
conversion on the fly)
others?
Comments? other issues? suggestions about wider distribution?
/Hugh
----------------------------------------------------------------