Heading:

Mesa Language Working Group Minutes -- December 16, 1977

Page Numbers: Yes X: 527 Y: 10.5"

Inter-Office Memorandum

ToLanguage Working GroupDateDecember 19, 1977

FromJohn WickLocationPalo Alto

SubjectMinutes of 16 DecemberOrganizationSDD/SD

XEROX

Filed on: [MAXC]<WICK>LWG-16DEC77.BRAVODRAFT

The Mesa Language Working Group met on Friday, December 16, 1977; Geschke, Lampson, Sweet, and Wick were present.

Allocate/Make

Ed advised that the compiler would be happier if these constructs separated the type expression and the initialization (as in declarations). For example,

p ← ALLOCATE red Foo ← Foo[. . . , red[. . .]] USING proc

The only drawback noted was that for long records and arrays, the USING clause can get lost on the end (we could put it first?).

Defaults

It was noted that the revisions to the rules for omitted fields in constructors made at the last meeting would introduce a rather unpleasant source incompatability. Disallowing the constructions ", ," and "field: ," when there is no default would invalidate lots of existing code. We decided on a warning message instead (except for procedure argument and result records; an omitted field will continue to be an error if there is no default).

Note that the warning applies only to constructors (any number of keywords or trailing commas can be omitted in extractors without complaint) and it applies only if there is no default. We retained the notation "field: NULL" to override a defaulted field (with an undefined value).

Included Identifiers

The following syntax for included identifiers is a bit easier to format than the one suggested last time:

Defs: FROM "defs" USING [a, b, . . . , c]

Some other keyword or bracketing scheme might be better (suggestions?).

String Constants

Ed pointed out (in absentia) that the construction

sb: StringBody[5] ← "abc"↑

would have the effect of copying the string constant from the code (once sequences are implemented). But the notation is not very obvious (BODY["abc"] was suggested), and the rules for determining where the storage is allocated are rather subtle.

Since the location of the allocated storage needs to be absolutely clear to the programmer (if he cares), we decided on a separate notation for string constants allocated in the local frame. This scheme has the advantage of "doing the right thing" even when the the string appears only as an argument in a procedure call, without any explicit declaration. (This also has the advantage of being independent of (but compatable with) the implementation of sequences, which probably won’t make it into version 4.) Three possibilities were suggested:

LOCAL["abc"]

\abc\ other available delimiters: $ % & ? |

"abc"L analogus to 177B and 33C

Needless to say, there was no consensus.

Sequences

The summary prepared from previous minutes pointed out that the relation between arrays, sequences, and descriptors was a bit unclear. The rules are as follows:

Arrays and sequences (or pointers to them) are not assignable to each other (because the index type and the sequence tag type cannot match). This is consistent with using computed sequences in place of arrays without index sets.

Descriptors for sequence bodies are valid only if the descriptor is declared without an index type. (The DESCRIPTOR construct should operate directly on sequences.)

With these points resolved, it is believed that sequences are ready for implementation.

Status

The following is an excerpt of the priority one and two items from the Mesa task list. Those items which are underlined have not yet been addressed by the Language Working Group. Most items are complete except for "implementation details". (A small matter of programming, right?)

Priority I

Long Integers
Long Pointers
Monitors
Open Procedures
String Constants
Tied (Based) Pointers

Priority II

Allocating Instances of Variables
Character Arithmetic
Default Parameters
Default Record Fields
Field Descriptors
Included Identifiers
Mutable Variant Records
Painted Integers
Pointer Arithmetic
Ports
Real Data Type
Sequences

Since the design is currently several months ahead of the implementation, we should probably call a halt to this series of meetings fairly soon and concentrate on writing code and discovering glitches in the proposals. One or two more meetings on field descriptors and painted integers would be profitable now (but I refuse to jump into ports again). A "cleanup" meeting or two will likely be required sometime between now and the next release.

Distribution:
Geschke
Lampson
Mitchell
Satterthwaite
Mesa Group