From rbotting@wiley.csusb.edu Thu Dec 2 13:21 PST 1993 Return-Path: Received: from wiley.csusb.edu by silicon.csci.csusb.edu (5.0/SMI-SVR4) id AA15167; Thu, 2 Dec 93 13:21:09 PST Received: by wiley.csusb.edu (5.67a/1.34) id AA11215; Thu, 2 Dec 1993 13:23:16 -0800 Date: Thu, 2 Dec 1993 13:23:16 -0800 From: rbotting@wiley.csusb.edu ("Dr. Richard Botting") Message-Id: <199312022123.AA11215@wiley.csusb.edu> To: dick@silicon.csci.csusb.edu Subject: (fwd) BETA: frequently Asked Questions Newsgroups: comp.object Content-Type: text Content-Length: 49081 Status: RO Path: csus.edu!decwrl!decwrl!uunet!pipex!sunic!uts!news.daimi.aau.dk!jlk From: jlk@daimi.aau.dk (J|rgen Lindskov Knudsen) Newsgroups: comp.object Subject: BETA: frequently Asked Questions Date: 2 Dec 1993 11:10:43 GMT Organization: DAIMI, Computer Science Dept. at Aarhus University Lines: 1172 Message-ID: <2dkifj$k4i@belfort.daimi.aau.dk> Reply-To: jlknudsen@daimi.aau.dk (Jorgen Lindskov Knudsen) NNTP-Posting-Host: anne.daimi.aau.dk Summary: BETA: frequently Asked Questions Keywords: BETA, FAQ Please find enclosed the first posting of the BETA FAQ. This FAQ deals with the BETA language and the Mjolner BETA System. This FAQ is distributed to the BETA usergroup (usergroup@mjolner.dk), and the Usenet news groups comp.object, comp.lang.misc, comp.answers and news.answers. This first posting is by no means complete, and I'm looking forward to your comments, questions, suggestions, etc., which will be taken into the preparation for the next posting. Jorgen Lindskov Knudsen, Computer Science Department, Aarhus University Ny Munkegade 116, DK-8000 Aarhus C, DENMARK E-mail: jlknudsen@daimi.aau.dk, Phone: +45 89 42 32 33, Fax: +45 89 42 32 55 ------------------------------------------------------------------------------- Archive-name: beta-faq Last-modified: 29 November 1993 BETA: FREQUENTLY ASKED QUESTIONS -------------------------------- This question-and-answer list is posted regularly to the BETA mail group, and to the Usenet newsgroups comp.object, comp.lang.misc, comp.answers and news.answers. Please send corrections, additions and comments to Jorgen Lindskov Knudsen (jlknudsen@daimi.aau.dk). This information is abstracted and condensed from the posts of many different contributors. No guarantees are made regarding its accuracy. You can receive the latest copy by sending an email message to info@mjolner.dk with the following message body: send BETA beta-faq ---------- CONTENTS ======== PART I: Frequently Asked Questions ================================== Q01) What is BETA? Q02) Where did BETA come from? Q03) What BETA products are available? Q04) Are there any school or student discounts? Q05) Is BETA available in the public domain? Q06) What books are available for learning about BETA? Q07) Does an introduction to BETA besides the BETA book exist? Q08) Are any magazines or newsletters available concerning BETA? Q09) Are there any BETA user groups? Q10) Are there any mailing groups related to BETA? Q11) Is there an archive of the BETA mailing list? Q12) (Why) does a comp.lang.beta (not) exist? Q13) Are there any conferences for BETA users? Q14) Is BETA available on PC, Mac, NeXT, Amiga, Atari, ...? Q15) Are there standards for the BETA language? Q16) What is Mjolner, Sif, Valhalla, Bifrost, Yggdrasil, etc.? Q17) Is it possible to obtain an evaluation version of the Mjolner BETA System? PART II: Language Issues ======================== L01) What features does BETA have? L02) What changes have been made to the BETA language definition? L03) How do you deal with concurrency in BETA? L04) How do you deal with persistence in BETA? L05) How do you deal with distribution in BETA? L06) How do you deal with exception handling in BETA? L07) Can classes be treated as first-order elements in BETA? L08) What about garbage collection in BETA? L09) How do I create a "parameterized class"? PART III: Environment Issues ============================ E01) What is the Mjolner BETA System? E02) What does the Mjolner BETA System contain? E03) What libraries come with the Mjolner BETA System? E04) What frameworks come with the Mjolner BETA System? E05) What tools come with the Mjolner BETA System? E06) Does a beta-mode exist for Emacs? E07) Does an interactive manual for BETA exist? PART IV: Specific Issues ======================== SECTION I: The Fragment System ------------------------------ F01) What is the purpose of the fragment system? F02) How do I separate implementation and specification code? F03) How do I get around *****Only pattern-declarations may appear in a fragment of category 'attributes' F04) Why can't I have virtual declarations/bindings in attributes-fragments? F05) Why can't I have instances in attributes-fragments? F06) How do I make "include" files for reuse? SECTION II: The X libraries --------------------------- X01) Why does my label widget sometimes get the attribute name as label-string, and sometimes not? SECTION III: The BETA compiler ------------------------------ C01) What is the execution speed of BETA programs? C02) How do I get rid of the warning: "A run-time qualification check will be inserted here" ? C03) What *does* that Qua-check warning mean, anyway? C04) How do I work around "*****Repetition of non simple patterns is not implemented" ? C065 How do I work around "Labeled imperative not implemented"? SECTION IV: The Basic libraries ------------------------------- B01) How do you compare text strings in BETA? B02) How do you read and write text in BETA? B03) What is the rationale behind the Mjolner BETA System file directory structures? =============================================================================== PART I: Frequently Asked Questions =============================================================================== Q01) What is BETA? BETA is a modern object-oriented language with comprehensive facilities for procedural and functional programming. BETA has powerful abstraction mechanisms than provide excellent support for design and implementation, including data definition for persistent data. The abstraction mechanisms includes support for identification of objects, classification and composition. BETA is a strongly typed language (like Simula, Eiffel and C++), with most type checking being carried out at compile-time. The abstraction mechanisms include class, procedure, function, coroutine, process, exception and many more, all unified into the ultimate abstraction mechanism: the pattern. In addition to the pattern, BETA has subpattern, virtual pattern and pattern variable. BETA does not only allow for passive objects as in Smalltalk, C++ and Eiffel. BETA objects may also act as coroutines, making it possible to model alternating sequential processes and quasi-parallel processes. BETA coroutines may also be executed concurrent with supporting facilities for synchronization and communication, including monitors, and rendezvous communication. ---------- Q02) Where did BETA come from? BETA originates from the Scandinavian school of object-orientation where the first object-oriented language Simula was developed. Object-oriented programming originated with the Simula languages developed at the Norwegian Computing Center, Oslo, in the 1960s. The first Simula language, Simula I, was intended for writing simulation programs. Simula I was later used as a basis for defining a general purpose programming language, Simula 67 (later renamed to Simula). Simula has been used by a relatively small community for a number of years, although it has had a major impact on research in computer science. The BETA language development process started out in 1975 with the aim to develop concepts, constructs and tools for programming, partly based on the Simula languages. The BETA language team consists of Bent Bruun Kristensen, Birger Moller-Pedersen, Ole Lehrmann Madsen and Kristen Nygaard. Kristen Nygaard was one of the two original designers of the Simula languages. ---------- Q03) What BETA products and services are available? Currently there is only one supplier of BETA products, namely Mjolner Informatics, who is marketing an entire development system (the Mjolner BETA System) based on the BETA language. In US, the MADA organization is the distributor for the Mjolner BETA System. Mjolner Informatics offers the Mjolner BETA System technology to other commercial organizations, who is interested in building BETA products (such as alternative development systems) or who is interested in developing value-added products for the Mjolner BETA System. This offer is based on licensing of the implementation of the existing system (including source-code, if needed). Addresses: Mjolner Informatics MADA Developers Gustav Wiedsvej 12 10062 Miller Avenue, Suite 202-B DK-8000 Aarhus C Cupertino, CA 95014 Denmark USA Phone: +45 86 12 20 00 Phone: +1 408 253 2765 Fax: +45 86 12 20 22 Fax: +1 408 253 2767 E-mail: info@mjolner.dk Applelink: MADA ---------- Q04) Are there any school or student discounts? Mjolner Informatics offers discounts for educational purposes. ---------- Q05) Is BETA available in the public domain? The BETA language definition is in the public domain. However, no public domain implementations of the BETA language exists. ---------- Q06) What books are available for learning about BETA? The ultimate source of information on the BETA language is: Ole Lehrmann Madsen, Birger Moller-Pedersen, Kristen Nygaard: "Object-Oriented Programming in the BETA Programming Language" Addison-Wesley and ACM Press, 1993 ISBN 0-201-62430-3 The Mjolner BETA System and the BETA language is also extensively described in the book: Jorgen Lindskov Knudsen, Mats Lofgren, Ole Lehrmann Madsen, Boris Magnusson (eds.): "Object-Oriented Environments: The Mjolner Approach" Prentice-Hall, 1993 ISBN 0-13-009291-6 ---------- Q07) Does an introduction to BETA besides the BETA book exist? The previously mentioned book: "Object-Oriented Environments: The Mjolner Approach", contains a chapter, introducing the BETA language. Besides, various current activities indicates that such introductory material in the form of tutorials are underway. See also question Q08. ---------- Q08) Are any magazines or newsletters available concerning BETA? The BETA language has been presented in several conference papers, especially at the OOPSLA, ECOOP, and TOOLS conferences. Furthermore, BETA has lately been described in a couple of articles in Dr. Jobbs Journal, #206, October 1993. Mjolner Informatics produces an 8-page newsletter called "Mjolner BETA Newsletter" which will appear four times a year. ---------- Q09) Are there any BETA user groups? Yes, there is a user group, hosted by Mjolner Informatics. The user group is primarily organized around the BETA mailing list: usergroup@mjolner.dk The BETA user group is one of the important sources of information on the developments of the Mjolner BETA System, and an important source of information to Mjolner Informatics on the user's expectations for future developments. See also question Q10. ---------- Q10) Are there any mailing groups related to BETA? There is a mailing list for BETA, organized by Mjolner Informatics. The mailing list is: usergroup@mjolner.dk In order to be added to (or removed from) the mailing list, please send a mail to: usergroup-request@mjolner.dk ---------- Q11) Is there an archive of the BETA mailing list? Mjolner Informatics keeps an archive of the BETA mailing list usergroup@mjolner.dk (see above) ---------- Q12) (Why) does a comp.lang.beta (not) exist? We are constantly monitoring the net traffic on newsgroups, such as comp.object and comp.lang.misc, and in the event that the traffic on these newsgroups becomes substantial on issues related to the BETA language and the Mjolner BETA System, we will take initiative to the creating of a comp.lang.beta newsgroup. ---------- Q13) Are there any conferences for BETA users? There are no conferences, entirely devoted to then BETA language and development system. BETA shares the spotlight with other object-oriented languages including C++, Eiffel and Smalltalk in conferences like: TOOLS is the major international conference devoted to the applications of Object-Oriented technology. ECOOP is the European Conference on Object-Oriented Programming. OOPSLA is the major international conference on Object-Oriented Programming, Systems, Languages and Applications. ---------- Q14) Is BETA available on PC, Mac, NeXT, Amiga, Atari, ...? Currently, BETA is available on UNIX workstations, and on Macintosh. On UNIX, the platforms supported are: Sun Sparc (Sun OS, and Solaris) and HP 9000 series 300, 400 and 700. Even though it has not been officially confirmed by Mjolner Informatics, users of the Mjolner BETA System have reported that the Mjolner BETA System can be effectively used on Amiga 4000 machines if run under the MacOS simulator. The speed is reported to be comparable to a HP 9000/425 workstation. Currently, BETA is not available on PC, but work is currently being done on porting the Mjolner BETA System to Win32, which is the joint API for Windows NT and the future Windows 4.0. There are no current plans to port the Mjolner BETA System to neither DOS, nor Windows 3.1 due to the 16bit addressing and 8-character filename limitations. ---------- Q15) Are there standards for the BETA language? The definition of the BETA language is in the public domain. This definition is controlled by the original designers of the BETA language: Bent Bruun Kristensen, Ole Lehrmann Madsen, Birger M|ller-Pedersen and Kristen Nygaard. This means that anyone or any company may create a compiler, interpreter, or whatever having to do with BETA. The BETA and the Mjolner BETA System trademarks are owned and controlled by Mjolner Informatics. ---------- Q16) What is Mjolner, Sif, Valhalla, Bifrost, Yggdrasil, etc.? Many have wondered about the origins of the strange product names used for parts of the Mjolner BETA System. Due to the origin of the Mjolner BETA System, many of the components of the system bears Nordic names. These Nordic names originate from the Nordic Mythodology, and are thus names within the common cultural background of people in the entire Nordic region: Mjolner: is the name of the hammer of the god Thor. According to the Mythodology, this hammer is the perfect tool that cannot fail, that grows with the task, and always returns to the hand of Thor if he throws it at something. Yggdrasil: is the name of the tree of the world. The ash tree of which the crown covers the whole world. The tree gets it power from the gods, from the evil giants, and from the kingdom of the death. Everything in the world happens under the mighty crown of Yggdrasil. Yggdrasil is the name of the metaprogramming system. Bifrost: is the name of the luminous bridge, the rainbow, that leads from Midgaard to Asgaard. Midgaard is the place where the human beings live, and Asgaard is the habitat of the Gods in the middle of the world. Bifrost is the name of the graphics system. Valhalla: is the name of Odin's hall to where all dead warriors come when they have fallen as heroes on the battlefield. Valhalla is the name of the source-level debugger. Sif: is the name of the wife of Thor. Sif is famous for her golden hair. Sif is the name of the hyper structure editor. Freja: is the name of the goddess of love. She lives in Folkvang and is the most beautiful of all women in Asgaard. She owns the golden piece of jewelry Brisingemen. Freja is the name of the CASE tool. Odin: is the name of the highest ranking gods in Asgaard. Thor: is the name of the strongest of all gods, and Thor is the god for all peasants. He is the son of Odin and Frigg and lives together with his wife Sif in Trudvang on the farm Bilskirner which is the biggest house in the world, with 540 floors. ---------- Q17) Is it possible to obtain an evaluation version of the Mjolner BETA System? Mjolner Informatics offers a demo version of the Mjolner BETA System for the cost of media and shipment. It is possible to obtain the demo system through FTP (not anonymous FTP, though). Ask info@mjolner.dk for details. =============================================================================== PART II: Language Issues =============================================================================== L01) What features does BETA have? BETA replaces classes, procedures, functions and types by a single abstraction mechanism, called the pattern. It generalizes virtual procedures to virtual patterns, streamlines linguistic notions such as nesting and block structure, and provides a unified framework for sequential, coroutine and concurrent execution. The resulting language is smaller that Simula in spite of being considerable more expressive. The pattern concept is the basic construct. A pattern is a description from which objects may be created. Patterns describes all aspects of objects, such as attributes and operations, as seen in traditional object-oriented languages, but also aspects such as parameters and actions, as seen in procedures. Objects are created from the patterns. Objects may be traditional objects as found in other languages, but it may also be objects which correspond to procedure or function activations, exception occurrences, or even coroutines or concurrent processes. Objects may be created statically or dynamically and the objects are automatically garbage collected by the runtime system when no references exists to them any longer. Patterns may be used as super patterns to other patterns (the subpatterns). This corresponds to traditional class hierarchies, but since patterns may describe other types of objects, inheritance is a structuring means available also for procedures, functions, exceptions, coroutines and processes. Patterns may be virtual pattern. This corresponds to traditional virtual procedures but again the generality of the pattern construct imply that also classes, exceptions, coroutines and processes may be virtual. Virtual patterns in the form of classes is similar to generic templates in other languages. The prime difference being that the generic parameters (that is the virtual class patterns) may be further restricted without actually instantiating the generic template. The generality of the pattern also implies that genericity is available for classes, procedures, functions, exceptions, coroutines and processes. Patterns may be be handled as first-order values in BETA. This implies the possibility of defining pattern variables, which dynamically at runtime can be assigned pattern references. This gives the possibilities for a very dynamic handling of patterns at runtime. ---------- L02) What changes have been made to the BETA language definition? The BETA language definition have been stable for about three years, and no major changes are expected in the near future. ---------- L03) How do you deal with concurrency in BETA? The processes of BETA (concurrent objects) is based on a simple fork-mechanism and semaphores. Based on these mechanisms, pattern definitions are available for shared variables in the form of monitors, and for synchronous process communication based on a port communication metaphor. The abstractions also contain facilities for utilizing future values in connection with process interactions. ---------- L04) How do you deal with persistence in BETA? The Mjolner BETA System contains a library that implements a persistent store for BETA objects. Any BETA object can be stored into the persistent store, and subsequent obtained from the store in a type-safe way. There is no requirements that the persistent objects inherit from any specific superpattern, and persistent objects are fully type-checked both when saved in the persistent store, and when retrieved from the persistent store. ---------- L05) How do you deal with distribution in BETA? The Mjolner BETA System contains an experimental distributed object system in which BETA objects may reside on different hosts, and communicate transparently with each others, just as if they were residing on the same host. The objects may even be residing on different hosts (e.g. on Macintosh and Unix workstations, respectively). The distributed object system is expected to be included in one of the next major releases of the Mjolner BETA System. ---------- L06) How do you deal with exception handling in BETA? Exception handling is dealt with through a predefined library, containing basic exception handling facilities. The exception handling facilities are fully implemented within the standard BETA language in the form of a library pattern, and the usage is often in the form of virtual patterns, inheriting from this library pattern. ---------- L07) Can classes be treated as first-order elements in BETA? Yes, they can. This is possible by using the pattern variable construct in BETA. A pattern variable may dynamically be assigned pattern references. Pattern variables may be used to dynamically create instances of the pattern, currently contained in the pattern variable. ---------- L08) What about garbage collection in BETA? Garbage collection is conducted automatically by the BETA runtime system when it is discovered that no references exists to the object. The garbage collection mechanism is based on generation-based scavenging. The implemented garbage collection system is very efficient. ---------- L09) How do I create a "parameterized class"? A parameterized class (a template in C++ or a generic class in Eiffel) is created in BETA by using the virtual pattern mechanism. The generic parameter is specified as a virtual attribute of the pattern, and subpatterns of this patterns may now make further restrictions on the generic parameter by further binding the virtual attribute. Generic instantiation is done by either making a final binding of the virtual attribute, or by instantiating an object directly from the pattern. =============================================================================== PART III: Environment Issues =============================================================================== E01) What is the Mjolner BETA System? The Mjolner BETA System is an integrated and interactive general-purpose software development environment that supports industrial strength programming using object-oriented programming in the BETA programming language. ---------- E02) What does the Mjolner BETA System contain? The Mjolner BETA System includes an implementation of the BETA language, a series of libraries and application frameworks, a set of development tools, and a metaprogramming system. All components of the Mjolner BETA System are constructed using the BETA language. Major parts of the Mjolner BETA System (e.g. the editor, parser, pretty-printer, metaprogramming system, fragment system) are grammar-based in the sense that tool generators exist that, given a specific grammar for a language, will define a specific tool that is able to manipulate programs written in that particular language. ---------- E03) What libraries come with the Mjolner BETA System? Basic libraries The basic patterns are the object-oriented variants of the standard simple data types, such as char, boolean, integer and real. These patterns make it possible to treat e.g. integers as ordinary objects. The basic patterns also includes the Object patterns, which is the implicit superpattern for all patterns that have no explicit superpattern. The Stream Patterns A Stream is a generalization of internal and external text objects. An internal text object (Text) is a sequence (repetition) of chars. An external text object (File) corresponds to a traditional text file. Stream, Text and File are organized in the following hierarchy: Stream: (# ... #); Text: Stream(# ... #); File: Stream(# ... #); UnixFile: File(# ... #); MacFile: File(# ... #); As part of the interface to the operating system, the basic libraries include patterns for accessing the directory structures of hierarchical file systems: Directory: (# ... #); UnixDirectory: Directory(# ... #); MacDirectory: Directory(# ... #); The Process Patterns The Process interface facilitates execution of subprocesses, communication between several independent processes, client/server architectures, and it is even possible to establish communication between Unix and Macintosh processes. The External Language Interface Patterns To enable interfacing into external languages (such as C), the basic libraries defines the external, cStruct, and externalRecord patterns. Container libraries The standard container data structures are organized in the following inheritance hierarchy of patterns: container _________________|_______________________ | | | | collection arrayContainer list sequentialContainer ______|_______ ___________|_______________ | | | | | | multiset hashTable stack queue deque prioQueue | | set extensibleHashTable __|_____________________ | | classificationSet classificationSubSet Container patterns are generic patterns in the sense that the element type of the elements kept in the container can vary between different container instances. Persistent store: Support for saving any kind of object generated by a BETA program execution on secondary storage and restoring them in another BETA program execution. The persistent store is fully type safe. An object-oriented database for BETA objects is currently under development. Metaprogramming system libraries: A metaprogram is a program that manipulate other programs. Yggdrasil is a metaprogramming system, that supports creation of metaprograms. Yggdrasil is grammar based: a metaprogramming environment may be generated from the grammar of any language The metaprograms manipulate programs through a common represen- tation called abstract syntax trees (ASTs) An AST is modelled as an instance of a pattern. There is a pattern corresponding to each syntactic category (non-terminal) of the grammar. The grammar hierarchy is modelled by a corresponding pattern hierarchy, derived automatically from the grammar. ---------- E04) What frameworks come with the Mjolner BETA System? Concurrency framework The basic libraries defines various patterns for dealing with concurrency, synchronization and communication. These patterns are: system, semaphore, fork, monitor, port, restrictedPort, objectPort, qualifiedPort, conc, and alt. X Window System framework The Mjolner BETA object oriented interface to the X Toolkit Intrinsics (Xt) is called XtEnv. This pattern contains the basic patterns common for many user-interface toolkits build upon the X Window System, but it does not contain any higher level user interface elements. It is typically used together with a widget set containing such user interface elements build on top of it. Examples of such widget sets are the Athena Widgets, OPEN LOOK, and Motif. The Mjolner BETA system currently includes object- oriented interfaces to the Athena Widgets (AwEnv) and to Motif (MotifEnv). Macintosh Toolbox framework MacEnv is a family of libraries abstracting the Macintosh Toolbox into an object-oriented framework. Every object in the Macintosh user interface, like windows and menus, has a corresponding BETA pattern definition in MacEnv. In order to create, say, a new window, you just create an instance of the Window pattern and tell it to display itself. All the other Macintosh user interface objects can be created and displayed in the same way. User defined objects like dialog boxes, are easily created by specializing the Dialog pattern, and using the various Control patterns defined in MacEnv. MacEnv includes a series of predefined patterns for making text editors, scrolling windows with pictures, object-oriented graphics with QuickDraw, easy interface to the Macintosh resources, files, clipboard, sound, and QuickTime. Bifrost graphics framework The interactive object-oriented graphics system Bifrost is based on the Stencil & Paint imaging model. Bifrost models computer graphics images by abstracting the geometric and color properties of graphical objects. The important new concept introduced in Bifrost is that there is one basic drawing primitive, the graphical object. The graphical object unite interaction, graphics modelling and graphics context. Bifrost includes extensive support for various kinds of interaction: interactive creation, reshaping, translation, scaling, and rotation of graphical objects. The object-oriented approach makes extensibility and tailorability a simple task, and facilitates object-oriented drawing applications. One of the main goals of the development of Bifrost was to make the graphics system independent of underlying graphics and hardware systems. Distribution framework A distributed object system is currently being developed. OODB framework A distributed object-oriented database system for BETA objects is currently being developed. ---------- E05) What tools come with the Mjolner BETA System? BETA compiler The BETA compiler is a native code generation compiler. Fragment system The fragment system is used for splitting BETA programs into smaller pieces (fragments). The fragment system is responsible for the dependencies between different fragment files, defining a given library or program. Due to the generality of the fragment system, a BETA program can be divided into smaller pieces in many different ways. Source-level debugger A source-level debugger for the BETA language is available on the Unix platform. It contains facilities for specifying break- points, single stepping, inspection of object states, inspecting the run-time organization, etc. The debugger uses a graphical interface running under the X Window System. Hyper structure editor The Mjolner BETA Hyper Structure Editor has the following properties: Syntax-directed editing Syntax directed editing makes it possible to construct and edit programs or other documents without introducing syntax errors. Syntax-directed editing is especially useful for application- oriented languages intended for end-users, casual users and beginners that may have difficulties in remembering the concrete syntax. Abstract presentation and browsing The editor is able to present a program at any level of detail. At the top-level of a program the user may get an overview of classes and procedures. It is then possible to browse through modules and procedures to see more and more details. Adaptive pretty-printing The editor includes an adaptive pretty-printing algorithm which prints the program or document such that it always fits within the size of the window or paper. Text editing and incremental parsing The programmer may freely alternate between syntax directed editing and textual editing. Any program part may be textually edited using keyboard, mouse and menus in the usual style known from the Macintosh or the X Window System, respectively. Any program part that has been textually edited is immediately parsed. Fragment manipulation and browsing The editor provides an interface to the fragment system. It is possible to browse in the fragment structure and to create and combine fragments. Integration of program and documentation The user may add a comment at any place in a program. The user decides whether or not to display a comment. Also the user decides whether to display a comment as part of the program or in another window; in the latter case a comment is indicated by means of (*). Using abstract presentation it is possible to obtain a pretty- print of a program which includes just the classes and procedure headings and corresponding comments. This makes it possible to extract a functional specification from the program. Hypertext facilities The editor includes hypertext facilities. The facility for handling comments is an example of a hyperlink between a program and a text document. Another type of hyperlink is a link from the use of a name to the declaration of the name (this is only implemented for BETA). Object-oriented CASE tool The Mjolner BETA CASE Tool provides - graphical structure editing of design diagrams - textual structure editing of programs - automatic program generation from design diagrams - reverse engineering from programs to design diagrams - simultaneous editing of design diagrams and programs No CASE gap: One single abstract language is used throughout analysis, design and implementation. Different concrete syntaxes are used to present the different models: - graphical syntax for design - textual syntax for programs. The CASE tool is currently only a demonstration prototype. Metaprogramming tools Supplementing the metaprogramming libraries, there is a number of grammar-based tools as part of the metaprogramming system, such as compiler-compiler, parser, pretty-printer, and the hyper structure editor is also grammar-based, such that it is possible to customize it towards specific grammars. ---------- E06) Does a beta-mode exist for Emacs? Yes, an emacs mode for editing BETA programs is part of the Mjolner BETA System. This beta-mode is in public domain and can be obtained by sending an e-mail to support@mjolner.dk ---------- E07) Does an interactive manual for BETA exist? Yes. Based on the hyper-structure editor, an experimental, interactive manual system exists for the libraries and frameworks of the Mjolner BETA System. The manual does not yet contain all relevant Mjolner BETA System manuals. =============================================================================== PART IV: Specific Issues =============================================================================== ------------------------------ SECTION I: The Fragment System ------------------------------ F01) What is the purpose of the fragment system? The purpose of the fragment system is to enable modularization of BETA programs. The fragment system also supports separate compilation, dependency analysis of modules, information hiding and separation of specification and implementation modules. The fragment system also enables the co-existence of different implementations of the same specification, depending on the target machine type (on the same file system), and automatic selection of the proper variant for the specific machine type. The fragment system is based on the slot and fragment metaphors. A slot is an specification in some source code which signifies that separately compiled source code may be associated with that place. A fragment is a piece of source code, that can be separately compiled, and associated with some slot. The fragment system takes care of the slots and fragments, and the connections between slots and fragments. Several different combination rules exists in the fragment system, enabling the specification of different modularization relations. ---------- F02) How do I separate implementation and specification code? Let us assume, that we has the following source code: ORIGIN '...' --- lib: attributes --- f: (# t: @text; i,j: @integer; r: @real enter t[] do (* ... some code implementing f ... *) #) This source code is assumed to reside in some source code file called fSource.bet. If we want to separate the implementation and the specification, we can do the following change to fSource.bet: ORIGIN '...' BODY 'fBody' --- lib: attributes --- f: (# t: @text; i,j: @integer; r: @real enter t[] <> #) That is, we have replaced the implementation with a slot specification. We now create another source file; let's call it fBody.bet: ORIGIN 'fSource' --- fBody: dopart --- do (* ... some code implementing f ... *) As can be seen, we have now modularized the implementation away from the specification (except for the i,j, and r attributes (see F04 below). ---------- F03) How do I get around *****Only pattern-declarations may appear in a fragment of category 'attributes' In F02, we didn't get rid of the i, j, r implementation attributes of f. The reason is, that it is not possible to do the most obvious, which would have been the following: fSource.bet: ORIGIN '...' BODY 'fBody' --- lib: attributes --- f: (# t: @text; <> enter t[] <> #) fBody.bet: ORIGIN 'fSource' --- fLib: attributes --- i,j: @integer; k: @real --- fBody: dopart --- do (* ... some code implementing f ... *) since it is not allowed to specify reference attributes (static or dynamic) in attribute slots. Instead we have to use the following trick: fSource.bet: ORIGIN '...' BODY 'fBody' --- lib: attributes --- f: (# t: @text; fprivate: @<> enter t[] <> #) fBody.bet: ORIGIN 'fSource' --- fLib: descriptor --- (# i,j: @integer; r: @real #) --- fBody: dopart --- do (* ... some code implementing f ... *) and in (* ... some code implementing f ... *) we have to change all references to i, j, and r to fprivate.i, fPrivate.j, and fprivate.r. ---------- F04) Why can't I have virtual declarations/bindings in attributes-fragments? Allowing virtual declarations and virtual bindings in attribute forms makes separate compilation of fragments very difficult due to problems in calculating the size of objects being allocated - if these objects have attributes, that are allocated from a virtual pattern, which may be further bound in some attribute form, which are compiled later. Possible solutions are currently being investigated by Mjolner Informatics. ---------- F05) Why can't I have instances in attributes-fragments? The problem is very similar to the problems discussed in F04, and also here are possible solutions being investigated by Mjolner Informatics. ---------- F06) How do I make "include" files for reuse? It's important to note, that the fragment system INCLUDE mechanism is radically different from e.g. the C compilers #include facility. The C #include mechanism is merely a means for textual composition, without any semantical implication. The fragment system INCLUDE mechanism is a semantical, separate compilation facility, and at the same time it described parts of the dependency relations between the program parts. ---------- --------------------------- SECTION II: The X libraries --------------------------- X01) Why does my label widget sometimes get the attribute name as label-string, and sometimes not? Example: The following BETA program result in a window with the content "Label" ORIGIN '~beta/Xt/current/awenv' --- PROGRAM: descriptor --- AwEnv (# Hello: @Label; do Hello.init; #) whereas this program results in a window with the content "Hello" ORIGIN '~beta/Xt/current/awenv' --- PROGRAM: descriptor --- AwEnv (# Hello: @Label(##); do Hello.init; #) Why? Answer: The connection between the names used for widgets in BETA and the external names used in the external widgets interfaced to from BETA is that the *pattern name* of the BETA widget is used for the external widget name by default. In the first example the Hello widget is an instance of the pattern Label, and in the second example the widget is the only possible instance of the singular pattern Label(##), which is named Hello. The appearance of the windows in this case comes from the fact that the Athena Label widget uses the external name of the widget as default label-string, if it is not specified otherwise. ------------------------------ SECTION III: The BETA compiler ------------------------------ C01) What is the execution speed of BETA programs? For average programs, the execution speed of typical BETA programs are comfortable. However, there are many possibilities for optimization in the current BETA compiler, the generated code, and the run-time system. Mjolner Informatics is constantly working on improving the execution speed of BETA. ---------- C02) How do I get rid of the warning: "A run-time qualification check will be inserted here" ? By using the -q or -w options to the compiler: "beta -q ..." or "beta -w ..." ---------- C03) What *does* that Qua-check warning mean, anyway? If you have: (# Vehicle: (# ... #); Bus: Vehicle(# ... #); aVehicle: ^Vehicle; aBus: ^Bus do ... aVehicle[]->aBus[] ... #) the compiler will give a Qua-check warning at the 'aVehicle[]->aBus[]'. The reason is, that aBus can only refer to objects, which are instances of a pattern that is a subpattern of Bus (or is a Bus). But aVehicle may refer to all objects which are instances of a pattern that is a subpattern of Vehicle (or is a Vehicle) - that is, not necessary Bus. The BETA runtime system therefore inserts a test, that the object aVehicle[] actually is referring to, is an instance of a pattern that is a subpattern of Bus (or is a Bus) - otherwise a runtime error occurs. The Qua-warning is specified to direct your attention towards these places for potential runtime errors. ---------- C04) How do I work around "*****Repetition of non simple patterns is not implemented" If you want to write: persons: [100]@person (which is not implemented), you should instead write: persons: [100]^persons and then before you start using the persons repetition, just initialize by: (for i: persons.range repeat &person[]->persons[i][] for) then you can use persons in the rest of the program, just as if it were declared as a repetition of static person. ---------- C05) How do I work around "Labeled imperative not implemented"? If you want to write: (L: Imp1; Imp2; ... Impi :L) (which is not implemented), you should instead write: L: (# do Imp1; Imp2; ... Impi #) In fact, the (L: ... :L) construct is being considered for exclusion from the BETA language due to the very simple replacement shown above. ------------------------------- SECTION IV: The basic libraries ------------------------------- B01) How do you compare text strings in BETA? Let's assume, that we have: t1, t2: @text; Then: t1[]->t2.equal returns true, if t1 and t2 are equal, and t1[]->t2.equalNCS returns true, if t1 and t2 are equal (ignoring case). ---------- B02) How do you read and write text in BETA? Texts are written onto standard output by: 'hello'->screen.puttext; which writes the string 'hello' on the screen at current cursor position. 'hello'->screen.putline; also writes a carriage-return. E.g. integers are written by: 7->screen.putInt; If you want to write onto other text variables (such as t: @text), you can do it by: 'hello'->t.puttext; 'hello'->t.putline; 7->t.putInt; Reading texts are equally easy: keyboard.getline->s[]; reads a line of text from the keyboard, and assign a reference to the read text to the text reference s (assumed declared as s: ^text). Reading from other texts (e.g. t) is done by: t.getline->s[]; ---------- B03) What is the rationale behind the Mjolner BETA System file directory structures? This note describes the file structure of the Mjolner BETA System. The note intends to illustrate as an advise on the most efficient way to structure the files of a BETA development project. At the same time, this file structure is used all over the existing Mjolner BETA System to structure the various subsystems of the Mjolner BETA System. Let us assume, that the development project is called odin, and that it consists of (at least) three subprojects, called brage, vidar and vale. We would then define the following file structure (brage/ indicates that brage is the name of a subdirectory): odin --+-- brage/ | +-- vidar/ | +-- vale/ Each of the three subprojects may exists in different versions, reflecting the development history. These versions are kept in separate subdirectories for each subproject. Let us illustrate with vidar (having versions 1.0, 1.1, and 1.2): vidar -+-- v1.0/ | +-- v1.1/ | +-- v1.2/ A configuration of odin now consists of the combination of the corresponding versions of the subprojects. Each version of each subproject has the following directory structure (here illustrated with the 1.1 version): v1.1 --+-- F1.bet | +-- F2.bet | +-- ... | +-- Fn.bet | +-- private/ | +-- demo/ | +-- test/ | +-- (* group files *) | +-- (* code directories *) The Fi.bet files contains the public interface files for the v1.1 version of the subproject. The private subdirectory contains the implementation fragments for the Fi.bet interface files (see later). The demo subdirectory will contains demo programs illustrating the usage of this subproject. The test subdirectory will contains programs for testing the functionality of this subproject. The (* group files *) indicates, that there will be a Fi.group file for each Fi.bet, containing the abstract syntax tree (AST) representation of the Fi.bet. The (* code directories *) indicates, that there will be one subdirectory for each machine type. Currently, the possible subdirectories are: sun3, sun4, sun4s, hp, hpux8, hpux9, snake, mac. There may be one subdirectory of each machine type. The substructure consisting of (* group files *) and (* code directories *) are shared by ALL directories, containing compiled BETA source files, and will therefore not be mentioned further below. The demo and test subdirectories may be further structures, possibly with a subdirectory for each interface file Fi, but can also follow any other structure. The private subdirectory is divided into the following substructure: private -+-- F1Body.bet | +-- F2Body.bet | +-- ... | +-- FnBody.bet | +-- external/ | +-- (* group files *) | +-- (* code directories *) where FiBody.bet contains the implementation fragments for the interface files. The FiBody.bet files may be machine-independent implementations, or machine-dependent implementations. The FiBody.bet files therefore follow the following naming convention: FiBody.bet is the name of a machine-independent implementation Fi_macBody.bet is the name of a machine-dependent implementation (here for macintosh) In most cases, there exists one implementation file for each interface file, but for large (or complex) interface files, multiple implementation files may exist. (apart from the different machine dependent implementation files). The external subdirectory contains non-BETA source files (such as C source code), and other files, which are not used directly by the Mjolner BETA System, such as Makefiles etc. The directory structure of external follows the conventions of the non-BETA system used (e.g. the C compiler etc.). -- Jorgen Lindskov Knudsen, Computer Science Department, Aarhus University Ny Munkegade 116, DK-8000 Aarhus C, DENMARK E-mail: jlknudsen@daimi.aau.dk, Phone: +45 89 42 32 33, Fax: +45 89 42 32 55 -- rbotting@wiley.csusb.edu. rbotting::=`Dr. Richard J. Botting`, wiley::=`Faculty EMail System`, csusb::=`California State University, San Bernardino, CA 92407, USA`. cookie::= "Once a scientist then a computer scientist, then a software process engineer!".