*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 } 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$ { font.italic_TRUE } < 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 } 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$ } 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 Foo} is equivalent to { { TAG$ < content > 1.0 27 assign _ ment } { 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]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$ } { TEXT$ < goo> } ... } and emit the script { PARA$ { TEXT$ font.points _ 12 } { 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$ } { 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 {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_. . . 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 } {Box$} {Box$ 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: <> Example: <> ------------------------------------------------------------------------ Primitive nodes: A string value 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: 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$ } {TEXT$