Path: news.daimi.aau.dk!jacobse From: jacobse@daimi.aau.dk (Jacob Seligmann) Newsgroups: comp.lang.beta Subject: BETA Language Frequently Asked Questions (FAQ) Date: 7 Sep 1994 11:26:46 GMT Organization: DAIMI, Computer Science Dept. at Aarhus University Lines: 1675 Expires: 30 Sep 1994 12:00:00 GMT Message-ID: <34k81m$2kj@belfort.daimi.aau.dk> NNTP-Posting-Host: clematis.daimi.aau.dk Archive-name: beta-language-faq Last-modified: September 6, 1994 Version: 1.2 Maintained-by: Jorgen Lindskov Knudsen BETA: Frequently Asked Questions (FAQ) This question-and-answer list is posted regularly (approx. bimonthly) to the BETA mail group, and to the Usenet newsgroups comp.lang.beta, 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 of the BETA FAQ by sending an email message to info@mjolner.dk with the following message body: send BETA beta-language-faq The BETA FAQ is also available via anonymous ftp to ftp.daimi.aau.dk in the pub/beta/ directory as beta-language-faq.txt, and through the World Wide Web (WWW) at: http://www.daimi.aau.dk/~beta/beta-language-faq.html. The WWW site will always contain the most updated version of the BETA FAQ. More information on the BETA language and the Mjolner BETA System can be found at: http://www.daimi.aau.dk/~beta/info. Changes since last FAQ New entries: L10) Difference between virtual, further, and final bindings L11) Invariants in BETA L12) Change propagation in BETA L13) Futures in BETA L14) Visibility of names in INNER F07) Compiler not complaining about a missing inner in body fragments C06) Problems with BETA program called test.bet on UNIX C08) Difference between P and &P B03) Problems with getInt followed by getLine B05) Meaning of (* idx+ *), etc. Changed entries: Q03) New distributors Q12) comp.lang.beta newsgroup now exists Q14) BETA now available on Linux F04) Improved description F05) New description of logical problem C07) How to permanently disable qualification check warnings 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 concerning BETA available? 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) Does a BETA newsgroup 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 do BETA have? L02) What changes have been made to the BETA language definition? L03) How do I deal with concurrency in BETA? L04) How do I deal with persistence in BETA? L05) How do I deal with distribution in BETA? L06) How do I 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"? L10) What is the differences between a virtual binding, a further binding and a final binding (i.e. between :<, ::<, and ::)? L11) What about invariants in BETA? L12) What about change propagation in BETA? L13) What about futures in BETA? L14) Why can't local variables be accessed in INNER? 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 for Emacs exist? 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 work around "*****Only pattern-declarations may appear in a fragment of category 'attributes'"? F04) Why can't I have instances in attributes-fragments? F05) Why can't I have virtual declarations/bindings in attributes-fragments? F06) What are the differences between the INCLUDE facilities of BETA and C? F07) Why doesn't the compiler complain about a missing inner in a body fragment? 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"? C05) How do I work around "Labeled imperative not implemented"? C06) Why does a BETA program called test.bet cause problems on some UNIX installations? C07) How do I disable qualification check warnings? C08) What is the difference between P and &P? 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) Why does getInt followed by getLine not necessarily work as expected? B04) What is the rationale behind the Mjolner BETA System file directory structures? B05) What do the (* idx+ *), etc. comments mean? 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 include 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 concurrently with supported 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 Software Frameworks Association is the distributor for the Mjolner BETA System, and ObjectLand is the distributor for the Mjolner BETA System in France, French part of Belgium, and French part of Switzerland. 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). Mjolner Informatics Gustav Wieds Vej 10 DK-8000 Aarhus C Denmark Phone: +45 86 12 20 00 Fax: +45 86 12 20 22 E-mail: info@mjolner.dk Software Frameworks Association (SFA) 599 N Mathilda Ave, Suite 135 Sunnyvale, CA 95086-3507 USA Phone: +1 (408) 245-0571 Fax: +1 (408) 245-0570 E-mail: info@frameworks.org ObjectLand 26 rue Jules Lannery F-59240 Dunkerque France Phone: +33 28 65 90 35 Fax: +33 28 59 36 46 E-mail: Laurent.Debrauwer@lifl.fr AppleLink: DEBRAUWER CalvaCom: LD85 Q04) Are there any school or student discounts? Mjolner Informatics offers substantial 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 exist. 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 an introductory chapter on the BETA language. Besides, various current activities indicate that introductory material in the form of tutorials are in the pipeline. See also question Q08. Q08) Are any magazines or newsletters concerning BETA available? The BETA language has been presented in several conference papers, including the OOPSLA, ECOOP, and TOOLS conferences. BETA has also been described in a couple of articles in Dr. Dobb's Journal, #206, October 1993. Furthermore, Communications of the ACM, Vol. 37, No. 2, February 1994, is a special issue on Hypermedia, including three papers on the use of the Mjolner BETA System (and the BETA language) for building hypermedia systems. Mjolner Informatics produces a quarterly 8-page newsletter called "Mjolner BETA Newsletter". 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 users' 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 question Q10). Q12) Does a BETA newsgroup exist? Yes. The newsgroup comp.lang.beta is available for discussing issues related to the BETA language. The newsgroup was accepted in August 1994, and it is expected that some of the BETA mailing lists will be cancelled in the near future, moving the discussion to comp.lang.beta instead. Q13) Are there any conferences for BETA users? There are no conferences devoted entirely to the BETA language and development system. BETA shares the spotlight with other object-oriented languages including C++, Eiffel, and Smalltalk in conferences like: TOOLS the major international conference devoted to the applications of Object-Oriented technology. ECOOP the European Conference on Object-Oriented Programming. OOPSLA 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). As of release 3.0, the Mjolner BETA System is also available for Linux (386/486/Pentium). Linux is a very popular freely available UNIX implementation for Intel processors. Although not 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 under the MacOS simulator, with an execution speed reported to be comparable to that of an HP 9000/425 workstation. Except for the Linux implementation, BETA is not currently available on the PC. However, alpha versions of the Mjolner BETA System for Win32 exist. Win32 is the joint API for Windows NT and the future Windows 4.0 (Chicago). Release of this port will become official in the near future. There are no current plans to port the Mjolner BETA System to neither DOS nor Windows 3.1 due to the 16-bit 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 Moller-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 bear Nordic names. These Nordic names originate from the Nordic Mythology, 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 Mythology, 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. Finally about the pronunciation of Mjolner. For English people the "spelling of the pronunciation" could be: "Myolner" or "Myulner", and for French people it could be: "Mieulnor". 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 dead. 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 god in Asgaard. Thor: is the name of the strongest of all gods. He 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 do 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 than Simula in spite of being considerably more expressive. The pattern concept is the basic construct. A pattern is a description from which objects may be created. Patterns describe 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 they 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 exist to them any longer. Patterns may be used as superpatterns 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. This corresponds to traditional virtual procedures but again the generality of the pattern construct implies that also classes, exceptions, coroutines, and processes may be virtual. Virtual patterns in the form of classes are similar to generic templates in other languages. The prime difference is 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 can be assigned pattern references dynamically at runtime. 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 has been stable for about three years, and no major changes are expected in the near future. L03) How do I deal with concurrency in BETA? The processes of BETA (concurrent objects) are 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 I 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 are no requirements that the persistent objects must 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 I 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 host types (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 I 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 to the object exist. 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. L10) What is the differences between a virtual binding, a further binding and a final binding (i.e. between :<, ::<, and ::)? To illustrate the difference between new and further-bindings, consider p: (# v:< (# do ...; inner #) #); q: p(# v::< (# do ... #) #); r: p(# v:< (# do ... #) #); in which a pattern p with a virtual attribute v, and two subpatterns, q and r, are declared. Pattern q further-binds p's virtual attribute, while pattern r declares a new virtual attribute v which has no connection to p's v, except that it happens to have the same name. [This may or may not be what the programmer intended, so perhaps a warning should be issued in this case.] Thus, if rp is a pointer of type p, and rp happens to denote a q object, then calling rp.v will cause q's v part to be executed in addition to p's (because v has been further-bound in q). However, if rp denotes an r object, then calling rp.v will cause only p's v part to be executed, not r's (because p's v attribute has not been further-bound). [Of course, if rr denotes a pointer of type r, then rr.v will cause r's v part to be executed.] A final binding has the same effect as a further-binding, except that it specifies that the virtual may not be further-bound from this point on. There are (at least) three different reasons why you might want to use final bindings: Modelling: Final-bindings are often considered to be a nice feature from a purely object-oriented modelling perspective since it indicates that the model is no longer extensible with respect to this attribute. Efficiency: The compiler is able to generate tighter code when it is known that a pattern is not virtual (any longer). Inheritance: It is not allowed to inherit from a virtual pattern; but it is ok to inherit from a final-bound one. L11) What about invariants in BETA? Invariants are not an integrated part of the BETA language. However, it is possible to create an invariant system as a framework or library, entirely written in BETA. In the Mjolner BETA System, an experimental invariant system is available. The system offers class invariants as well as pre- and post-conditions for operations. The invariant system also offers the ability to control whether the invariants are checked or not, either on individual object basis or system-wide. L12) What about change propagation in BETA? Change propagation (as in Model-View-Control - MVC) is also available in BETA (with extended facilities). Change propagation is available as an experimental part of the current system. L13) What about futures in BETA? Futures are used in concurrent programming to return results from a concurrent computation, even before they have been calculated. The result can then be passed around as any other value, and only when an attempt is made to access it, the reader will be blocked until the result is made available by the concurrent computation. Based on the existing BETA facilities, futures can easily be implemented, and an experimental futures library is available as part of the current system. L14) Why can't local variables be accessed in INNER? Consider the following code fragment: P: (# do (# x: ... do inner P #) #) PP: P(# do ... #) According to the BETA visibility rules, x may not be referenced from the do-part of PP. Why? The answer lies in the fact that patterns may have more than one inner section. Consider the following (slightly modified) example, where inners are placed in different inserted descriptors, each containing declarations of different sets of local variables: P: (# do (# x: ... do inner P #); (# y: ... do inner P #) #) PP: P(# do ... #) In this case, the do-part of PP is executed twice via inner, but with different sets of local variables (x and y, respectively). It is therefore meaningless to refer to any one of these in the do-part of PP. 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 pattern 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 with external languages (such as C), the basic libraries define 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 sequentialContainer list ______|_______ ___________|_______________ | | | | | | 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 manipulates 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 representation 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 define 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 built 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 built 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 unites 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 through 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: A 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. Being grammar-based, it is possible to customize them all towards specific grammars. E06) Does a beta-mode for Emacs exist? Yes, an Emacs mode for editing BETA programs is part of the Mjolner BETA System. This beta-mode is in the 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 a specification in the source code which signifies that separately compiled source code may be associated with that place. A fragment is a piece of source code which can be separately compiled, and associated with a slot. The fragment system takes care of the slots and fragments, and the connections between them. Several different combination rules exist 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 a source code file called fSource.bet. If we want to separate the implementation and the specification, we can make 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 question F05). F03) How do I work around "*****Only pattern-declarations may appear in a fragment of category 'attributes'"? In F02, we didn't get rid of the i, j, and 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; r: @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 instances in attributes-fragments? Allowing instances in attribute forms makes separate compilation of fragments very difficult due to problems in calculating the size of objects being allocated from the descriptor in which the fragment form is bound (to a slot). E.g. fSource.bet: ORIGIN '...' --- lib: attributes --- f: (# t: @text; <> enter t[] <> #) fUsage.bet: ORIGIN '...' --- INCLUDE 'fSource' --- program: descriptor --- (# foo: @f do (* ... usage of foo ... *) #) fImpl1.bet: ORIGIN 'fSource' --- fLib: attributes --- i,j: @integer; r: @real --- fBody: dopart --- do (* ... some code implementing f ... *) fImpl2.bet: ORIGIN 'fSource' --- fLib: attributes --- i,j,k: @integer; r, s: @real --- fBody: dopart --- do (* ... some code implementing f ... *) fProg1.bet: ORIGIN 'fUsage'; BODY 'fImpl1' fProg2.bet: ORIGIN 'fUsage'; BODY 'fImpl2' When compiling the fUsage.bet fragment separately, it is impossible to pre-calculate the size of the foo object, since foo will contain i,j,r in fProg1.bet, whereas foo will contain i,j,k,r,s in fProg2.bet. A solution to this problem is being investigated by MIA, but there are no plan for when this will be supported. F05) Why can't I have virtual declarations/bindings in attributes-fragments? There are two problems in allowing virtual declarations in attribute fragments. The first problem is a logical problem. Consider: fSource.bet: ORIGIN '...' --- lib: attributes --- A: (# V:< T; ... #); B: (# <> ... #); C: (# V::< T1; ... #) fUsage.bet: ORIGIN 'fSource' --- Blib: attributes --- V::< T2 The problem is, that when doing the semantic checking of V::< T1 in C, it is impossible to know the further binding in the fUsage.bet fragment, since it may be compiled after the compilation of the fSource.bet fragment. Thus it is impossible to ensure, that the further binding in C is in fact legal (to be legal, T1 must be a subpattern of T and all further bindings that might appear in all fragments later bound to the Blib slot. The second problem is in calculating the size of the virtual dispatch table, if declaration of new virtuals were allowed in fragments bound to the Blib slot. F06) What are the differences between the INCLUDE facilities of BETA and C? It is 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's INCLUDE mechanism is a semantical, separate compilation facility, and at the same time it describes parts of the dependency relations between the program parts. F07) Why doesn't the compiler complain about a missing inner in a body fragment? The BETA compiler permits the following fragments: top.bet: ORIGIN '~beta/basiclib/v1.4/betaenv'; BODY 'testBody' --- lib: attributes --- test: (# do <> #) --- program: descriptor --- (# do test(# do ... #) #) testBody.bet: ORIGIN 'top' --- testBody: descriptor --- (# do (* no inner! *) #) Why does the compiler allow the specialization of test in the program slot even though there is no inner in the definition of test (as can be seen in the testBody fragment)? The reason is that the testBody fragment may be compiled separately, and later changed without recompiling or rechecking the top.bet fragment. That is, even though the testBody might originally have included an inner, there is no way to ensure that later changes do not remove it (without sacrificing the separate compilation ability). Note: This behavior is consistent with the compiler not performing flow analysis to ensure that all execution paths of a pattern contain an inner. For example, foo: (# do (if true then (* nothing! *) else inner if) #) bar: foo(# do ... #); is legal even though bar's do-part is never executed. 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 results in a window containing "Label" ORIGIN '~beta/Xt/current/awenv' --- PROGRAM: descriptor --- AwEnv (# Hello: @Label; do Hello.init; #) whereas this program results in a window containing "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 is 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 necessarily Bus. The BETA runtime system therefore inserts a test to verify that the object referenced by aVehicle[] is actually an instance of a pattern that is a subpattern of Bus (or is a Bus) - otherwise a runtime error occurs. The Qua-warning is issued 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, initialize it by: (for i: persons.range repeat &person[]->persons[i][] for) Then you can use the persons repetition in the rest of the program, just as if it was declared as a repetition of static persons. 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. C06) Why does a BETA program called test.bet cause problems on some UNIX installations? By default, the executable generated from a BETA program called test.bet is called test. Depending on your UNIX installation's defaults and your own environment variables, attempts to execute the BETA program by typing test may, however, result in the standard system program test being executed instead. To avoid the problem, just type ./test instead of test. [Note: This is a typical beginner's problem, not related to the BETA language or the BETA environment as such.] C07) How do I disable qualification check warnings? The "A run-time qualification check will be generated here" warning may be disabled by using the compiler's -noquawarn (or -q) switch. All warnings may disabled by using the -nowarnings (or -w) switch. If you would like the -q option to become the default, you can include it in your BETAOPTS environment variable, e.g. setenv BETAOPTS -q If you would like to temporarily turn qualification check warnings back on, you may then do so by specifying the -quawarn switch. C08) What is the difference between P and &P? Consider the following BETA program: (# P: (# do ... #) do P; &P #) Compiling this program with the current BETA compiler shows no difference in the code generated for P and &P. However, the semantics of BETA defines a difference, namely that P is the execution of an inserted item and that &P is the creation and execution of a dynamic item, one of the differences being that inserted items are only allocated once, irrespectively of how many times they are executed. The current BETA compiler implements inserted items as dynamic ones, thereby not taking advantage of the potential possibility for optimization. This limitation will be removed in a future release of the compiler. 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 and only if t1 and t2 are equal, and t1[]->t2.equalNCS returns true if and only if t1 and t2 are equal up to differences in 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. 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 is equally easy: keyboard.getline->s[]; reads a line of text from the keyboard, and assigns a reference to the read text to the text reference s (assumed to be declared as s: ^text). Reading from other texts (e.g. t) is done by: t.getline->s[]; B03) Why does getInt followed by getLine not necessarily work as expected? You have to be careful when scanning input entered from the keyboard. For example, if your program has a section of the form keyboard.getInt -> ...; ... keyboard.getLine -> ...; and you enter, say, 42 foo then the string returned by keyboard.getLine will be empty because getInt stops scanning immediately after 42 and does not consume the (non-numeric) new-line character. [Thus, entering 42foo works correctly.] You may insert the line (if keyboard.peek//ascii.newline then keyboard.get if); between the calls to getInt and getLine to get the desired effect, or even call keyboard.scanWhiteSpace in which case, however, you won't be able to enter a string starting with white-space characters, similar to the functionality of C's library function scanf(). B04) What is the rationale behind the Mjolner BETA System file directory structures? This entry describes the file structure of the Mjolner BETA System. The entry is intended as an illustration of one 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 contain 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 contains demo programs illustrating the usage of this subproject. The test subdirectory contains programs for testing the functionality of this subproject. The (* group files *) indicates that there will be an Fi.group file (or an Fi.astL for PC systems) 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, hpux8, hpux9, snake, mac, and linux. There may be one subdirectory of each machine type. The substructure consisting of (* group files *) and (* code directories *) is 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 structured, possibly with a subdirectory for each interface file Fi, but may also follow different layouts. 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). B05) What do the (* idx+ *), etc. comments mean? At different places in the Mjolner BETA System interface files, you may encounter comments of the form (* idx=2 *), (* idx+ *), or (* idx- *). These are not compiler options - the compiler totally ignores all comments. Instead, the comments are used for formatting the interface files for the documentation. They can be safely ignored. /Jacob Seligmann ------------------------------------------------------------------------ Mjolner Informatics ApS Phone: (+45) 86 20 20 00 ext. 2754 Science Park Aarhus Direct: (+45) 86 20 20 11 - 2754 Gustav Wieds Vej 10 Fax: (+45) 86 20 12 22 DK-8000 Aarhus C, Denmark Email: jacobse@mjolner.dk ------------------------------------------------------------------------ BETA is better ------------------------------------------------------------------------