nigam@MITRE.ARPA (05/31/88)
Soft-Eng Digest Mon, 30 Apr 88 V: Issue 7 Today's Topics: Announcement of Leif Distribution Boswell and the Project Chronicles (2 msgs) Control flow and common sense (4 msgs) CP Minutes of ECMA TC33 PCTE Second Meeting New ECMA TC33 PCTE Terms of Reference number-string conversions Programming Environments Survey Request for information on DAVE and other dataflow tracing tools requirement specification ---------------------------------------------------------------------- Date: Thu, 19 May 88 18:28:05 cdt From: wsmith@m.cs.uiuc.edu (William Smith) Subject: Announcement of Leif Distribution We have just released Leif, a language oriented editor that is based on a recognition paradigm. In a recognition paradigm the programmer enters text and the editor incrementally analyzes this text to determine structure. Many other language oriented editors are based on templates. In these editors, the program is constructed by expanding templates. Template editors prevent the creation of syntax errors by restricting the possible edits. In Leif, the programmer may use all of the text editing commands of a host editor (GNU Emacs) to create a program. The programmer may also use language oriented commands. At any point, the syntax analysis may be consulted to locate syntax errors or display the structure of the program. By using a standard text editor as the front end, Leif offers several benefits. First, there is very little overhead in learning to use Leif. By learning only one new command, the "move to syntax error" command, Leif can be useful. Other commands allow a programmer to see the structure of the program or examine a syntax error. A second benefit is that the user can edit the program as text or as syntax simultaneously. Leif has respectable performance. It uses an incremental parsing algorithm to analyze changes to the text and to maintain a parse tree. If a change is made that affects only a local part of the parse tree, only that part is Analysis does not occur on every key stroke. Instead, Leif allows any number of consecutive changes to be processed as a unit. The programmer may use Leif transparently and request information from the parser when it is needed. Once started, Leif does not require any actions by the programmer for it to follow an editing session. Until a Leif command is activated, the user does not notice any change in the editor. This translates into an efficiency benefit and further enhances the ease of use. A language for Leif is specified as a lexical analyzer and LALR(1) grammar. Standard tools, Lex and Bison (similar to Yacc), are used to process the specification. Once the tables produced by these tools have been converted into an appropriate parse table format, Leif use the tables and edit text in the language. Prototyping the syntax of a language is easy and a designer of a language may specify a language and experiment with it quickly. The language need not be a programming language, but could instead be a specification, design or text processing language as long as a language fits in the lexical analyzer and parser paradigm. Leif is available via anonymous ftp from a.cs.uiuc.edu. The files are located in the subdirectory pub/Leif. Consult the file README.DIST that is in that directory to decide which files to retrieve. Documentation is available in the file leif-doc.tar.Z. (If you are unable to retrieve the files via ftp, please contact us.) Please send Leif related queries to ihnp4!uiucdcs!leif or leif@a.cs.uiuc.edu Bill Smith, Dan LaLiberte, Roy Campbell ------------------------------ Date: 12 May 88 03:24:16 GMT From: pixar!unicom!jonson@bloom-beacon.MIT.EDU (Mary D Johnson) Subject: Boswell and the Project Chronicles In article <41891UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: . . . to paraphrase the guru, boswell, expert (chose one) might be more valuable than the project leader at least that seems to be Lee's message (in my words) It also seems to be the hardest thing to convince management that the department or project manager might not be too upset to pay more than they make themselves to get the services of someone who is really good. How many coaches make more than their star pitchers, centers, or quarter backs? ------------------------------ Date: 13 May 88 17:42:56 GMT From: uh2%psuvm.BITNET@CUNYVM.CUNY.EDU (Lee Sailer) Subject: Boswell and the Project Chronicles >How many coaches make more than their star pitchers, centers, or quarter >backs? You make our point for us. The Coach is the Chief Programmer. The star pitcher is his assistant. ------------------------------ Date: 7 May 88 14:14:54 GMT From: defun.utah.edu!shebs@cs.utah.edu (Stanley T. Shebs) Subject: Control flow and common sense In article <1122@daisy.UUCP> david@daisy.UUCP (David Schachter) writes: >One fellow I know documented a particularly complex and obscure code with the >comment "This procudure implements the <something or other> algorithm given >on page <xyz> of <some book> by <some author>". (The angle bracketed items >are mine.) Sounds perfectly fine to me. Why waste all kinds of space repeating other people's words? Or worse, not mentioning at all that the algorithm derives from somewhere else? In all fairness, the bald citation is insufficient - there should also be one or two lines like "the algorithm is based on the use of multi-colored pointers cycling around in something resembling a butterfly FFT". This will jog the memory of the informed reader, and strongly suggest to the ignorant reader that there are a lot of prerequisites to understanding this code. ------------------------------ Date: 9 May 88 16:49:11 GMT From: ihnp4!ihlpf!jtkrist@bloom-beacon.MIT.EDU Subject: Control flow and common sense In article <1122@daisy.UUCP> david@daisy.UUCP (David Schachter) writes: >One fellow I know documented a particularly complex and obscure code with the >comment "This procudure implements the <something or other> algorithm given >on page <xyz> of <some book> by <some author>". (The angle bracketed items >are mine.) > golly, this could be me! whenever i need to implement an algorithm, i look first in knuth and if i find what i need, i transliterate the algorithm, as closely as possible, in the language i'm using - yes i know it's not structured and there are lots of labels and gotos, but it works - who was it who said that scientists stand on each other's shoulders, while programmers stand on each other's toes? ------------------------------ Date: 7 May 88 13:27:32 GMT From: uh2%psuvm.BITNET@jade.berkeley.edu.user%host.BITNET@CUNYVM.CUNY.EDU (Lee Sailer) Subject: Control flow and common sense Tastes differ, and gentlefolk can disagree. I am usually delighted when this type of comment appears in the code. The book nearly always makes much better reading than some guys half-literate comments. Real Soon Now, we'll all be using Xanadu, and the comments in the code will actually point at the reference on a disk somewhere, and you'll be able to access it online. :-) ------------------------------ Date: 9 May 88 12:57:44 GMT From: attcan!lsuc!spectrix!yunexus!geac!daveb@uunet.uu.net (David Collier-Brown) Subject: Control flow and common sense In article <1122@daisy.UUCP> david@daisy.UUCP (David Schachter) writes: | One fellow I know documented a particularly complex and obscure code with the | comment "This procudure implements the <something or other> algorithm given | on page <xyz> of <some book> by <some author>". (The angle bracketed items | are mine.) | Real helpful. If I want to understand his code, I have to get the book from | a speciality bookstore or get my company to purchase library access at Stanford | University. Then, hoping the edition I get is the same as his (so the page | numbers match), I read some author's description of the algorithm and hope | the programmer implemented the algorithm exactly. Great, just great. That was probably me. You'll find the photocopies of the pages in the book in the file with the master man pages and design notes for the program. | It is folks like him who justify, in my mind, the existence of nuclear weapons. That's odd, I don't **remember** working for a nuclear weapons company... ------------------------------ Date: Wed, 18 May 88 10:04 BST From: Colin M Thomson <mcvax!gm.rl.ac.uk!CMTA@uunet.UU.NET> Subject: CP In digest V issue 1 fad@balder.think.com.uucp suggests the main problem with the Brooks's CPT organisation is that you can't find the superprogrammer to lead. That isn't the problem at all [as someone already pointed out, you don't need one. However there a few problems:- (a) managements sometimes think you need a superprogrammer: this either stops them using the technique, or (much worse) leads to them putting someone totally inappropriate in the post. [Such managements are subject to natural selection, so this may be a rare problem!] (b) many projects are TOO SMALL for the technique to be applicable. A fairly isolated project of less than 5 man years with a natural timescale of about 10 months is a common enough occurrence. (c) some projects are just too big; it's unreasonable to expect one person to understand the design at a fairly detailed level for the whole of a 5000 man year job. Splitting into subprojects of the right size for attack by cpts can always be done, I guess, but the natural split that comes out of a top level structural design may not deliver chunks of the right size, and imposing a different design split to get the chunks to fit may (will?) introduce precisely the sort of incoherence and structural decay the technique was intended to avoid. [This is not a very serious problem: the task size range that fits the CPT concept well is quite large - say about 25 my to about 125 my, and one can choose to do some tasks within the overall big project with CPT organisation and some with other organisations, ie use it where it fits.] (d) related to (b) above, I saw one bunch of people group together lots of smallish and totally unrelated tasks into a hunk of work to make something big enough to fit CPT style organisation. Needless to say, it didn't work [no design coherence was needed between the individual hunks, in fact radically differing desing styles were appropriate]. So there's a problem of misuse of the technique as well as problems in using it. ------------------------------ Date: 17 May 88 04:23:00 GMT From: casee.dec.com!wyman@decwrl.dec.com (Bob Wyman) Subject: Minutes of ECMA TC33 PCTE Second Meeting Folks, Attached, you will find a copy of the minutes of the second meeting of the ECMA (European Computer Manufacturer's Association) Technical Committee 33 on PCTE (Portable Common Tools Environment). As stated when I posted the minutes for the first meeting, I receive these minutes from the ECMA secretariat on floppy disk and make no editorial changes to them prior to posting them to the network. Thus, I cannot be held in any way responsible for their contents. The only changes I make to the text are those necessary to remove the more bizarre control characters introduced by the word processing software used by the secretariat... For those not familiar with PCTE, it is probably best to say that many consider it the "European CAIS." In fact, significant effort has recently been expended by members of the PCTE community and the CAIS-A team to try to plan a strategy by which PCTE and CAIS can be converged or at least made to interwork. This PCTE/CAIS cooperation is being primarily driven by a number of NATO nations within the IEPG/TA13 sponsored "PCTE+" program. It is expected that PCTE will soon become a standard, at least in Europe, and that this standard will be forwarded to the ISO for broader review. Further, it is expected that either PCTE or an amalgam between PCTE and CAIS will become a requirement for NATO business after 1990. Thus, although PCTE is of European origin, it is likely to have impact on the US market as well. Happy reading. ============================================================================== ECMA / TC33 / 88 / 23 - - E C M A European Computer Manufacturers Association Minutes of TC33 2nd Meeting Cannes, 28-29 March 1988 Chairman : Mr. Morron (ICL) Secretary : Mr. Brockway (ECMA) In attendance : Dr. Crispin (HP), Messrs. Davis (ICL), Frost (BT), Hayselden (SSL), Jeanrond (Nixdorf), Kelter (Universitat Dortmund), Mittermaier (Siemens), Moreau (BIM), Myren (TeleLogic), Smedema (Philips), Thomas (Bull), Wyman (DEC) Excused : Messrs. Harvey (Alcatel), MacDonald (Unisys), Nielsen (DDC), Prof. Dr. Weber (Universitat Dortmund) Absent : Dr. Bologna 1. Adoption of Agenda The Agenda was adopted as proposed (88/12); items were re-sequenced, as reflected by these Minutes. Newly-available papers were noted: X Toolkit Widgets - C Language X Interface (MIT, DEC, 88/18 A), Using the X Toolkit or How to Write a Widget (DEC, 88/18 B), and Conformance to a PCTE standard, issue 1 (ICL, 88/19). 2. Approval of Minutes of TC33 1st Meeting It was felt that the Minutes as written (88/11) do not explicitly reflect an unstated, but nonetheless underlying, agreement of the Meeting that both C and Ada specifications should be included, with equal emphasis, within the initial proposed ECMA standard. On page 3, item 8, the 4th sentence was revised to achieve greater clarity as follows: Mr. Kelter indicated that 1.5 is intended to remove internal inconsistencies in each language-bound specification, and for which a commentary procedure operates within the PICG (88/4 refers), whereas 1.6 is intended to remove mutual inconsistencies between the two language-bound specifications. With these clarifications, the Minutes were approved as written. 3. Matters arising from the Minutes not covered elsewhere An early version of the VDM specification, kindly made available to TC33 through the Office of Mr. Elmore (CEC/XIII/A/4), was received with interest (88/16). Mr. Brockway emphasized that the document is an initial draft and directed particular attention to the cautionary covering letter from ESPRIT VIP Project Manager Mr. Jackson, and to the envisaged availability dates for revised and final versions of the specification as indicated by Mr. Elmore (covering letters to 88/16). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - For readability, TC33 document references are abbreviated from ECMA/TC33/88/n to the form 88/n. Mr. Brockway was asked to request from Mr. Elmore a copy of the Ada Functional Specification (First Edition), and also, with regard to copyright aspects of the PCTE Interface Specifications, to request approval for ECMA TC33 to base its work both on the current versions of the C and the Ada specifications and on future versions as they become available. It was also agreed to request copies of the current PCTE+ C and Ada Functional Specifications, as well as the PCTE+ Interface Specifications Comparison between PCTE and PCTE+. Accordingly Mr. Morron will approach the appropriate authority within IEPG TA13 to seek clarification as to how TC33 can best base its work on the PCTE+ documents; Mr. Brockway will request the current documents from Mr. Fikkert (International Review Manager, TNO) for circulation within TC33. In his contacts with TA13, Mr. Morron will also explore the possibility of using text as recorded on tapes. With regard to the envisaged future launch of ECMA PCTE standards into ISO by means of the fast-track procedure, Mr. Brockway indicated that it is neither required nor desirable for ECMA to pre-submit a proposal to ISO for the creation of a new work item on PCTE (Minutes of 1st Meeting, 87/11, page 3, item 7, refer). Mr. Wyman introduced portions of the ISO fast-track working procedures. It was suggested that a 5-year rule may apply, under which once a standard has been accepted through the fast-track procedure it cannot then be revised within 5 years, a suggestion which, if true, would necessitate a strategic timing of submissions of ECMA standards into ISO. Secretariat Note: Documents describing the ISO fast-track procedure are not being circulated within TC33. Instead, ECMA Secretary General Mr. Hekimi will present the relevant aspects of this procedure at the next Meeting of TC33 (Geneva, 24-25 May 1988), and respond to questions or concerns of TC33 members. In particular, ISO international standards may be revised, in principle, at any time; there is no requirement to wait 5 years before revisions. The 5-year rule (which is not specific to the fast-track procedure) stipulates essentially that every ISO international standard shall be reviewed not less frequently than at 5-year intervals, to ensure compatibility is maintained with regard to other standards and that considerations of areas of overlap are adequately covered. The essential point, in accord with a basic premise of standardization, is that ISO international standards (whether arrived at through fast-track or otherwise) may be revised as often as required provided that the revisions are upward-compatible; revisions that are unable to maintain upward-compatibility should ideally be avoided and, in any event, not applied frequently. 4. Report from PIMB Mr. Morron reported from the 9 March PIMB Meeting. With regard to the briefing given by the TC33 1st Meeting Mr. Morron indicated that: (i) the Ada specification is in the public domain; however the C specification is seen as definitive ; (ii) the proposal (for addressing to the CEC) indicating the desirability of rewriting the C specifications in the style and quality of the Ada specifications, and requesting allocation of the necessary resources, was raised and noted; a considered and definitive response was not however given. Mr. Morron was actioned to raise point (ii) again at the next PIMB Meeting (6 May). Among topics discussed by the PIMB Mr. Morron highlighted language-independency, the possibility of future production of a promotional videoclip for PCTE, and the recommendation that TC33 base its work on the C specifications. Mr. Davis felt it is critical that the issue and funding of specifications of Ada bindings for the User Interface (U-I) be resolved. Mr. Morron agreed to raise this at the PIMB. Mr. Thomas agreed to make available a U-I document for TC33 circulation. 5. Report from PICG Mr. Kelter reported. The overall schedule of PICG work (88/5) has not changed since the previous TC33 Meeting. Few comments have been received on 88/4. A PICG U-I panel has been created as a full-time working group, and has led to a division of tasks. Work on PCTE 1.5 will proceed in an April-May timeframe, geared to the July PIMB Meeting; the timing is recognizably tight. PICG resources are limited and stretched, especially if a large number of change requests are received. Work on C is being given priority. The C specifications are on-line, those of Ada will be brought on-line soon. Some TC33 members questioned the prioritization being given by the PICG to 1.5 C work, and considered it preferable to raise the priorities on Ada. Mr. Wyman suggested that work would proceed more efficiently if the total workload is subdivided into isolated functional areas and addressed by different experts on a per-topic basis. Mr. Wyman indicated that his Company would be prepared to address the topics of date and time and memory allocation management. Considerable support was expressed for this viewpoint. With regard to the relationship of management and technical work in both the PICG and TC33 environments, the possibility of parts of the necessary technical work being carried out within TC33 was noted. TC33 agreed to focus on a November 1988 target for a pre-final draft initial ECMA PCTE standard rather than placing emphasis on the July 1988 PICG target for 1.5. It was agreed that PICG work would be supplemented by TC33 work if seen as necessary. 6. Interface and division of responsibilities between PIMB and TC33 This agenda item was not addressed explicitly, the subject being covered by other items. Messrs. Morron and Wyman agreed to provide the ECMA Secretariat with lists of the memberships of the PIMB and PICG. 7. Review of scope and PoW With regard to the TC33 scope and PoW (88/8) as proposed at the previous Meeting, it was agreed to delete references to 1.4 and the Fourth Edition; the text thus revised was agreed upon (88/20), and will be put forward to the CC Meeting of 26-27 May. 8. Conformance requirements Mr. Davis introduced his paper Conformance to a PCTE standard, issue 1 (88/19). With regard to section 4 Conformance of what? , some participants considered this to be simply conformance of a PCTE; others felt the point to be more complex. The text of 4.1 received particular attention; it was felt that conformance of tools and of implementations are both important. In conclusion, Mr. Davis agreed to prepare draft text for a Conformance Clause for the initial ECMA PCTE standard, for consideration at the next-but-one TC33 Meeting (7-8 July). Mr. Brockway will forward to Mr. Davis further ECMA standards including a selection dealing with programming languages. Discussion of conformance testing was held over until a future Meeting. 9. Report from TC33 Ad-hoc Group on the Reference Model Mr. Wyman reported from the 3-4 March Meeting of the ad-hoc group on the reference model, also attended by Dr. Crispin and Mr. Davis. Terms of reference (ToR) for a new TC33 Task Group on the reference model, accompanied by a schedule of events, as prepared and proposed by the ad-hoc group, were presented by Mr. Wyman. It was agreed to establish a TC33 Task Group on the reference model. The ToR for the Task Group were agreed as follows: Terms of Reference for the TC33 Task Group on the Reference Model (TGRM) (agreed by TC33, 29 March 1988) SCOPE: To define and maintain a reference model for computer assisted systems engineering environments in order to provide a suitable framework within which evolving standards can be defined. PROGRAMME OF WORK: 1. To define the requirements for the reference model with particular focus on the requirements for portability and interoperability within a distributed heterogeneous environment. 2. To solicit input from the systems engineering community on models which can assist in meeting the requirements. 3. To identify international standards that must be referenced by the model. 4. To develop and present to TC33 a proposed ECMA Technical Report defining the model and its rationale. 5. To maintain and enhance the model. Regarding point 3, Mr. Wyman indicated that there are about 150 relevant standards; a list will be circulated within TC33 in due course. Participation in TGRM is open. Dr. Crispin and Messrs. Davis and Wyman indicated their commitment to the work of TGRM; Messrs. Frost and Jeanrond also expressed high interest. With at least 3-5 companies intending to participate in the work, the minimum requirement for a TG was seen to be met, and TGRM formally established. Turning to the proposed schedule for the TG, it was agreed to include a target of September 1988 for a 1st draft Technical Report on the reference model, with a 2nd draft in November 1988 and final draft in February 1989. With this refinement, the schedule for TC33 TGRM was agreed (88/22). Mr. Wyman focused on the workshop on reference models for systems engineering environments, proposed for sometime during October or November. Questions with regard to organization, structure, participation, invitation, papers, and funding were briefly addressed; Mr. Wyman agreed to prepare a proposal covering these and other relevant aspects of the workshop, for consideration at the next Meeting. Requirements for the reference model were given initial attention; some of the points addressed summarily are noted below (contributions and commentary are invited and should be sent to Dr. Crispin): - the single workstation environment, - the non-connected multi-equipment environment, - the connected equipment environment, - with the same PCTE implementation, - with different PCTE implementations, - with equipment all of the same manufacturer, - with equipment of different manufacturers, - the distributed environment, - language bindings, including the possibility (or impossibility) of 1:1 mapping between various bindings, - common services in C and Ada implementations, - the resolution of cultural differences between C and Ada, inherent in the essences of the two languages, - considerations regarding end-users, including end-users as writers of tools and end-users as final users of tools, - interoperability of tools written in different languages. One of the major objectives of the reference model is to provide a framework for a smooth and coordinated evolution of future ECMA standards, in particular to ensure that the first standard is developed in such a way that further standards may easily achieve alignment in the sense of upward compatibility. Mr. Wyman reported on the list of existing studies (88/10). It was noted that documents are now available on ISTAR, PACT, VIP (see 88/16), ESF (for which Mr. Jeanrond agreed to send documents to Mr. Davis), and will soon be available for ATHERTON. Mr. Wyman agreed to follow up with Mr. Bourguignon on EAST. 10. Review of roadmap and timeframe The extract from the Report of a Meeting of the CC held 25-26 February was noted (88/17). Mr. Brockway reported on concerns expressed by the Secretary General to ECMA Management and the CC with regard to changes to the timeframe and planning being proposed by TC33. It was considered by all present that publishing 1.4 as an ECMA standard would serve no purpose and would infact be counter-productive. The initial goal was recalled and confirmed, i.e an initial ECMA standard for adoption by the ECMA GA of June 1989, implying completion of a final draft by TC33 in February 1989. Alternative routes to June 1989 were considered, including an additive path based on 1.4-1.5-1.6 and a subtractive path based on PCTE+. It was agreed that the production of future versions of the draft PCTE standard can best be begun by selective editing of the latest PCTE+ specifications (C and Ada). The differences between 1.4 and future versions of the draft PCTE standard will reflect PCTE+ extensions and other proposed modifications accepted by TC33. TC33 recommend that PICG agree this approach to their achievement of the PIMB directive within three weeks, and inform the TC33 Chairman by telex. It was further agreed that each TC33 participant will brief his Company representatives to the CC and the GA with regard to this situation. Mr. Thomas agreed to prepare a list of the extension areas of PCTE+, and a proposed prioritization, for circulation in advance of the next Meeting, the objective being to examine which of these are suitable for inclusion in the initial ECMA standard. The roadmap and timeframe for TC33 as elaborated at the 1st Meeting (88/9) was then reviewed and updated to reflect the above agreements (88/21). 11. Roles and liaisons It was recalled that internal liaison is envisaged with TC22 (Database) and with TC32-TG2 (Communication, Networks and Systems Interconnection - Distributed Interactive Processing), whose scopes and ToRs are given in document 88/7. Liaison with TC32-TG2 was considered particularly relevant with regard to the recently adopted Standard ECMA-127 Basic Remote Procedure Call (RPC) using OSI Remote Operations. Dr. Crispin accepted nomination to liaise from TC33; Mr. Rutherford (contactable through Mr. Morron at ICL) and he will prepare a brief paper on liaison requirements regarding PCTE and Standard ECMA-127 for review at the next Meeting. The revised TC33 ToR (88/20), these Minutes (88/23) and the Agenda for the next Meeting (88/24) will be sent to the Chairmen of TC22 (Dr. Lamersdorf, IBM) and TC32 (Mr. von Studnitz, Philips) and to the TC32-TG2 Convenor (Mr. Brenner, ICL). 12. Document handling issues This item was not addressed explicitly; the subject was covered under other items. The guidelines offered by the ECMA GA for editing, recording and exchanging drafts of ECMA standards and TRs were noted as circulated (GA/86/21). 13. Chairman's Report to Coordinating Committee Mr. Morron agreed to prepare his report for review by TC33 at the next Meeting (24-25 May), immediately prior to the next CC Meeting (26-27 May). 14. Next Meetings of TC33 and TC33-TGRM The next, 3rd Meeting of TC33 will be held 24-25 May 1988, in Geneva, from 14:00 hours on 24 May until 17:00 hours on 25 May. An Agenda and htel accommodation arrangements are given in document 88/24. Contributions for circulation to TC33 in advance should be sent to the Secretariat to arrive no later than 29 April. The 4th Meeting of TC33 will be held 7-8 July 1988, in Brussels, kindly arranged by Philips, from 10:00 hours on 7 July until 13:00 hours on 8 July (the early start on 7 July is intended to enable participants to reach home by nightfall the following day). The 1st Meeting of TC33-TGRM will be held on 26 April 1988, in The Hague; details will be available directly from Mr. Wyman. 15. Other business (i) Publicity The degree to which TC33 should publicize its work was briefly considered. Since the revised scope and ToR have yet to be reviewed and approved by the CC, it was agreed not to formally activate any ECMA publicity machinery until after the CC review of 26-27 May. It was recalled that all ECMA documents are in the public domain. (ii) Member Company representation in TC33 Mr. Brockway reported that, as noted at the 1st Meeting, despite early indications of interest in the work of TC33, neither IBM nor GEC had announced representatives to this committee. Documents 88/1 through 88/12 had been sent to Apollo Computer, but no indication has yet been received regarding interest in participating in TC33. Secretariat Note: IBM has subsequently announced its membership of TC33. With all business concluded, Mr. Morron guided discussion to a close and adjourned the Meeting, thanking all present for their participation in the progress achieved. Thanks were extended to Mr. Wyman and Digital for organizing and hosting this Meeting. ------------------------------ Date: 17 May 88 04:45:00 GMT From: casee.dec.com!wyman@decwrl.dec.com (Bob Wyman) Subject: New ECMA TC33 PCTE Terms of Reference Dear Readers, Attached you will find the new Proposed Revised Terms of Reference for ECMA (European Computer Manufacturer's Association) Technical Committee 33 on PCTE (Portable Common Tools Environments). These are referred to in the minutes of the 2nd TC33 meeting, previously posted. =============================================================================== ECMA / TC33 / 88 / 20 E C M A European Computer Manufacturers Association Proposed Revised Terms of Reference of TC33 As revised by TC33 2nd Meeting, Cannes, 28-29 March 1988 (supersedes document TC33 / 88 / 8) The Scope and Programme of Work of TC33 as they appear in document TC33/88/1 and in the 1988 Edition of the ECMA Memento were reassessed by TC33 at its 1st Meeting, held 1-2 February 1988 in Geneva. A proposed revised text was then circulated as document TC33/88/8, incorporating clarifications and editorial changes, and also reflecting shifts in importance attached by TC33-represented Member Companies to the various aspects of the work in which TC33 intends to engage. The text was further amended at the TC33 2nd Meeting by replacing the references PCTE 1.4 and Fourth edition by PCTE. Pending approval by the Coordinating Committee, TC33 is proceeding on the basis of the terms of reference thus revised and shown overpage. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - overpage TITLE: PORTABLE COMMON TOOL ENVIRONMENT (PCTE) SCOPE: To standardize a common tool interface, implementable on a wide range of operating environments, to ensure a suitable foundation for portable, interoperable computer assisted systems engineering tools and tool sets. PROGRAMME OF WORK: 1. To define a layered reference model for computer assisted systems engineering environments that will support the incremental definition and evolution of interface standards. 2. To position PCTE (see Note) within that reference model. 3. To develop interface standards for the layers of the reference model, taking PCTE (see Note) as a starting point. 4. To maintain liaison with TC22 and with TC32-TG2. 5. To maintain liaison with the PCTE Interface Management Board (PIMB) and its technical group - the PCTE Interface Control Group (PICG), with DG XIII of the Commission of the European Communities, with the PCTE+ programme of Technical Area 13 (TA13) of the Independent European Programme Group (IEPG), and with the German PCTE Initiative. 6. To identify and position complementary standards and standards activities relevant to the reference model, and to maintain liaison with those standards organizations responsible for their maintenance. 7. To develop interface standards for the lowest layer of the reference model first and in the shortest possible time, while taking into account the requirements and specification efforts already underway as noted in item 5. 8. To prepare standards in a form acceptable for submission via ECMA to ISO. 9. To present the standards ultimately as an abstract specification with separate language bindings. Note: PCTE: the Portable Common Tool Environment Functional Specifications, currently managed by the PCTE Interface Management Board (PIMB). ------------------------------ Date: 19 May 88 14:37:34 GMT From: jfjr@mitre-bedford.arpa (Jerome Freedman) Subject: number-string conversions I am not sure if this is the correct group so forgive me if I am wrong. A few days ago Robert Firth criticized (Boy did he) some Pascal code that translated integers and floats to strings and back again. Its an issue I never gave much thought to but it interested me. How is this done when done well?? any pointers to relevant literature?? ------------------------------ Date: 20 May 88 23:00:11 GMT From: beta!dph@hc.dspo.gov (David P Huelsbeck) Subject: Programming Environments Survey I'm interested in finding information about who is doing research in the areas of programming environments, software tools, CASE etc. I'm also interested in finding out generally what these folks are doing. My interest is two fold. First, I may be working on a programming environments related project at work some time this fall. Second, I plan to graduate with my BSCS some time in the not too distant future and I'd like to pursue a graduate degree with programming environments as my emphasis. I've looked a fair amount of literature but I haven't turned up a lot of leads. So any and all help would be appreciated. ------------------------------ Date: 18 May 88 18:04:16 GMT From: attcan!utzoo!dciem!array!len@uunet.uu.net (Leonard Vanek) Subject: Request for information on DAVE and other dataflow tracing tools Does anyone know the complete address of NAG on Banbury Rd., Oxford UK? I am interested in NAG as the source for TOOLPAK, specifically a component called "DAVE", which performs dataflow tracing of Fortran programs. If anyone has information on either DAVE or NAG's TOOLPAK I would also like to hear from you. This would include references to work on DAVE by Osterweil and Fosdick. I would also like to hear about any other interactive dataflow tracing tools that anyone knows about. ------------------------------ Date: 17 May 88 22:42:23 GMT From: uhccux!cs661s02@humu.nosc.mil (Cs661s02) Subject: requirement specification I looking for references in generating requirement specification document. Thanks in advancs ------------------------------ End of Soft-Eng Digest ******************************