From comp@komp.ace.nl Mon Aug 31 20:46:11 1992 Received: from sun4nl.nluug.nl by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA16582; Mon, 31 Aug 92 20:46:11 +0200 Received: from netnog.ace.nl by sun4nl.nluug.nl via EUnet id AA17562 (5.65b/CWI-3.3); Mon, 31 Aug 1992 20:45:46 +0200 Received: from ace.ace.nl by netnog.ace.nl with SMTP id AA02943 (879.1.1.11/2.17); Mon, 31 Aug 92 20:11:03 +0200 (MET) X-Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. +31 20 6646416 (phone) +31 20 6750389 (fax) 11702 (ace nl) (telex) Received: from komp.ace.nl ([192.1.2.90]) by ace.ace.nl with SMTP id AA15532 (1.14/2.17); Mon, 31 Aug 92 19:26:41 +0200 (MET) Received: by komp.ace.nl with SMTP id AA21157 (1.10/2.17); Mon, 31 Aug 92 18:15:38 +0200 (MET) To: sc22wg11@dkuug.dk Subject: WG11/N334: Report on Tampere WG11 meeting Date: Mon, 31 Aug 92 18:15:30 N Message-Id: <21155.715277730@komp> From: Willem Wakker X-Charset: ASCII X-Char-Esc: 29 SC22/WG11/N334 Report on WG11 meeting Tampere 21-23 August 1992 After identification and copying of papers needed, and assignment of temporary (Tampere) numbers T1, T2 etc. to them, the meeting began at about 10.45 on Friday 21 August 1992. (This report uses the WG11 numbers later allocated to these) Present were Ed Barkmeyer (USA, CLID editor), Ken Edwards (USA, CLIP editor), Brian Meek (UK), and as observer and invited participant Roger Scowen (UK and WG17 Prolog convenor). It was noted that the convenor, Willem Wakker, would not be arriving until late Saturday, and Brian Meek was appointed chairman in his absence. Since no formal agenda was available, this being primarily an editing meeting to review the latest drafts of the CLID and CLIP documents, the draft agenda for the October meeting was used as a guide. Administrative items 1-4 and 14-15 were left until the convenor arrived. Under item 6 (bindings TR) it was noted that the letter ballot comments should be reviewed though their resolution would have to be left to the October meeting, but this item too would be deferred until the convenor arrived. There were documents relating to items 8 (LIA-1) and 11 (RPC) that might need some agenda time, as also was the case with 12a (Posix) and 12b (PCTE). Nothing was known that would need discussion under the other agenda items. It was therefore agreed to deal with item 7 (CLID) on the first day and item 6 (CLIP) on the second day (Saturday). 7. Common language-independent datatypes 7.1 Review of Roger Scowen's comments (N309) The UK panel had reviewed and discussed N309 with Roger Scowen and had produced a response document (N324). In the meantime Roger had incorporated the substance of N309 in a UK contribution to SC22 (N1201) which as explained in a later electronic mail message was an individual submission, not an endorsed UK position. He had also produced for this meeting documents his reactions to Brian Meek's draft of the response document now designated N324. Brian Meek began by going through N309 and N324, explaining where the UK panel agreed with N309 and expanding on the reasons given in T1 where disagreement was expressed. Much of the disagreement arose from different perceptions of the scope, purpose, and level of abstraction of the CLID document; the panel agreed with many of the statements of need but did not believe that the CLID standard was the appropriate place to address them. Many of them needed to be addressed in mapping standards (bindings) or cross- language service standards such as CLIP, but did not belong in CLID. The UK panel agreed that definitions could be improved and tightened but felt that the necessary precision and rigour could be attained without introducing mathematical formalism which would render the draft standard unacceptable to much of the readership in the language communities. Roger Scowen then introduced his reply document and initiated a discussion on the issues he had raised and still caused him concern, as an individual or as a language WG convenor. The most important of these was his view that a datatype is not just a set of values but also the set of operations on those values. The discussion was not intended to resolve the issues but rather to clarify them, though some had already been addressed in the latest version (version 6) of CLID (N319). On the question of using LaTex, the project editor said that this is not a practical possibility for him but he intended to use double column for future drafts. He also accepted the suggestion that issues in the issues list should each have a unique and constant identifier for ease of comparison between drafts. WG11 did not feel able to accept Roger Scowen's position on all of the issues raised. In particular members argued that, since many potential applications of CLID did not need the operations, as Roger had pointed out in his conformity recommendations, it made sense to keep those separate. Because of the many different uses of datatypes in different contexts, it would be very difficult to achieve agreement on and acceptance of a normative set of operations for all datatypes. The place for normative operations was in standards based on CLID that needed them; the role of CLID was as enabling standard, to establish a common set of definitions based at the static level of value sets, on which such operational standards could build. However, numerous points were raised during the discussion which later proved helpful in resolving outstanding issues in N319. 7.2 Review of version 6, N319, and editor's notes, N320 Ed Barkmeyer introduced N319 and went through the notes in N320 explaining the changes to the document and the resulting changes to the outstanding issues list. The remaining outstanding issues on pages (i) - (iii) of N319 were then discussed, with the outcome as follows. (Roger Scowen participated in the discussions but not in the decisions on these issues.) Issue 1 (move datatypes from clause 7 to clause 9): No moves are necessary. This is not a major issue: what is important is that datatypes that are similar but can be distinguished are distinguished. Other taxonomies of datatypes are possible which might entail such changes but the current one is viable for these datatypes and these changes would not bring about noticeable improvements. Issue 2 (array, etc subtypes of a more general Map datatype?) It was agreed that the term "mapping" must be avoided except in the context of mappings between CLID datatypes and language datatypes. Brian Meek pointed out that it was an established UK requirement that a generic definition of "aggregate" datatypes be included, together with explanation of the derivation of the various kinds of aggregate in terms of their structural and conceptual properties - homogeneity, dimensionality, indexibility etc. This would have been in formal UK technical comment accompanying its NO vote had it chosen to vote in that way on the 1st CD, and had only received little attention so far because WG11 had concentrated on the formal comments from other NBs. After discussion it was agreed to adopt this taxonomy, with the current aggregates 7.3.2 - 7.3.7 being move to a new subsection "Aggregate datatypes" and 7.3.1 (Choice) together with 7.1.14 (Pointer) and 7.1.15 (Procedure) and probably 7.3.8 (Declared- generator types) remaining in a (possibly renamed) "Generated datatypes" subsection. Issue 3 (model for Set and Bag?) After discussion it was agreed to adopt the mathematical model to provide the relationship and distinction between Set and Bag but to provide explanatory text and Venn diagrams as illustration. Issue 4 (description of Table generator) This could be rolled up into the generic taxonomy for aggregates; multiple keys would be included (i.e. Table can be multidimensional). Issue 5 (user-defined datatypes and generators) It was agreed that CLID must have IDN definitions of everything it needs regardless of whether or not these are needed for CLIP or RPC, the only constraint being that they must not introduce conflicts or inconsistencies. It was noted that RPC would include IDN definitions not needed for CLIP or CLID and CLIP would include IDN definitions not needed for CLID and perhaps some not needed for RPC. A solution to the principle of "the same IDN (definitions)" was that all three standards could contain an informative annex containing all IDN definitions distinguishing those used in that standard from those used only in one or both of the others. That was a matter which could be resolved with the RPC group at the October meeting. Issue 6 (is direct compliance meaningful?) The answer is yes: mapping (binding) standards would conform directly, and the possibilility must be allowed for interface definitions without their own standards or relevant defined mappings to be able to use CLID datatypes and claim conformity. Issue 7 (use of outward mappings?) Outward mapping had to be defined in order to identify formally which CLID datatypes correspond to the internal language datatypes and where necessary to document constraints or minimal requirements which may be specified in the case of some datatypes. Issue 8 (radix other than 10?) For the purposes of the definitions in CLID itself more than one radix is not necessary so this is not at CLID issue at all. It may be important for languages with literal denotations in their syntax for different radices, but that is a matter for the mapping standards. Issue 9 (informative annex with example mapping?) It had been agreed to include this in response to a French comment and in principle it would be a useful addition. However, it would appear on reflection that it might cause objections from the language WG or community concerned if WG11 itself provided this. It was agreed that this could be raised at SC22 plenary during the discussions on cross- language issues - when it was possible that a WG might volunteer to provide the annex - and also perhaps to ascertain if France would object to the 2nd CD if it were not possible to provide such an annex at that stage. Issue 10 (compliance of various kinds of entity?) Though this had not yet been done the project editor thought that there was now enough material in existence on possibilities or actual attempts at compliance to enable this to be done in time for the 2nd CD. It was therefore agreed that this would be included in the final 2nd CD draft for the October meeting. Issue 11 (reference model only? compliance rules?) It was agreed that CLID had characteristics of a reference model but went beyond that. As stated under issue 6, direct compliance is needed so that products such as cross-language or cross-entity utilities can reference, use, and claim conformity to CLID, especially where no relevant standards exist which would allow indirect compliance. In addition, the possibility of direct compliance will encourage future products, including new kinds of products, to use standard CLID datatypes directly rather than defining their own and then needing mappings. No changes to the compliance rules were proposed; some of the subsidiary issues under this heading were not addressed. Issue 12 (integer-modulo, modulo) It was agreed to include modulo as Cyclic-enumerated and integer- modulo renamed as Modulo, with Enumerated as a generator from State and Cyclic-enumerated as a generator from Enumerated. This was thought to be a noticeable taxonomic improvement. Issue 13 (annex B) This is a minor issue, to be decided when views of French and German members of WG11 have been obtained. Issue 14 (Pointer to Procedure) This is an issue in CLIP rather than CLID, relating to invocation and parameter passing and not to the conceptual notion of datatype; it is a part of the procedure datatype characterising operation "Apply". For CLID it is simply the application of Pointer to the Procedure datatype and can remain as it is. Issue 15 (Nonnegative and Inorder) The project editor felt that he could now resolve this in the light of the discussions on the relationship between CLID and LIA and the use of mathematical formalism under agenda item 7.1. Issue 16 (atomicity of values) Values of primitive datatypes are necessarily atomic, values of others may or may not be. This will be clearer with the introduction of the separate category of dggregate datatypes. This is a minor issue of intent and understanding only, not a major technical issue. Issue 17 (dense/discrete, approximate/exact) This issue was resolved by the removal of the concept of dense v. discrete from the document, which was not necessary to it. The concept of approximate v. exact was important and would be retained. Index datatypes should be finite and exact, not discrete. Selecting, excluding, and Set datatype should be limited to exact rather than discrete. Scaled is not an approximate datatype, it is an exact datatype which through operations on its values is used in some applications to provide approximations to values which it cannot represent directly. The concept of "numeric datatype" was not required in the CLID definitions though it could appear informally for explanatory informative text if this were felt to be useful. In summary, all issues had been resolved except issue 5 which needed discussion with the RPC group, issue 9, to be raised at SC22, some remaining parts of issue 11 still to be addressed by WG11, and issue 13, to be decided after the views of the French and German members of WG11 had been obtained. 6. CLIP 6.1 Review of N317 On Saturday morning the task list was reviewed and the group then turned to CLIP. Ken Edwards introduced N317 and remaing issues discussed. In response to a query by Roger Scowen it was confirmed that CLIP covers no representational issues and in particular did not prescribe a required serial ordering of the individual elements of aggregate datatypes; however, it was required that mappings and hence marshalling and unmarshalling must preserve the integrity of the individual elements. How this was achieved was immaterial to CLID. In response to queries about the scope statement it was agreed that in clause 1.2 the term "processor" would be better replaced by "language processor" in the sense of TR 10176, that in the exclusions reference to "data processing system" would be better replaced by "configuration" in the sense used in the conformity TRs, and that a separate explicit exclusion about ordering of actual parameters would make clear the point just raised about aggregated values. Changes would entail corresponding changes in clause 3, in which also the definition of "procedure" as the Procedure datatype was not what was required, and an explanation was needed that "client procedure" in the sense used in the CLIP document represented a generalisation of the usual language concept of "procedure". 6.2 Review of N331 The comments by Dan Yellin (N331) were reviewed. The meeting disagreed with the view of global data expressed in point 1: it must at least conceptually involve marshalling and unmarshalling and this in turn can be regarded as a form of parameter passing. However, for global data this marshalling and unmarshalling can be at any time before the call, at the time of call, during execution of call before access to the global data is needed, or at the time access is required. In that sense the "implied parameter passing" and corresponding marshalling is not constrained in the same way as explicit parameter passing by the specific types listed in clause 6.4. On Yellin's comment 2, 6.4.1 and 6.4.2 distinguishes whether the parameter is first passed at the time of invocation or at some later time. Call-by-value-sent-on-request (6.4.2) is not "weird", it is an optimisation aid so that where an actual parameter may not in fact be used during a particular call, it is not passed, since it is not requested by the server. Languages may not "implement" this specifically but many standards do not preclude it. As for repeated calls, these can be handled by making the parameter a pointer which can be repeatedly referenced by the server, or a procedure which can be repeatedly called by the server. As for 6.4.4, the document states explicitly that it is "primarily here for completeness", so that CLIP can cover all possibilities should the need arise. In fact 6.4.3 and 6.4.4 can both be improved since they should relate to the timing of the server's return of the value rather than what the client does with that value when returned, something which is a matter for the client language standard or CLIP binding standard. Hence 6.4.3 should be changed to call- by-value-returned-on-termination. The project editor was asked to do this and the corresponding changes in the body of 6.4.3 and 6.4.4. The third of Dan Yellin's points was editorial. 6.3 Further discussion on N317 The conformity rules in clause 5 were considered and it was decided that the rules for language processors and for other information processing entities should be provided separately. 7.3 Review of N299 Len Moss's had submitted comments from X3J3 which had been deferred from the Baltimore meeting. Of the four sets, nos. 1 and 4 were already resolved in version 6 (N319). On the array queries in no. 2, several of the varieties appeared to arise from needs for different kinds of parameter passing for different purposes, and effectively all array dataypes with particular constraints or characteristics that could be included in a mapping standard. However, they also appeared in some cases to be based upon an implementation model which was more akin to a sequence or flat list (without substructure) with an indexing capability overlaid upon it. After extensive discussion it was agreed that the Fortran community, WG5 and/or X3J3, could be asked to review this again once the aggregate datatypes have been recast. Brian Meek undertook to try to contact WG5 people on these matters during the SC22 meeting and to find out if a copy of the Fortran 90 standard was available for reference. As far as inability to denote a null pointer was concerned, the outward mapping (or inward reverse mapping) of Fortran POINTER would be to Pointer and no null value would ever be passed out. The inward mapping could be defined with the constraint that if used with a CLID value of null an error would be generated. 7.4 Prolog datatypes Roger Scowen circulated some excerpts from the draft Prolog standard and gave a short tutorial on the datatypes of Prolog. There followed a discussion on possible ways of mapping these. Terms had to be one of five types. Of these, integer and floating point were straightforward. Atom seemed to be best mapped as New CharacterString and Variable as Pointer to the union of all types. Compound was much trickier and would need considerable work. It was noted that CLID was never intended to be universal and there was a guideline used on whether a datatype was included depended on how many languages it appeared in. Roger Scowen said that he would not be concerned if the current CLID types could not accommodate Atom, Variable or Compound. The group thought that it was always valuable to shed new light on CLID by comparing it with actual languages, and if possible adjusting or adding to definitions to accommodate new datatypes. However, this did not seem easy in the case of Prolog Compound. aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Willem Wakker email: cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ACE Associated Computer Experts bv ...!mcsun!ace!willemw van Eeghenstraat 100 tel: +31 20 6646416 1071 GL Amsterdam fax: +31 20 6750389 The Netherlands tx: 11702 (ace nl) eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee