From: jlk@daimi.aau.dk (Jorgen Lindskov Knudsen)
Newsgroups: comp.lang.beta,comp.object,comp.answers,news.answers
Subject: FAQ: BETA Programming Language
Date: 12 Sep 1994 21:14:32 GMT
Organization: DAIMI, Computer Science Dept. at Aarhus University
Message-ID: <352gbo$79e@belfort.daimi.aau.dk>
Reply-To: beta-language-faq@mjolner.dk
message to info@mjolner.dk with the following message body: 
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[]
           <<SLOT fBody: dopart>>
           #)

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;
              <<SLOT fLib: attributes>>
           enter t[]
           <<SLOT fBody: dopart>>
           #)

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: @<<SLOT fLib: descriptor>>
           enter t[]
           <<SLOT fBody: dopart>>
           #)

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;
              <<SLOT fLib: attributes>>
           enter t[]
           <<SLOT fBody: dopart>>
           #)

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: A (# <<Blib: attributes>>
                ...
             #);
        C: B (# 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 <<SLOT testBody: descriptor>> #)
        --- 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. 
--

   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

