Heading:qjk40(635)
Mesa Language Working Group Minutes -- December 16, 1977y756qjk40\b56B
Page Numbers: Yes  X: 527  Y: 10.5"qjk40
Inter-Office Memorandumz18592l4445y762\f5b
To	Language Working Group	Date	December 19, 1977z18592l4445d2998e21(0,65535)(1,4445)(5,11684)(6,14146)\f7 2f0t2 1t0 22t6 1f7t0 4f0t7 1t0
From	John Wick	Location	Palo Altoz18592l4445d2998y716e25\f7 4f0t2 1t0 9t6 1f7t0 8f0t7 1t0
Subject	Minutes of 16 December	Organization	SDD/SDz18592l4445d2998e25\f7 7f0t2 1t0 22t6 1f7t0 12f0t7 1t0
XEROX       z18592l508y644e14(2116)\f2 5f0
Filed on: [MAXC]<WICK>LWG-16DEC77.BRAVO	DRAFTe30(0,16510)(1,65535)(5,65535)(6,65535)\f7 39f1 1f9b5f1B
e10(2116)
The Mesa Language Working Group met on Friday, December 16, 1977; Geschke, Lampson, Sweet, and Wick were present.x2e12jk40(1799)
Allocate/Makee12jk80\i
Ed advised that the compiler would be happier if these constructs separated the type expression and the initialization (as in declarations).  For example,x2e12jk40
p _ ALLOCATE red Foo _ Foo[. . . , red[. . .]] USING procl4269x2e12jk40\f6b4f7 8f6 35f7 5f6
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?).x2e12jk40\66f7b5f0B
Defaultse12jk80\i
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).x2e12jk40\197f6b3f0B7f6b8f0B
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).x2e12jk40\213f6b7f7 4f0B
Included Identifierse12jk80\i
The following syntax for included identifiers is a bit easier to format than the one suggested last time:x2e12jk40
Defs: FROM "defs" USING [a, b, . . . , c]l4269x2e12jk40\f6b6f7 4f6 8f7 5f6 18f0B
Some other keyword or bracketing scheme might be better (suggestions?).x2e12jk40
String Constantse12jk80\i
Ed pointed out (in absentia) that the constructionx2e12jk40
sb: StringBody[5] _ "abc"^l4269x2e12jk40\f6b26f0B
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.x2e12jk40\140f7b4f6 7f0B
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:x2e12jk40
LOCAL["abc"]l4269x2e12jk40\f7b5f6 7f0B
\abc\  other available delimiters: $ % & ? |l4269x2e12jk40\f7b1f6 3f7 1f0B
"abc"L  analogus to 177B and 33Cl4269x2e12jk40\f6b6f0B14f6b4f0B5f6b3f0B
Needless to say, there was no consensus.x2e12jk40
Sequencesx2e12jk40\i9I
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:x2e12jk40
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.l4269x2e12jk40
Descriptors for sequence bodies are valid only if the descriptor is declared without an index type.  (The DESCRIPTOR construct should operate directly on sequences.)l4269x2e12jk40\106f7b10f0B
With these points resolved, it is believed that sequences are ready for implementation.x2e12jk40
Statusx2e12jk40\i6I
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?)x2e12jk40
Priority Iz18556x2e12jk56(635)\i
Long Integers
Long Pointers
Monitors
Open Procedures
String Constants
Tied (Based) Pointersz18556x2e6jk88
Priority IIz18556x2e12jk56\i
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
Sequencesz18556x2e6jk88\96u17U46u16U20u5U
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.e12jk40(2116)
e12jk40
Distribution:
Geschke
Lampson
Mitchell
Satterthwaite
Mesa Groupl3528d2998x2e12k80