MDAY@xx.lcs.mit.EDU ("Mark S. Day") (03/13/88)
Soft-Eng Digest Sat, 12 Mar 88 Volume 4 : Issue 17 Today's Topics: Functional Approaches to Concurrent Systems HICSS-22 Call for Papers Metrics on Specs, 4GL, 5GL Name Space Problem (2 msgs) "Efficient" Implementation Requirements for a New Kernel ---------------------------------------------------------------------- Date: Sat, 27 Feb 88 15:18:16 PST From: Eugene Miya <eugene@ames-nas.arpa> Subject: Functional Approaches to Concurrent Systems >I'm very interested in building concurrent/parallel systems, such as >operating systems, in the framework of functional programming. > >Recent nonprocedural approaches to concurrent systems are based on >mathematical-flavour concepts such as logic, functional, or >message-based (Ex: Actor) programming. Of the three, it is seemed that >logic and message-based approaches are more studied than functional in >the field of concurrent systems. > >Why functional approaches have been less studied? > >If you know other researches or papers related to functional >approaches, please let me know. As a follow up to Mark Day: There is a pretty good machine readable biography composed to Andy B. Cheese at Nottingham. I just converted it all to refer format. Lauren Smith (lls@mimsy.umd.edu) maintains the US copy, but I suspect that Andy uses it for his personal collection. A good number of papers are Alvey papers which the English will not distribute out of their country (I spoke to Andy about some of this), and I suspect that American and Japanese requests are looked at with especially competitive perspectives. Lauren's ultimate employer might also have something to say about giving you a copy. If you want a copy, let me know, it's 368KB with the largest of 24 being 35 KB. If I get burned for sending it to you, I will let the net know (assuming they don't take my accounts away). U.S. requests should be sent to Lauren and European requests to Andy. There's numerous applicative language and other approaches. It's not like this is a vacuous area of research. I have several problems with bibliographic sevices which I won't elaborate one: like great for librarians, not as great for researchers. --eugene miya NASA Ames ------------------------------ Date: 4 Mar 88 14:59:05 EST From: Thomas Corbi <GROKLIB@ibm.com> Subject: HICSS-22 Call for Papers CALL FOR PAPERS AND REFEREES HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES - 22 "SOFTWARE DESIGN TOOLS AND TECHNIQUES" Kailua-Kona, Hawaii -- January 3-6, 1989 The Software Track of HICSS-22 will contain a special set of papers focusing on a broad selection of topics in the area of SOFTWARE DESIGN TOOLS and TECHNIQUES. The presentations will provide a forum to discuss new advances in theory and applications of software design. The need for systematic software design has received increasingly widespread acceptance. Researchers have been actively working on various design tools and techniques to improve the software development process. These design tools allow for design to be expressed in a a variety of useful notations including requirement-oriented representations, mathematical representations, and programming language oriented representations. This session will explore development of new design tools, methods and notations as well as improvement of existing tools and environments to help promote high levels of software quality. Submissions are solicited in various topics of software design tools, techniques, and environments, including: * incremental definition and analysis of programs (syntax directed editors) * distributed software design * architectural design * requirement specifications and analysis * traceability throughout the system lifecycle * reuseability in design and implementation * performance engineering analysis * program and data structure display * software architecture Papers are invited that may be theoretical, conceptual, tutorial, or descriptive in nature. Those papers selected for presentation will appear in the Conference Proceedings which is published by the Computer Society of the IEEE. HICSS-22 is sponsored by the University of Hawaii in cooperation with the ACM, the Computer Society, and the Pacific Research Institute for Information Systems and Management (PRIISM). INSTRUCTIONS FOR SUBMITTING PAPERS Manuscripts should be be 22-26 typewritten, double-spaced pages in length. Do not send submissions that are significantly shorter or longer than this. Papers must not have been previously presented or published, nor currently submitted for journal publication. Each manuscript will be put through a rigorous refereeing process. Manuscripts should have a title page that includes the title of the paper, full name of its author(s), affiliation(s), complete physical and electronic address(es), telephone number(s), and a 300-word abstract of the paper. DEADLINES * A 300-word abstract is due by March 30, 1988 * Feedback to author concerning abstract by April 15, 1988 * Six copies of the manuscript are due by June 6, 1988 * Notification of accepted papers by September 1, 1988 * Accepted manuscripts, camera-ready, are due by October 3, 1988 SEND SUBMISSIONS AND QUESTIONS TO: Prof. Narayan C. Debnath HICSS-22 Software Design Tools and Techniques Session Coordinator Department of Computer Science University of Wisconsin-River Falls River Falls, WI 54022 715-425-3769 ------------------------------ Date: Fri, 04 Mar 88 10:37 CET From: "Ludwig Hausen +49-2241-14-2426" <HAUSEN%DBNGMD21.BITNET@MITVMA.MIT.EDU> Subject: Metrics on Specs, 4GL, 5GL We are working on the foundation of the assessment of software and trying to develop a generic software quality and productivity model. Current state of the art shows that there are a huge number of measures and metrics available, most of them are applicable only to the assessment of programs, i.e. programs which are written in procedural languages (Fortran, Ada, C, etc.). On the other hand there is also a need to assess results produced in the earlier stages of the development. Unfortunately one can't find so many measures or metrics appropriate for the assessment of requirements, functional specifications or even DB applications (4GL, DML, DDL, etc.). Therefore, we would greatly appreciate to receive any comment or text on the definition or application of measures and/or metrics on O software documentation written in natural language(s), O design specifications, O requirement specifications, O 4GLs, data definition languages, data manipulation languages or other linguistic means used in DB design and application, O software written in object-oriented languages (Smalltalk and the like), O software written in AI languages (Lisp, Prolog, OPS5, XPS-Languages), O test coverage for requirement specs, design specs or other non-procedural languages. O software written in other non-procedural language. From practitioners I would like especially to learn O what aspects of quality are of interest, O what aspects of productivity are of interest, O which objects should be measured. A drafted report on the quality model, called YAMOSQUAP (Yet Another Modelling Of Software Quality And Productivity) is available. An abstract is to be found below. H A N S - L U D W I G H A U S E N GMD Schloss Birlinghoven Telefax +49-2241-14-2889 D-5205 Sankt Augustin 1 Teletex 2627-224135=GMD VV West GERMANY Telex 8 89 469 gmd d E-mail hausen@dbngmd21.BITNET Telephone +49-2241-14-2440 or 2426 P.S.:GMD (Gesellschaft fuer Mathematik und Datenverarbeitung) German National Research Institute of Computer Science German Federal Ministry of Research and Technology (BMFT) .................................................................... YET ANOTHER MODELLING OF SOFTWARE QUALITY AND PRODUCTIVITY Hans-Ludwig Hausen, GMD, Schloss Birlinghoven, D-5205 St.Augustin 1, FRG Abstract Software engineering comprises construction, validation, measurement and assessment of software products and software projects. Software systems are often subdivided into the levels application concept, data processing concept and implementation. Evaluation, measurement and assessment have to take these three levels into consideration. Quality models have to consider active and passive elements of the software as well as dynamic characteristics on all three levels. Since software systems and software projects are unique quality models have to be flexible. The proposed scheme for quality modelling uses weight functions to define quality factors in terms of evaluation factors. The scheme may also be extented to cover productivity. A selected set of quality and evaluation factors is used to demonstrate the quality modelling procedure. With respect to three levels of software description a number of ratios are defined in order to describe software quantitatively. Using functions which reflect past experience, it becomes possible to generate estimates over the product extent and the production effort. Both the modelling scheme and the assessment scheme are effectively implementable. An abstract program defines the computation of the quality and productivity on a common scheme. ------------------------------ Date: 23 Feb 88 03:22:42 GMT From: maynard!campbell@think.com (Larry Campbell) Subject: Name Space Problem From article <3490002@otter.hple.hp.com>, by kers@otter.hple.hp.com (Christopher Dollin): > I'd go for "one-datatype-per-file". Spliting the files up using directories is > just a hack for controlling a growing namespace; NO existing language that I > know of has a decent solution for this (and if *you* know of one that does, > **please** let me know!). How about packages, as found (at least) in Common LISP and Ada? -- Larry Campbell The Boston Software Works, Inc. Internet: campbell@maynard.bsw.com 120 Fulton Street, Boston MA 02109 uucp: {husc6,mirror,think}!maynard!campbell +1 617 367 6846 ------------------------------ Date: 23 Feb 88 16:55:28 GMT From: otter!kers@hplabs.hp.com (Christopher Dollin) Subject: Name Space Problem > How about packages, as found (at least) in Common LISP and Ada? Well, those were the ones I was thinking of when I said that no existing language solved the problem! [BTW - I don't think you can compare the Ada and Lisp notions of packages, except as you can compare thumbscrews and drowning.] I don't think Ada even attempts to solve the problem. Correct me if I'm wrong, but isn't there a single flat namespace for modules? So how do I plug together different subsystems built independantly? The Common Lisp system has all sorts of problems. It packages symbols (words; names), not variables. The package namespace is flat. It has no notion of access control (you can grab the innards of any package without a declared intention to do do). It does not support transitive export of things. (If it did, you can bet that it wouldn't support *non*-transitive export). You can't rename across a import/export boundary to avoid name clashes. Etc. It's just like filing systems. They give you this way of separating files one from another, and Lo! make it hard to join them together again. That's why Unix has hard links. And symbolic links. And a tree structured hierarchy, or a DAG if you're super-user. And PATH. And CDPATH. And (csh) ~. And ......... PS No, Pop doesn't get it right either. Regards, Kers | "Why Lisp if you can talk Poperly?" ------------------------------ Date: 2 Mar 88 12:23:23 GMT From: mcvax!enea!sommar@uunet.uu.net (Erland Sommarskog) Subject: "Efficient" Implementation >How many novice Pascal programmers use many global vars because it saves >memory? On a paging system, though, you may need more pages in real memory >because of the way the chaining of variables is done in Pascal. This reminds me of when I did my exam work. My task was to do a capacity analysis of the file system of a 68000-based machine. Since this file system was quite buggy I had to check the sources to see what happened. The langauge used was EriPascal, a Pascal extention with Modula-2 module concept and real-time primitives. Nevin would have loved them. They used a lot of global variables. A typical procedure could have some local variables, but mostly they used the used the global ones, even for typical local purposes. To make it even more fun, all variables had one-letter prefixes like cnumber, cix etc. And on top of all, the modules were *huge*. 6000 lines or so. Now, was this a fast and speedy file system? Laugh. Reading a record from a 100 record-index file with variable-length fields could take 3 seconds. With a Winchester. No, no time-sharing. At disk-manager level, reading a specified block in a file was randomly distributed between 100 and 300 ms. Talk about poor algorithms. You should have seen the code for finding a particular block. In practice they counted on their fingers, making complicated a MOD for every decrement. Not takling of the procedure that allocated disk blocks. 27 Gotos into 150 lines of code. Yes, there was a bug in it. So moral: You may save some execution time by having your variables global, but you since you are obscuring your code so fatally, you will lose the notion of what you are doing and introduce bugs and inefficiencies instead. Oh, it should be added that the file system I talked of has since then been improved. I have no idea of how it works today. Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP ------------------------------ Date: 26 Feb 88 21:10:24 GMT From: trwrb!aero!venera.isi.edu!raveling@ucbvax.Berkeley.EDU (Paul Raveling) Subject: Requirements for a New Kernel >Isn't the real power of UNIX in that it >is an environment that encourages tool building? No. It REQUIRES tool building because the operating system itself doesn't offer good solutions to large sets of problems. >The only restriction that seems desireable is "LEAVE THE KERNEL ALONE!". Many of the problems with Unix can't be solved without a different kernel. I favor a substantially different kernel with a Unix compatibility layer over it to accommodate existing applications. I'd write new applications for the new kernel's native facilities. To pick a few examples: We need asynchronous i/o. What we did in EPOS was to issue a request as a signal (NOT like a Unix signal) to a device driver process; the device driver then issued an answering signal at completion. These signals included event data and were queued if the destination process wasn't ready for them. Lurking behind this terse description are about half a dozen things the Unix kernel can't do. We need GOOD interprocess communication. The only Unix mechanisms that are standard enough to have some hope to contribute are pipes and signals. There's nothing which efficiently communicates a small set of paramaters, such as those in typical C function calls, between processes. Unix signals don't queue event data, and pipes are slow -- our benchmarks show that either the setup overhead for pipe i/o or context switching is easily an order of magnitude slower than it should be. We need to share memory among processes in a multi-process application. There's no way to do this and keep application software portable between Unixes with different extensions. We need a single i/o interface with mutually consistent functions. We really don't want to have to check stream status, call Xpending, etc. before knowing it's safe to call select. In fact, it can never be totally safe to use select with streams or X connections without a polling time interval; if a context switch and input completion intervene between the stream/X connection check and the select, the select can leave the calling process blocked. We need to spawn processes without creating another copy of the entire address space (as in fork) and without having to fetch the new process from a disk file (as in vfork). The first part is especially important, since much of our project's software is Lisp running in a 40-megabyte address space, and we don't have enough swap space for another copy of it. I haven't even mentioned the question of user interfaces, but the problems there are equally dismal. Give Me Liberty or Give Me Unix! Paul Raveling Raveling@vaxa.isi.edu ------------------------------ End of Soft-Eng Digest ****************************** -------