## Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z

# FAQ: BETA Programming Language (version 1.12 - 07 May 98)

[ Usenet FAQs | Web FAQs | Documents | RFC Index | Property taxes ]
Archive-name: beta-language-faq
Last-modified: May 07, 1998
Version: 1.12
Maintained-by: Jorgen Lindskov Knudsen <jlk@daimi.aau.dk>
----------------------------------------------------------------------------

View all headers
BETA: Frequently Asked Questions (FAQ)

----------------------------------------------------------------------------
This question-and-answer list is posted regularly to the BETA mail group,

(jlk@daimi.aau.dk).

This information is abstracted and condensed from the posts of many
different contributors. No guarantees are made regarding its accuracy.
----------------------------------------------------------------------------
There are several ways to get this document:

* E-mail: The FAQ can be obtained by sending a message to
info@mjolner.com with the following message body:

send BETA beta-language-faq

* FTP: The FAQ can be fetched via anonymous ftp from ftp.daimi.aau.dk as

pub/beta/faq/beta-language-faq.txt

* WWW: The FAQ is available in hypertextualized form on the World Wide
Web at URL

http://www.daimi.aau.dk/~beta/FAQ.

http://www.daimi.aau.dk/~beta/

http://www.mjolner.com/

----------------------------------------------------------------------------

Changes since version 1.11

New entries:

* M09) I cannot compile Beta programs with MPW that ships with CW Pro 2.

Changed entries:

* W07) Known bugs, limitations and inconveniences in release 4.1

In addition, a number of minor changes and corrections have been made to
other entries.
----------------------------------------------------------------------------

Contents

* Part I: Frequently Asked Questions
o Q01) What is BETA?
o Q02) Where did BETA come from?
o Q03) What BETA products are available?
o Q04) Are there any school or student discounts?
o Q05) Is BETA available in the public domain?
o Q06) What books are available for learning about BETA?
o Q07) Does an introduction to BETA besides the BETA book exist?
o Q08) Are any magazines or newsletters concerning BETA available?
o Q09) Are there any user groups related to BETA?
o Q10) Are there any mailing lists related to BETA?
o Q11) Are there any newsgroups related to BETA?
o Q12) Is there an archive of BETA postings?
o Q13) Are there any conferences for BETA users?
o Q14) Is BETA available on PC, Mac, NeXT, Amiga, Atari, ...?
o Q15) Are there standards for the BETA language?
o Q16) What is Mjolner, Sif, Valhalla, Bifrost, Yggdrasil, etc.?
o Q17) Is it possible to obtain an evaluation version of the Mjolner
System?
o Q18) What is the origin of the name BETA?
o Q19) How to format BETA programs in LaTeX?
* Part II: Language Issues
o L01) What features do BETA have?
o L02) What changes have been made to the BETA language definition?
o L03) How do I deal with concurrency in BETA?
o L04) How do I deal with persistence in BETA?
o L05) How do I deal with distribution in BETA?
o L06) How do I deal with exception handling in BETA?
o L07) Can classes be treated as first-order elements in BETA?
o L08) What about garbage collection in BETA?
o L09) How do I create a "parameterized class"?
o L10) What is the difference between a virtual binding, a further
binding and a final binding (i.e. between :<, ::<, and ::)?
o L11) What about invariants in BETA?
o L12) What about change propagation in BETA?
o L13) What about futures in BETA?
o L14) Why can't local variables be accessed in INNER?
o L15) How do I implement a copy (or clone) operation?
o L16) Why doesn't BETA have multiple inheritance?
o L17) What is the rationale behind the syntax of BETA?
o L18) How do the scope rules of BETA actually work?
o L19) What is a pattern?
o L20) Are identifiers and keyworks case-sensitive in BETA?
o L21) What characters are allowed in BETA identifiers?
o L22) What is the exact semantics of leave P and restart P, when P
is the name of a pattern?
o L23) What is the BETA lexem syntax?
o L24) What is the maximum length of a BETA identifier?
o L25) What is the exact qualification rules for nested patterns?
* Part III: Environment Issues
o E01) What is the Mjolner System?
o E02) What does the Mjolner System contain?
o E03) What libraries come with the Mjolner System?
o E04) What frameworks come with the Mjolner System?
o E05) What tools come with the Mjolner System?
o E06) Does a beta-mode for Emacs exist?
* Part IV: Specific Issues
o 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?
+ F08) Can <<Attributes>> be used instead of <<AttributeDecl>>?
o Section II: The X libraries
+ X01) Why does my label widget sometimes get the attribute
name as label-string, and sometimes not?
+ X02) Why do I get the error "There must be only one non-shell
widget which is son of Toplevel"?
+ X03) How do I get a separate window for my widget?
+ X04) Why do I get the error "clockWidgetClass: undefined"
when linking my AwEnv program? [corrected in r4.0]
+ X05) Why do I get the error "Error: NULL ArgVal in
XtGetValues" when executing my Xt program? [corrected in
r4.0]
+ X06) How do I set font information in MotifStrings?
+ X07) Resource specification errors in Xt/v1.9
o 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"? [corrected in r4.0]
+ 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?
+ C09) What does "virtual prefix not implemented" mean?
[corrected in r4.0]
+ C10) What should I do if the compiler prints "Please report
the error to Mjolner Informatics" and stops?
+ C11) What are the known errors the compiler?
+ C11.1) Bugs in version 5.0
+ C11.2) Bugs in version 5.1
+ C11.3) Bugs in version 5.2
+ C12) Tracing the work of compiler?
+ C13) Problem with floating point expressions in connection
with repetitions
+ C14) New features introduced in the Compiler
+ C14.1) New features in version 5.3 of the Compiler
+ C14.2) New features in version 5.2 of the Compiler
+ C14.3) New features in version 5.1 of the Compiler
+ C14.4) New features in version 5.0 of the Compiler
o 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 System file
directory structures?
+ B05) What do the (* idx+ *), etc. comments mean?
+ B06) Error in v1.4/seqContainer.bet? [corrected in r4.0]
+ B07) Error in v1.4/regexp.bet? [corrected in r4.0]
+ B08) Error in v1.4/basicsystemenv.bet? [corrected in r4.0]
+ B09) Why does my guienvsystemenv program stop at startup?
* Part V: Platform Specific Issues
o Section V: BETA on Macintosh
+ M01) What are the system requirements to run BETA on
Macintosh?
+ M02) What is MPW. Where do I get it?
+ M04) Do I need a floating point unit to use BETA?
+ M05) Does BETA work on PowerPC machines?
+ M06) Does BETA work on Motorola machines?
+ M07) Known bugs, limitations and inconveniences in release
4.0.2
+ M08) Known bugs, limitations and inconveniences in release
4.1
+ M09) I cannot compile Beta programs with MPW that ships with
CW Pro 2.
o Section VI: BETA on Windows 95 and Windows NT
+ W01) What are the system requirements to run BETA on Windows
95 and Windows NT?
+ W02) SDK Requirements for Windows 95 or Windows NT
+ W03) Why do I need a MAKE facility?
+ W04) Error in directory scan using Borland SDK? [corrected in
r4.0]
+ W05) Make-error for lazyref_gc.c using Borland SDK?
[corrected in r4.0.2]
+ W06) Known bugs, limitations and inconveniences in release
4.0.2
+ W07) Known bugs, limitations and inconveniences in release
4.1
o Section VII: BETA on HPUX
+ HP01) What are the system requirements to run BETA on HPUX
workstations?
+ HP02) Why do some callbacks cause "Illegal Instruction" on
hpux9pa (using v5.0 of the compiler)?
o Section VIII: BETA on Linux
+ Lx01) What are the system requirements to run BETA on Linux
machines?
+ Lx02) How to make the BETA compiler version 5.0/5.1 work with
Linux ELF libraries [corrected in r4.0]
+ Lx03) Why does GuiEnv demos segmentation fail? [error in r4.0
& r4.0.1]
o Section IX: BETA on Silicon Graphics
+ SG01) What are the system requirements to run BETA on Silicon
Graphics workstations?
+ SG02) Gnu C Compiler gcc not supported
+ SG03) Remember to set LD_LIBRARY_PATH
+ SG04) Using BETA on IRIX 6 machines
+ SG05) Limitations, bugs and inconveniences
+ SG06) Disclaimer (Slow startup of tools)
o Section X: BETA on Sun workstations
+ Sun01) What are the system requirements to run BETA on Sun
workstations?

----------------------------------------------------------------------------

----------------------------------------------------------------------------

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
System) based on the BETA language.

In the US, the MacTech Magazine Mail Store is the distributor of the Mjolner
System.

In France and the French parts of Belgium and Switzerland, the Mjolner
System is distributed by BCDL-ObjectLand.

In UK, the Mjolner System is distributed by InterGlossa.

Mjolner Informatics offers the Mjolner System technology to other commercial
organizations who are interested in building BETA products (such as
alternative development systems), or who are interested in developing
value-added products for the Mjolner 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.com
WWW: http://www.mjolner.com
WWW Sales: http://www.mjolner.com/warehouse/

MacTech Magazine, Mail Order Store
Xplain Corporation
P.O. Box 250055
1617 Pontius Avenue, 2nd Floor
Los Angeles, CA 90025-9555, USA
Phone: +1 310 575 4343
Fax: +1 310 575 0925
CompuServe: 71333,1064
Internet: neil_ticktin@xplain.com
America Online: MACTECHMAG
GEnie: MACTECHMAG

BCDL-ObjectLand
26 rue Jules Lanery
F-59240 Dunkerque
France
Phone: +33 28 66 53 00
Fax: +33 28 66 53 01
E-mail: ObjectLand@netinfo.fr
WWW: http://www.netinfo.fr/ObjectLand/ (Journal of

InterGlossa Ltd
UK
Phone: +44 1734 561919
Fax: +44 1734 561920
E-mail: Tom.Lake@glossa.co.uk
WWW: http://www.glossa.co.uk

----------------------------------------------------------------------------

Q04) Are there any school or student discounts?

Mjolner Informatics offers substantial discounts for educational purposes
(e.g. 45/%}. Also included in educational site licenses are attractive
offers for the institutions to freely distribute Personal Edition versions
of the system to those students, following the cources, in which BETA is
used.

Generally, the Personal Edition versions of the system is freely available
information.
----------------------------------------------------------------------------

Q05) Is BETA available in the public domain?

The BETA language definition is in the public domain. A reference manual on
the language is in progress (release-date not fixed yet).

The Personal Edition versions of the system is freely available from Mjolner

Kai Petzke has initiated a project for writing a freeware compiler for BETA.
It is implemented as a translator of BETA to C. For more information and to
download a working copy of the compiler, that understands most of BETA's
grammatical terms, see the web page:
----------------------------------------------------------------------------

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"
ISBN 0-201-62430-3

An german introduction to BETA can be found in the book:

Ernst Erich Doberkat, Stefan Dißmann:
"Einführung in die objectkorientierte Programmierung mit BETA"
ISBN 3-8273-1026-1

The Mjolner 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.

----------------------------------------------------------------------------

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 System (and
the BETA language) for building hypermedia systems.

Mjolner Informatics produces a quarterly 8-page newsletter called "Mjolner
----------------------------------------------------------------------------

Q09) Are there any user groups related to BETA?

Yes, there is a user group hosted by Mjolner Informatics. The user group is
primarily organized around the BETA mailing list: usergroup@mjolner.com

The BETA user group is one of the important sources of information on the
developments of the Mjolner System, and an important source of information
to Mjolner Informatics on the users' expectations for future developments.

----------------------------------------------------------------------------

Q10) Are there any mailing lists related to BETA?

There is a mailing list for BETA, organized by Mjolner Informatics:

usergroup@mjolner.com

In order to be added to, or removed from the mailing list, please send a
mail to:

usergroup-request@mjolner.com

(Do not send subscription requests to usergroup@mjolner.com as they will be
mirrored onto comp.lang.beta.)

Mail sent to the mailing list is automatically forwarded to the
comp.lang.beta newsgroup and news posted on the newsgroup is automatically
forwarded (moderated) to the mailing list.
----------------------------------------------------------------------------

Q11) Are there any newsgroups related to BETA?

The comp.lang.beta Usenet newsgroup is available for discussing issues
related to the BETA language.

Postings to comp.lang.beta are automatically forwarded (moderated) to the
usergroup@mjolner.com mailing list and mails to the mailing list is
automatically posted to the newsgroup.
----------------------------------------------------------------------------

Q12) Is there an archive of BETA postings?

Mjolner Informatics keeps an archive of the BETA mailing list.

In addition, the University of Aarhus maintains an archive of all postings
to the comp.lang.beta newsgroup, available at:

* http://www.daimi.aau.dk/~beta/News/
* ftp://ftp.daimi.aau.dk/pub/beta/comp.lang.beta

The former is updated daily, the latter annually.
----------------------------------------------------------------------------

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, on PowerPC Macintosh and
on Intel-based PCs.

On UNIX, the platforms supported are: Sun Sparc (Solaris), HP 9000 (series
700) and Silicon Graphics MIPS machines running IRIX 5.3 or 6.

Mjolner System is also available for Linux (386/486/Pentium). Linux is a
very popular freely available UNIX implementation for Intel processors (for

Mjolner System is also available for Windows 95 and Windows NT
(386/486/Pentium).

There are no current plans to port the Mjolner System to neither DOS nor
Windows 3.1 due to the 16-bit addressing and 8-character filename
limitations.

Although not officially confirmed by Mjolner Informatics, users of the
Mjolner System have reported that the Mjolner 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.

The following additional info is kindly supplied by Juha Makinen
<Juha.Makinen@cs.Helsinki.FI>:

Actually this program is an emulator, because it can run native
Apple Macintosh 680x0-code in Amigas. The name of this program is
an Emplant and it is a 99,9% compatible Apple Macintosh emulator.
It emulates the Machintosh (like Quadra) even faster than an
equivalent Macintosh is running with the same processor and
clock-speed. (This is due to separate graphics, I/O etc.
co-processors found on motherboard of the Amiga. Some programs
show two times better performance.)

The program is an multi-platform -emulator and can also multitask
another emulation and/or AmigaOS on the backgroud. There is a
rival (Amax IV) for this emulation-program, but it is only 99,5%
Macintosh-compatible and is not supported as widely as this one
is. (I'm not sure which one the original author refers to, but I'm
quite sure that you can run Beta-compiler on Emplant with
Macintosh Emulation. Every program which run in original Quadra
should run on Emplant.)

And as an addition, you can run Emplant-emulator also on the Amiga
3000 (and A2000 if you have a processor-card with MMU).

----------------------------------------------------------------------------

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.

Currently, no language definition document exist. Work is in progress to
write this language definition document. The definition will be given in
strict natural language.

See section Q06 and L02 for information on available language descriptions
and latest changes to the language.

The BETA and the Mjolner 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 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
speaking people, the "spelling of the pronunciation" could be:
"Myolner" or "Myulner", and for French speaking 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.
Frigg:
is the name of the wife of Odin and queen of Asgaard. Frigg is the name
of the user interface editor.
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 System?

Well, yes and no. Mjolner Informatics has previously offered a demo version
of the Mjolner System for the cost of media and shipment.

Due to the introduction of the very cheap Personal Edition versions on all
platforms, the demo offer has, however, been stopped. For evaluation
purposes, Mjolner Informatics suggests purchase of a PE system (price
currently US$60+VAT, media and shipment). Write info@mjolner.com for details. ---------------------------------------------------------------------------- Q18) What is the origin of the name BETA? [Ole Lehrmann Madsen (olm@daimi.aau.dk) writes:] Originally Beta was just one of a series of languages developed at Nordic universities. The first object-oriented language Simula was originally designed as a simulation language but it was soon realised that the main ideas could be used for programming in general and this lead to Simula 67, which has class, subclass, virtual function coroutines, etc. It also supplied the first object-oriented framework in the form of Class Simulation which is a set of classes to support the original goal of Simula to write simulation programs. It turned out that many users of Simula seemed to get more understanding of their problem domain by having to develop a model using Simula than of the actual simulation results. Kristen Nygaard and others then decided to develop a successor for Simula, but with main focus of system description - not execution. This lead to a language called Delta In Delta you could express true concurrent objects and use predicates to express state changes. Delta could, however, not be executed. Delta means 'participate' in Norwegian'. [E. Holbaek-Hannsen, P Haandlykken, K. Nygaard: System Description and the Delta Language. Norwegian Computing Center, Publ. no 523, 1973] When Kristen Nygaard was a visiting professor at Aarhus University in 1973-75, a project was started to develop a programming language based on the Delta ideas. This language should be a (programming language) successor to Simula and was called Gamma In the seventies, it was often assumed that a general programming language was not usable as a systems programming langauge. It was therefore decided to define a systems programming langauge which should also be used to implement Gamma. This language was called BETA Finally the machine level languages were referred to as Alpha Long story:-) So what happened to Delta and Gamma? There is a (big) report describing Delta and there has later been some related work on Delta including using it in a few projects, but it is no longer being used or developed. The language Epsilon was a simplified version of Delta and the result of attempts to formalize Delta by means of Petri Nets. The Gamma language was never developed. During the work on Beta it was soon realized that there was no need for Gamma. It turned out that by having powerful abstraction mechanisms in Beta, the Gamma-level could be handled by supplying class libraries and frameworks. You may thus think on the Gamma-level as the libraries and frameworks of the Mjolner System. And this is where we are today. Some of the stuff in Delta could be handled by adding constraints to BETA and supporting invariants and pre/post conditions. (The idea of invariants and pre/post conditions for classes were originally suggested by Tony Hoare for Simula. [C.A.R. Hoare: Proof of correctness of data representation, Acta Informatics, 4, 271-281, 1972] The Mjolner System has some libraries supporting initial versions of constraints and invariants. It has often discussed changing the name BETA - to avoid the beta-testing jokes. The suggestion for a name change is Scala - Scandinavian Language and also Scala means 'going up'... But so far it has been decided to stick with Beta. ---------------------------------------------------------------------------- Q19) How to format BETA programs in LaTeX? The best way to format BETA programs in the LaTeX formatting system is by using the lgrind LaTeX package. You can use the following lgrind style: beta|the BETA programming language:\ :pb=(^\d?\p\d?\:\d?\p?\d?$$#\d?:\ :id=_:\ :bb=\d(\(#|\(if|\(for)\d:\ :be=\d(#$$|if\)|for\))\d|;:\ :oc:\ :cb=$$*:\ :ce=*$$:\ :sb=':\ :se=':\ :tb=%%:\ :te=%%:\ :mb=%\$:\
:me=\$%:\ :vb=%\|:\ :ve=\|%:\ :kw=if then else for repeat\ do inner none this enter exit leave restart suspend\ and or xor mod div\ stop: This lgrind style can be made available in two different ways: * Included in the among standard lgrind styles. This is done by copying the above definition into the lgrindefs styles file, which is installed as part of the lgrind installation (possibly in the /usr/share/local/lib/lgrindefs file - dependent on your local setup). This installation must be done by the local systems administrator. * You can also copy the lgrind style onto a file in your personal file system. Let us for further reference assume that this file is called:$HOME/lgrind/lgrindefs.

Q19.1) How to use the BETA lgrind style

When the lgrind style is made available (as above), you can use it in the
following way.

Let us assume, that you have a BETA source file called prog.bet.

* If the lgrind style is saved among the standard lgrind styles, you
execute:

lgrind -lbeta -i prog.bet > prog.tex

* If the lgrind style is saved in your personal file system, you execute:

lgrind -lbeta -d $HOME/lgrind/lgrindefs -i prog.bet > prog.tex You are now ready to include the BETA source into a LaTeX document. You do this by inserting the following in the start of the LaTeX document: \usepackage{lgrind} Please note, that you only need to insert this once. This implies, that the lgrind LaTeX style is available. At the position in the document, where you wish the BETA source code, you just insert one of the following: * \lgrindfile{prog} which will simply include the file at that point of text, and will draw horizontal lines before and after the listing. * \lagrind[htbp]{prog.tex}{caption}{label} which will put the listing also within a figure environment, using the float options, caption and label you gave. You insert one lgridfile or lagrind command for each piece of BETA source code, you wish to include in the document. ---------------------------------------------------------------------------- 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. You can find more introductions to the BETA language by looking at the BETA Language Tutorial. ---------------------------------------------------------------------------- L02) What changes have been made to the BETA language definition? The BETA language definition has been stable since 1992, apart form the following minor changes: L02.1) String Literals as References The pattern text enters and exits a char repetition. This means, that a text may be initialized using constant strings as follows: t: @text; do 'hello' -> t; Many operations involving texts, however, takes references to texts as enter/exit parameters. This is mainly for efficiency reasons. To allow easy invocation of such operations on string literals, the following is also allowed: t: ^text; do 'hello' -> t[]; The semantics of this is, that a text object is instantiated, initialized by the constant string, and finally assigned to the text reference. L02.2) Simple If Often the following If statement is used: b: @boolean; do (if b//TRUE then ... else ... if); The current version of the compiler supports an extension to the BETA language called Simple If. This extension means, that the case-selector // may be omitted, if the evaluation on the left hand side exits a boolean. That is, the above may be written b: @boolean; do (if b then ... else ... if); Like in the general if-statement, the else part if optional. L02.3) Xor Primitive An xor primitive is supported as a basic operation on booleans. That is b1, b2, b3: @boolean do b1 xor b2 -> b3 is possible. L02.4) Short-circuit Boolean Expressions Boolean expressions are implemented as short-circuit. That is, in B1 or B2 B2 is not evaluated if B1 is true, and B1 and B2 B2 is not evaluated if B1 is false. L02.4) Labelled imperatives Labelled imperatives were previously defined in the language in two forms: L: Imp; and (L: Imp1; ...; :L) The second form has now been removed from the language. Instead, the compiler offers the form L: (# do Imp1; ... #) Note that this form is implemented very efficiently in the case where there are no declarations in the object descriptor (i.e. between (# and do). ---------------------------------------------------------------------------- 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 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 System contains a 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). ---------------------------------------------------------------------------- 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 difference 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 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 variables declared in execution blocks not 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. ---------------------------------------------------------------------------- L15) How do I implement a copy (or clone) operation? It is often useful to be able to make a genuine copy of an object. It is currently being discussed to introduce a 'clone' operation into the object pattern, which should take care of this copying automatically, but no decision has been made as to how and when. Until then, the following trick does the job: P: (# (* internal P structures *) copy:< (* generic copy operation *) (# copyType: ##P; theCopy: ^P; do this(P)##->copyType##; &copyType[]->theCopy[]; (* insert here code to implement the copying * of internal P structures into theCopy *) INNER copy; (* possible finalization of the copying process *) exit theCopy[] #) #); Q: P(# (* internal Q structures *) copy::< (# Qcopy: ^Q do theCopy[]->Qcopy[]; (* insert here code to implement the copying * of internal Q structures into Qcopy *) INNER copy; (* possible finalization of the Q copying process *) #) #); R: Q(# (* internal R structures *) copy::< (# Rcopy: ^R do theCopy[]->Rcopy[]; (* insert here code to implement the copying * of internal R structures into Rcopy *) INNER copy; (* possible finalization of the R copying process *) #) #); Given the declarations a: @R; aCopy: ^R; then a.copy->aCopy[] will make a copy of the a object with the proper qualification (here R), and a state that is a copy of the state of a. Note: The Rcopy: ^R do theCopy[]->Rcopy[] part of the copy further binding is an inconvenience, but is necessary to persuade the type system to allow remote access to the R-parts of the theCopy object. ---------------------------------------------------------------------------- L16) Why doesn't BETA have multiple inheritance? [Ole Lehrmann Madsen (olm@daimi.aau.dk) writes:] I shall try to explain why there is no (traditional) multiple inheritance in BETA. Please note that I am not trying to argue against MI. The following is only an attempt to explain why it is not in BETA. When BETA was designed we did not think that the concept of multiple inheritance was ready for being incorporated in the language. One of the main design goals for BETA was that it should be good for modelling. Most usages of MI seemed to be for pure code reuse, i.e. a new class may be defined by inheriting from a number of classes and then redefining the parts that should differ. Often this is done without there being any conceptual relation between the new class and the ones it inherits from. We did not like that way of using inheritance. MI in BETA should be there to model classification hierarchies which are non-tree structured. In my experience, such hierarchies are rare in practice. What is more common is that you may want several independent tree-structured classification hierarchies for the same objects. A set of person objects might be classified according to their profession, nationality, and religion. This gives three class-hierarchies. People often handle such situation using MI, but this will merge the hierarchies in a way that makes it difficult to identify the three original ones. We would like to support such independent classification hierarchies in BETA, but no concrete proposal exists. The various proposals for solving name conflicts and overlapping superclasses also seemed rather complex. We did not want the semantics of basic constructs to be complicated to understand. For BETA there are a number of additional problems: * Virtual patterns from a common superclass may have conflicting bindings in the superclasses: A: (# V:< A1; ... do ... inner ... #); B: A(# V::< A2; ... do ... inner ... #); C: A(# V::< A3; ... do ... inner ... #); D: B & C (# V:: A4; ... do ... #); (The syntax B & C has tentatively been used for MI in BETA.) Here A2 and A3 must both be subclasses of A1, and A4 must be a subclass of both A2 and A3. (In her Ph.D. Thesis, Kristine Thomsen defined a language along these lines, which handled virtual bindings a la those in BETA. It should be available from the Computer Science Department, Aarhus University.) * The semantics for combining inners of multiple superclasses must also be defined. In the example above, should B's do-part be executed before C's or vice versa? Since we are not in favour of making the order of superclasses significant, we were considering letting the execution order of B and C be non-deterministic, in the sense that the implementation may execute B or C in any order. (Thomsen's thesis also deals with combing inners and proposes a number of other alternatives. You may also want to take a look at: K. S. Thomsen: "Inheritance on Processes, Exemplified on Distributed Termination Detection", International Journal of Parallel Programming, pages 24-37, November 1988.) Finally, we have not felt an strong need to support MI in the traditional sense, since BETA has other means for handling some of the most common MI cases: In BETA you may inherit from part-objects and at the same time further-bind its virtuals: A: (# f:< ... #); B: (# g:< ... #); C: (# ... X: @A(# f::< (# ... #); ... #); Y: @B(# g::< (# ... #); ... #); ... #); X and Y are singular part-objects; due to BETA's block structure the virtual bindings of f and g may refer to variables in the enclosing C-object. Given the declaration W: ^C, the functions f and g may be invoked as W.X.f and W.Y.g. The difference from MI is that you have to qualify using X and Y. Some people think of this as an inconvenience; others think of it as an advantage since it forces them to be explicit about name conflicts between A and B. If you prefer writing W.f and W.g, you may define f and g functions in C and let them forward the calls to X.f and Y.g. Given the declaration V: ^A, then W.X[]->V[] is possible, and an invocation of V.f calls the further-binding of f in X, thereby possibly accessing/changing the state of C. To sum up, this form of multiple inheritance via part objects is very similar to non-overlapping inheritance in C++. As a final example, consider the following well-known MI case: Window / \ WindowWithBorder WindowWithTitle \ / WindowWithBorderAndTitle In BETA this may be handled using block-structure Window: (# ... Border: (# ... #); Title: (# ... #); #); W1: @Window(# B: @Border; T: @Title #); W2: @Window(# T1,T2: @Title #); Here W1 has a border and a title, whereas W2 has no border and two titles. (For a further discussion, see K. Osterby: "Parts, Wholes, and Subclasses", Proceedings of the 1990 European Simulation Multiconference, pages 259-263, 1990.) To sum up, we did not think that traditional MI has been worth the complications it will add to the language, since many of the MI cases can be handled by other means. We are, however, still discussing MI, and it may end up being supported more directly. ---------------------------------------------------------------------------- L17) What is the rationale behind the syntax of BETA? [Ole Lehrmann Madsen (olm@daimi.aau.dk) writes:] When we designed BETA, we spent a lot of time discussing syntax - it is one of those things people can really disagree about. We tried to develop what we considered to be a nice and readable syntax with as few long keywords as possible. The following type of brackets are used: (# ... #) object (* ... *) comment (if ... if) if-imperative (for ... for) for-imperative We did consider using { and } for objects or comments, but ended up not doing it; we did not feel a strong need to have BETA look like C. As we did not like long keywords (as in Pascal or Ada), BETA uses symbols like @, ^, |, and :< instead. We believe that for a small language like BETA, it is an advantage to have a compact syntax. This way, you can have more code on a page or in a window. (Of course, {,} is shorter than (#,#), but we preferred the syntax to be consistent with (if,if), etc.) It is not our experience that the syntax of BETA presents any obstacle to learning the language. BETA has very few constructs (and symbols), and while they may seem strange at first, they are easy to learn and use. Try it! You can find a quick overview of the BETA syntax by looking at the BETA Quick Reference Card ---------------------------------------------------------------------------- L18) How do the scope rules of BETA actually work? The BETA scope rules may seem slightly complex to the new BETA programmer, but are actually rather intuitive and simple. There are three visibility rules: 1. Names declared in the descriptor itself are visible within the descriptor. 2. Names declared in the superpattern of a descriptor are visible within the descriptor. 3. Names declared in outer blocks (i.e. enclosing descriptors) are visible within the descriptor. These rules are applied in order to find the definition for a given name application: * Start by using rule 1, looking for a local declaration. * If not found, then use rule 2 to find the declaration in the superpattern (if the descriptor has one). While using this rule, you may apply rule 1. * If still not found, then use rule 3 to find the declaration in the enclosing descriptors. While using this rule, you may apply rule 1 and 2. Note: This method implies that it is possible to reuse the same name for different declarations, as long as the declarations are in different descriptors. To see how the rules interact, take a look at the example program below. It illustrates most of the combinations, and has the resulting output is shown in comments after each imperative. (# a: (# do 1->screen.putint #); P1: (# do a; INNER P1 #); P2: (# a: (# do 2->screen.putint #); do a #); P3: P1(# do a #); P4: P1(# a: (# do 3->screen.putint #); do a #); P5: P1(# foo1: (# do a; inner foo1 #); foo2: (# a: (# do 4->screen.putint #) do a; inner foo2 #); #); P6: P5(# a: (# do 5->screen.putint #); foo3: (# do a; inner foo3 #); foo4: foo1(# do a; inner foo4 #); foo5: foo2(# do a; inner foo5 #); #); P: @P6; do a; (* 1 *) P1; (* 1 *) P2; (* 2 *) P3; (* 11 *) P4; (* 13 *) P5; (* 1 *) P6; (* 1 *) P.foo1; (* 1 *) P.foo2; (* 4 *) P.foo3; (* 5 *) P.foo4; (* 15 *) P.foo5; (* 44 *) P.foo1(# do a #); (* 11 *) P.foo2(# do a #); (* 44 *) P.foo3(# do a #); (* 51 *) P.foo4(# do a #); (* 151 *) P.foo5(# do a #); (* 444 *) #) ---------------------------------------------------------------------------- L19) What is a pattern? The following is an attempt to explain the pattern concept. The description is divided into two parts: a description in the form of examples, and a more abstract explanation. To begin with, think of a pattern as a generic word for the concepts class, procedure and function. This is not all there is to it, but it will get you started. In BETA, a pattern is anything starting with (# and ending with #). As a simple example, here is a function that multiplies two numbers: multiply: (# a,b: @integer; enter (a,b) exit a*b #); The multiply pattern takes two integers, a and b, and returns their product. These kinds of patterns are often called functional patterns, since their use correspond to functions (or procedures) in other languages. In BETA, a call to multiply might look like: (7,17)->&multiply->&putInt; putInt is a procedure that writes the result on the screen. As another example, let's build a stack class in the typical object-oriented paradigm: stack: (# content: [100] @integer; currentSize: @integer; push: (# e: @integer; enter e do currentSize+1->currentSize; e->content[currentSize]; #); empty: (# exit (currentSize=0) #); pop: (# e: @integer; do content[currentSize]->e; currentSize-1->currentSize; exit e #); #); Now, stack is also just a pattern. You may call it a class pattern since its meant to be used as a class: to make instances, the actual stacks. And just in case you were wondering: Yes, the push, empty, and pop methods defined for stack are also patterns (functional/procedural patterns), defined inside the stack pattern. BETA offers a lot of extra functionality which could make the example much more realistic (information hiding, generic stacks, exceptions due to overflow, dynamic expansion of the stack capacity, etc.), but let's keep the example simple. Having shown a few practical examples, here's the more elaborate explanation: A pattern is used for instantiating objects (static objects, dynamic objects, inserted objects, etc.). A pattern declaration in its full form looks like this (other forms below): P: S(# decl1; decl2; ... decln; enter enterlist do imperatives exit exitlist #); This declares P as a (direct) subpattern of S. (S thus is the (direct) superpattern of P.) S may be omitted, in which case object (the direct or indirect superpattern of all patterns) is assumed. Each part (declarations, enter part, do part and exit part) can be omitted. (Thus "P: (# #);" is legal.) Each declaration can be a declaration of a pattern, a virtual pattern, a further or final binding of a previously declared virtual pattern, a static item, a dynamic item, a static component, a dynamic component, a repetition (array) or a pattern variable (used for holding a pattern, popularly speaking). Or a number of same. Thus the above declaration of P fits into an outer pattern. If both P and S have declared enter parts, the enter list of a P object consists of the enter lists concatenated. The same goes for the exit list. Thus the subpattern declaration can only add to the enter and exit lists, not make other changes. A bit more complicated rules exist for do-parts, but the basic principle is the same: only additions are possible. A pattern can be virtual. There are three forms of virtual pattern declarations: P: (# V:< Q; #); P: (# V:< Q(# ... #); #); P: (# V:< (# ... #); #); where Q is a pattern name. (For the sake of completeness, this should perhaps be written as P: S(# ...; V:< Q; ...; enter ... do ... exit ... #); P: S(# ...; V:< R(# ...; enter ... do ... exit ... #); ...; enter ... do ... exit ... #); etc., but we'll leave the that out.) Virtual declarations can be extended, or further bound, in subpatterns: P1: P(# V::< Q1; #); P1: P(# V::< Q1(# ... #); #); P1: P(# V::< (# ... #); #); In the first two forms, it is required that one of the following two conditions holds: 1. V was declared in P (or some superpattern of P) as V:< Q, and Q1 is a direct or indirect subpattern of Q. 2. V was already further bound in P (or some superpattern of P) using the form V::< Q0, and Q1 is a direct or indirect subpattern of Q0. The third form V::< (# ... #) can be used regardless of which form was used for the previous declaration or further binding of V. In this case, the descriptor (# ... #) is used to automatically form a subpattern. (This form of further binding is the only available one if V is declared using V:< (# ... #), or V has been further bound using V::< Q1(# ... #) or V::< (# ... #).) Thus, the further binding makes V a subpattern of what it was before. Finally, a virtual pattern may be final bound. A final binding is a further binding, except (syntactically) :: is used instead of ::<, and (semantically) after a final binding, V is no longer virtual, and can therefore not be further bound. The final binding must otherwise follow the same rules as described above for further bindings. Also, see Question L10. ---------------------------------------------------------------------------- L20) Are identifiers and keyworks case-sensitive in BETA? Neither identifiers nor keywords of the BETA language are case-sensitive. That is, the identifier hello is the same as the identifier HELlo, and the keyword INNER is the same as the keywork inner. However, there is one exception from this rule. Identifiers used for declaring Externals are case-sensitive (due to identifiers in the C programming language being case-sensitible). Please refer to the Compiler Manual for details. ---------------------------------------------------------------------------- L21) What characters are allowed in BETA identifiers? The identifiers in the BETA language must obey the following literal syntax: A BETA indentifier has to start with a letter or '_', and may be followed by a sequence of letters, digits, and '_'. ---------------------------------------------------------------------------- L22) What is the exact semantics of leave P and restart P, when P is the name of a pattern? Leave and restart are the very basic local control mechanisms in BETA. Leave and restart are specified by: restart id and leave id where id is the name of either a label or an enclosing pattern. When id is an enclosing pattern, id is defined to refer to the do-part of id (hence not to the do-part of any superpattern of id). Consider the pattern: P: A(# ... do (* L1 *) ...; leave/restart P; ...; (* L2 *) #) restart P implies that execution continues at (* L1 *): This means that restart P has the effect of entering the do-part of P as after an inner in A. leave P implies that execution continues at (* L2 *): This means that leave P has the effect that execution continues in the do-part of A after the inner that called the main-do-part of P. Example: (# A: (# do (for 4 repeat '['->put; INNER; ']'->put for) #); P: A (# k: @integer do k+1->k->putInt; (if k=2 then '-'->put; leave P if); (if k=3 then '*'->put; restart P if); '+'->put #); do P #) will give the following output: [1+][2-][3*4+][5+] ---------------------------------------------------------------------------- L23) What is the BETA lexem syntax? The different lexems in the BETA language grammar (names, strings, and numbers) are not precisely defined in any of the available documents. We will therefore here give the definition: <NameAppl> = <NameDecl> <NameDecl> = (<letter>|"_")+(<digit>|<letter>|"_")* <String> = "'"<char>*"'" where <char> can be any char except "'" and newline. "'" are allowed in <String>, iff preceeded with "\". "\n", "\t", etc. are allowed in <String> to represent non-printable chars - see Compiler manual (mia91-02) for details. <Const> = (<int>|<based>|<real>) where <int> = <digit>+ <based> = <int>("X"|"x")<basedNum> <basedNum> = (<digit>|<letter>)+ <real> = <int>["."<int>][("E"|"e")[("+"|"-")]<int>] <letter> = "a"|"b"|...|"z"|"A"|"B"|...|"Z" <digit> = "1"|"2"|...|"9"|"0" The usage of |, +, *, (...), and [...] conform to standard regular expressions syntax. ---------------------------------------------------------------------------- L24) What is the maximum length of a BETA identifier? For most practical cases there is no maximum lenghth of a name. The length of an name is currently limited by the representation of an abstract syntax tree (AST). There is currently a limitation to the size of an AST. In the AST representation, a 16-bit integer is used to represent the length of a name. A name can thus in theory consist of more than 65000 characters. However, it is much more likely that a BETA fragment breaks the limit of an AST than an identifier becomes too large. ---------------------------------------------------------------------------- L25) What is the exact qualification rules for nested patterns? In Chapter 8 on Block Structure in the BETA book it is (in section 8.2) said that patterns like Pascal.Symbol and Simula.Symbol are different. The corresponding declarations are as follows Grammar: (# ...; Symbol: (# ... #); ... #); Pascal: @Grammar; Simula: @Grammar; The current implementation does, however, not consider nested patterns like Pascal.Symbol and Simula.Symbol to be different. The reason for this is historical. Qualification check was implemented in two stages. First the compile-time checks were implemented, and next the run-time checks. The qualification rules for run-time checking were implemented such that nested pattern like Pascal.Symbol and Simula.Symbol are identical. This is a relaxation of the proper run-time qualification rule (as defined by the BETA language), and a future release of the MBS will properly implement run-time qualification check. ---------------------------------------------------------------------------- PART III: Environment Issues ---------------------------------------------------------------------------- E01) What is the Mjolner System? The Mjolner 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. (Note: "Mjolner System" was formerly designated "Mjolner BETA system".) ---------------------------------------------------------------------------- E02) What does the Mjolner System contain? The Mjolner 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 System are constructed using the BETA language. Major parts of the Mjolner 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 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. See the Basic Libraries Manual for more details. 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(# ... #); See the Basic Libraries Manual p12 for more details. 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, PC and Macintosh processes. See the Process Libraries Manual for more details. The External Language Interface Patterns To enable interfacing with external languages (such as C), the basic libraries define the external, cStruct, and externalRecord patterns. See the Basic Libraries Manual p18 for more details. 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. See the Container Libraries Manual for more details. 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. See the Persistence in BETA Manual for more details. 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. See the Metaprogramming Manual for more details. ---------------------------------------------------------------------------- E04) What frameworks come with the Mjolner 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. Graphical User Interface framework The Mjolner System contains from release 4.0 a platform independent framework for the construction of graphical user interfaces, called guienv.. 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 System currently includes object-oriented interfaces to the Athena Widgets (AwEnv) and to Motif (MotifEnv). 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 available for enabling transparent access to BETA objects located on different hosts on the network. OODB framework A distributed object-oriented database system for BETA objects is currently being developed. ---------------------------------------------------------------------------- E05) What tools come with the Mjolner 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 Browser The different tools in the Mjolner System uses the same source browser. This source browser gives easy access to the file system, and gives facilities for browsing in the entire set of source files, belonging to a given program (the dependency graph of the program). Source-level Debugger A source-level debugger for the BETA language is available on all platform (except Macintosh and HP-PA). It contains facilities for specifying break-points, single stepping, inspection of object states, inspecting the run-time organization, etc. The debugger has a graphical interface. 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 o graphical structure editing of design diagrams o textual structure editing of programs o automatic program generation from design diagrams o reverse engineering from programs to design diagrams o simultaneous editing of design diagrams and programs No CASE gap: o A single abstract language is used throughout analysis, design, and implementation. o Different concrete syntaxes are used to present the different models: + graphical syntax for design + textual syntax for programs User Interface Editor The graphical user interface editor gives a direct manipulation editor for the user interface of an application. The user interface editor is integrated with the structure editor, enabling both graphical, structured and textual editing of the user interface of the program. 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 System. This beta-mode is in the public domain and can be obtained by FTP at ftp://ftp.daimi.aau.dk/pub/beta/emacs. ---------------------------------------------------------------------------- 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 Mjolner Informatics, 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.6/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. ---------------------------------------------------------------------------- F08) Can <<Attributes>> be used instead of <<AttributeDecl>>? The fragment system has a pragmatic treatment of the syntactic categories <<AttributeDecl>> and <<Attributes>>. In general one may want to leave slots in a delaration list for inserting declarations as in: (# a: @integer; <<SLOT lib1: attributes>>; b: ^ text; <<SLOT lib2: attributes>>; c: (# ... #) #) It is, however, not possible to generate the above form from the BETA grammar, since the nonterminal <attributes> cannot generate itself. It is possible to make a grammar that can do this, but such a grammar is very likely to be ambiguous. The following fragment can, however, be generated from the grammar: (# a: @integer; <<SLOT lib1: attributeDecl>>; b: ^ text; <<SLOT lib2: attributeDecl>>; c: (# ... #) #) This will, however, only allow one fragment-form to be inserted in a each library slot. To handle this, the fragment system allows a fragment form of category <attributes> to be inserted for an <attributeDecl>. This aliasing between <attributeDecl> and <attributes> is handled by the alias mechanism for the BOBS parser used by the meta programming system. See$(BETALIB)/bobs/vx.y/bobs.bet, nontAlias. The alias mechanism also makes it
possible to use <descriptor> as a shorthand for <objectDescriptor>. The use
of syntac alias's is pragmatic and does not strictly follow the principles
of the fragment system, but it is considered a minor but practical
mechanism.
----------------------------------------------------------------------------

SECTION II: The X libraries

----------------------------------------------------------------------------

X01) Why does my label widget sometimes get the attribute name as
label-string, and sometimes not?

The following BETA program creates a window containing "Label"

ORIGIN '~beta/Xt/current/awenv'
--- program: descriptor ---
AwEnv
(# Hello: @Label;
do Hello.init;
#)

whereas the following program creates a window containing "Hello"

ORIGIN '~beta/Xt/current/awenv'
--- program: descriptor ---
AwEnv
(# Hello: @Label(##);
do Hello.init;
#)

Why?

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. A variant of this problem is
the case where you specify a list of widgets using the same pattern:

hello1, hello2: @Label(##);

In this case the default name will always be the first name in the list,
hello1. To avoid this behavior, use the scheme

hello1: @Label(##);
hello2: @Label(##);

or specify the name explicitly instead.
See the X Windows Libraries Manual p5-7 for more details.

----------------------------------------------------------------------------

X02) Why do I get the error "There must be only one non-shell widget which
is son of Toplevel"?

Consider the following program:

ORIGIN '~beta/Xt/current/awenv';
--- program: descriptor ---
AwEnv
(# faculty: label
(# init:: (# do 2-> borderwidth #) #);
University: @box
(# Physics, Mathematics: @faculty;
init:: (# do Physics.init; Mathematics.init #);
#)
do University.init;
#)

The idea was that a window with two labels named Physics and Mathematics
should appear. But executing it gives the error message

Xt Error: There must be only one non-shell widget which is son of
Toplevel. The widget causing the conflict is named faculty.

This is because the program uses the init pattern of the widgets without
specifying the father and name of the widgets. In the Xt manual [MIA 91-16],
it is briefly explained that the father widget will default to "the
enclosing widget according to BETA's scope rules" (see the description of
Core in "Basic XtEnv patterns").

To be precise, this is what happens: When the init pattern of a widget is
invoked, it first checked to see if the father is NONE. This will be the
case if no father is specified in the enter part of init. If so, a search is
started in the statical environment of the widget pattern. If a
specialization of a Core widget is found, this widget is used as the father.
This search is continued until a pattern with no enclosing pattern is found.
In this case the widget named TopLevel (in xtenv) is used as the father. The
widget TopLevel is an instance of the pattern TopLevelShell, which among its
characteristics has the constraint that it wants to have exactly one
non-shell child.

Now consider the example program: The first thing that happens is that the
init attribute of University is invoked. Since no father is specified, a
search for one is started from the University pattern. This search finds the
pattern AwEnv(# ... #), which is not a Core, and which has no enclosing
pattern. Thus University will get the father widget TopLevel.

The final binding of University.init then invokes Physics.init. Physics is
an instance of the pattern faculty, which is declared in the same scope as
University. Thus the search for a father for Physics is identical to the
search for the father of University, and Physics also gets TopLevel as its
father. This is when the error occurs. The reason why the name reported in
the error message is faculty is explained in Question X01.

Notice that it did not matter that the instantiation of the Physics object
is done within University: the default father is searched for starting from
the pattern declaration of the object.

In general there are three possible solutions:

1. Supply the father and name when initializing the faculty widgets:

do ("Physics", University)->Physics.init;
("Mathematics", University)->Mathematics.init;

In this case, no search for a default father is needed for the faculty
widgets.
2. Make (possibly empty) specializations of faculty inside University:

Physics: @faculty(##);
Mathematics: @faculty(##);

Now the search for a default father of Physics will start at the
pattern faculty(##) inside University, so the University pattern will
be the first found in this search, and hence the University widget will
become the father of the Physics widget. Likewise for Mathematics.
3. Move the declaration of the faculty pattern inside the University
pattern. This will give the same search path as in solution 2.
(Conceptually, this might also be the best place to declare faculty in
the first place.)

The above example was a simple one. In more complicated cases, the reason
for an error of this kind can be trickier to spot. If your program uses the
fragment system to move declarations of useful widgets into a library, this
kind of error is likely to occur. Remember that if an instance of an
unspecialized widget is used, the widget pattern being declared in, say, the
XtEnvLib attributes slot of xtenv, then the search for a default father is
started at the XtEnv pattern, and therefore no father widget is found. In
this case the widget will get TopLevel as father. Solutions 1 or 2 above
will be appropriate in these cases.
See the X Windows Libraries Manual p5-7 for more details.

----------------------------------------------------------------------------

X03) How do I get a separate window for my widget?

Widgets that create separate windows which can be individually moved,
resized, and so on, by the window manager are specializations of the Shell
pattern. Normally you would use a TopLevelShell (the pattern used for the
TopLevel widget created by default by XtEnv).

To make the following Athena Label appear in a separate window

goodbye: @Label(# init:: (# do 'Goodbye World'->label #)

you would wrap a TopLevelShell around it:

byewindow: @TopLevelShell
(# goodbye: @Label
(# init:: (# do 'Goodbye World'->label #) #);
init:: (# do goodbye.init #);
#);

To make the window appear, it should be initialized like any other widget,
and then the Shell method popup should be invoked:

byewindow.init;
byewindow.popup;

Notice that the first widget initialized by a program will by default become
a child of the TopLevel widget (see question X02), and will thus be in a
separate window.

There are other possible shells to use, such as OverrideShell. The
OverrideShell has gotten its name because although it creates a separate top
level window, it overrides all requests from the window manager, and will
therefore not be resizable, etc.
----------------------------------------------------------------------------

X04) Why do I get the error "clockWidgetClass: undefined" when linking my
AwEnv program using the xt/v1.8 libraries? [corrected in r4.0]

The X libraries in the Mjolner System are based on X11 release 5 (X11R4/R5).
Support for X11R6 is not included in release 3.0 of the Mjolner System. But
with a few exceptions, X11R6 is backward compatible with X11R5. One of the
few exceptions is the reason for the above error: Some very infrequently
used widgets have been removed from the Athena widget set in X11R6.

To fix the error you should have your system administrator apply the
following patch to the file ~beta/Xt/v1.8/private/external/awInt.c:

13d12
< #include <X11/Xaw/Clock.h>
15,16d13
< #include <X11/Xaw/Logo.h>
< #include <X11/Xaw/Mailbox.h>
37d33
<
53,55d48
< int getClockWidgetClass(){return ( (long) clockWidgetClass);}
< int getLogoWidgetClass(){return ( (long) logoWidgetClass);}
< int getMailboxWidgetClass(){return ( (long) mailboxWidgetClass);}

That is, remove all lines referring to the clock, logo, and mailbox widgets.
Then the system administrator should compile one of the awenv demos to get
the changes incorporated into the system.

To simplify correction of the above errors, a patch for the Mjolner System,
release 3.0 and 3.1 has been supplied. It can be fetched from
ftp://ftp.mjolner.com/pub/X11R6_patch,.

----------------------------------------------------------------------------

X05) Why do I get the error "Error: NULL ArgVal in XtGetValues" when
executing my Xt program using the xt/v1.8 libraries? [corrected in r4.0]

This is due to a programming error in the Mjolner System interface to the X
toolkit. The error does not seem to influence programs linked under X11
release 5, but (at least) X11R6 on Linux encounters it.

1. In the file ~beta/Xt/v1.8/xtlib.bet, the definition of the pattern
argList should be changed to:

argList: cStruct
(# byteSize::< (# do 100->value #);
max: (# exit R.range div 2 #);
extend:
(# size: @integer;
enter size
do (if size=0 then R.range->size
else size-R.range->size;
if);
size->R.extend;
#);
set: @
(# number: @integer;
cStr: @integer;
value: @integer;
enter (number,cstr,value)
do (* Cannot check ranges since no GC's may occur.
* The user needs to do the bookkeeping himself
* using 'max' and 'extend'.
* The reason for this is that 'value' may be
* the computed address of an integer.
*)
cstr->R[number*2-1];
value->R[number*2]
#);
get: @
(# number: @integer;
enter number
exit R[number*2]
#);
getName: @
(# number: @integer;
t: ^text;
enter number
do r[2*number-1]->CStringToText->t[];
exit t[]
#);
#);

2. In the file ~beta/Xt/v1.8/private/xtenvbody.bet, the two fragments
IntegerResourceGet and AncestorSensitiveGet should be changed to:

--- IntegerResourceGet: dopart ---
do (1,resourceName, @@value)->private.wargs.set;
(Thewidget,private.wargs[],1)->XtGetValues;

and

--- AncestorSensitiveGet: dopart ---
do (1,xtnancestorsensitive,@@value)->private.wargs.set;
(Thewidget,private.wargs[],1)->XtGetValues;

respectively.
3. In the file ~beta/Xt/v1.8/private/awenvbody.bet, the fragment
FloatResourceGet should be changed to:

--- FloatResourceGet: descriptor ---
(# status,res: @integer
do (1,resourceName,@@value)->private.wargs.set;
(theWidget,private.wargs[],1)->XtGetValues;
resolution->res;
(@@value,res)->getQuotFromFloat->value
#)

4. In the file ~beta/Xt/v1.8/motif/private/basicsbody.bet, the three
fragments MotifStringResourceGetText, MotifStringResourceGet, and
ProcResourceGet should be changed to:

--- MotifStringResourceGetText: descriptor ---
(# S: @MotifString;
do (1,resourceName,@@S.value)->Private.Wargs.Set;
(TheWidget,Private.Wargs[],1)->XtGetValues;
S.getText->t[];
S.destroy;
#)

and

--- MotifStringResourceGet: descriptor ---
(#
do (1,resourceName,@@value)->private.wargs.set;
(thewidget,private.wargs[],1)->XtGetValues;
#)

and

--- ProcResourceGet: descriptor ---
(#
do (1,resourceName,@@p)->private.wargs.set;
(Thewidget,private.wargs[],1)->XtGetValues;
#)

respectively.
5. In the file ~beta/Xt/v1.8/motif/private/rowcolumnbody.bet the two
fragments RowColumnLabelStringGetText and RowColumnLabelStringGet
should be changed to:

--- RowColumnLabelStringGetText: descriptor ---
(# S: @MotifString;
do (1,resourceName,@@S.value)->Private.Wargs.Set;
(TheWidget,Private.Wargs[],1)->XtGetValues;
S.getText->t[];
S.destroy;
#)

and

--- RowColumnLabelStringGet: descriptor ---
(#
do (1,resourceName,@@value)->private.wargs.set;
(thewidget,private.wargs[],1)->XtGetValues;
#)

respectively.

cd $BETALIB/Xt/v1.8 beta -q -c private/awenvbody.bet motif/private/rowcolumnbody.bet to get the changed files recompiled. These changes will be incorporated in version 1.9 of the Xt libraries. To simplify correction of the above errors, a patch for the Mjolner System, release 3.0 and 3.1 has been supplied. It can be fetched from ftp://ftp.mjolner.com/pub/X11R6_patch,. Please see the README file for details. ---------------------------------------------------------------------------- X06) How do I set font information in MotifStrings? In order to set font information in MotifStrings, you can use the following as a template: sensorLabel: @Label (# init:: (# s: @labelString; t: @MotifString (# init:: (# do ('Sensor:','ItalFont',XmSTRING_DIRECTION_L_TO_R) -> t.setTextSegment; #); #); do (...) t.init; t->s.set; #); #); ---------------------------------------------------------------------------- X07) Resource specification errors in Xt/v1.9 [corrected in r4.0] Version 1.9 of the BETA interface to X (part of r4.0) solves most of the errors appearing when using X11R6 (e.g. the errors in X04 and X05). This is done, among other things, by introducing BooleanResource, CharResource and ShortResource to correctly model the interface to X resources with different physical representations. Unfortunately a few of the resources was not converted correctly. This means that you may get wrong behaviour when reading these resources. To fix this you can change the following in the Xt/v1.9 sources, and recompile the libraries (after appropriate setting of permissions): Change from IntegerResource to ShortResource: --------------------------------------------- motif/rowcolumn.bet: RowColumn.numColumns motif/texts.bet: TextField.columns Change from IntegerResource to BooleanResource: ----------------------------------------------- awenv.bet: SimpleMenu.menuOnScreen awenv.bet: Paned.refigureMode awenv.bet: AsciiText.autoFill awenv.bet: AsciiText.resize awenv.bet: AsciiText.displayNonprinting awenv.bet: CoreLIB.resizable xtenv.bet: Core.mappedWhenManaged xtenv.bet: Shell.allowShellResize xtenv.bet: Shell.overrideRedirect xtenv.bet: Shell.saveUnder xtenv.bet: WMShell.input xtenv.bet: WMShell.transient xtenv.bet: WMShell.waitForWM xtenv.bet: TopLevelShell.iconic motif/bulletinboard.bet: BulletinBoard.defaultPosition motif/lists.bet: MotifList.automaticSelection motif/scale.bet: Scale.highlightOnEnter motif/texts.bet: ScrolledText.scrollVertical motif/texts.bet: ScrolledText.scrollHorizontal motif/texts.bet: ScrolledText.scrollLeftSide motif/texts.bet: ScrolledText.scrollTopSide motif/texts.bet: TextField.verifyBell These errors will naturally be corrected in the next release. ---------------------------------------------------------------------------- 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" (using v5.0 of the compiler)? [corrected in r4.0] If you want to write: persons: [100]@person (which is not implemented in version 5.0 of the BETA compiler), 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. In version 5.1 of the BETA compiler, persons: [100]@person is implemented. ---------------------------------------------------------------------------- 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. See also L22. ---------------------------------------------------------------------------- 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. Similar problems can arise with other, existing UNIX commands. [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 compiler switches. In version v5.0 of the compiler, you can use the -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. As of version v5.1 of the compiler, the switch -noquawarn have been renamed to --noWarnQua, and the switch -quawarn have been renamed to --warnQua. ---------------------------------------------------------------------------- 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. ---------------------------------------------------------------------------- C09) What does "virtual prefix not implemented" mean? [corrected in r4.0] A couple of typos in the compiler manual [MIA 90-02(1.3) August 1994] for version v5.0 of the compiler have caused some confusion over this message. Section 5, item 8 ("Implementation Restrictions") should read as follows: 8. Virtual superpatterns, i.e., A::< (# ... #); (* where A is some virtual *) B: A(# ... #); have not been implemented. By using a final binding, this limitation can often be overcome like this: A:: (# ... #); (* A is no longer virtual *) B: A(# ... #); The situation may also occur in a more indirect way: graph: (# node:< (# ... #); nodeList: @list(# element::< node #); ... #); Here the virtual further binding of element in list is not allowed, since node is itself virtual. The next version of the compiler will allow final binding using a pattern that is itself virtual. That is, you will be allowed to do this: graph: (# node:< (# ... #); nodeList: @list(# element:: node #); ... #); In version 5.0 of the compiler, this situation is not handled correctly. Instead you can do as follows: graph: (# node:< (# ... #); nodeListElement: (# n: ^node enter n[] exit n[] #); nodeList: @list(# element::< nodeListElement #); ... #); General virtual prefixes behave much like multiple inheritance and will not be implemented in the near future. These errors have been fixed in the manual for the version v5.1 of the compiler. ---------------------------------------------------------------------------- C10) What should I do if the compiler prints "Please report the error to Mjolner Informatics" and stops? The compiler may under very rare conditions run into an error from which it is unable to recover. It will often print out the message "Please report the error to Mjolner Informatics" just before stopping. If you run into an error like this, you should do the following: 1. Check in question C11, that the error has not yet been reported. 2. If it has not been reported, please make an archive with the following files (using e.g. tar on UNIX, and e.g. StuffIt or CompactPro on macintosh): o all relevant .bet source files o the .dump file of the compiler, if it exists o a file with the compiler output leading to the error Then please mail this file to support@mjolner.com with a short description of the error. For users of r4.0, you will find a new tool, betatar, which is usefull for packing the entire set of source files into a tar-file (only available on UNIX platforms) ---------------------------------------------------------------------------- C11) What are the known errors in v5.0 of the compiler? The following paragraphs deals with various bugs and workarounds in the different compiler versions. ---------------------------------------------------------------------------- C11.1) Bugs in version 5.0 of the compiler Since the release of v5.0 of the compiler in august 1994, the following errors have been reported. Some of these errors occur in very specific situations, that are hard to describe in general, but others may be generally presented, please see below. C11.1.1. Static Constants [fixed in v5.1] The following program will make the compiler crash: ORIGIN '~beta/basiclib/current/betaenv'; --- program: descriptor --- (# E: @(# exit 1 #) #) The compiler reports: ******* System error!!! Constant used as static item Please report this error to Mjolner Informatics and then stops. This is because constants should be declared without the '@' sign, i.e.: ORIGIN '~beta/basiclib/current/betaenv'; --- program: descriptor --- (# E: (# exit 1 #) #) C11.1.2. Computed remotes and virtuals [fixed in v5.1] The computed remotes, that the compiler supports in general from release v5.0, will sometimes make the compiler crash, especially if virtuals are involved. Example: ORIGIN '~beta/basiclib/current/betaenv'; INCLUDE '~beta/containers/current/list'; --- program: descriptor --- (# point: (# x: @integer; #); pointList: @List (# element::point; headx: (# exit (head).elm.x #); #); #) This program makes the compiler crash with the error: ******* System error!!! Pre is empty/null(virtual binding) Please report this error to Mjolner Informatics The workaround in this case is to avoid the computed remote in headx: ORIGIN '~beta/basiclib/current/betaenv'; INCLUDE '~beta/containers/current/list'; --- program: descriptor --- (# point: (# x: @integer; #); pointList: @List (# element::point; thehead: ^theCellType; headx: (# do head->thehead[]; exit thehead.elm.x #); #); #) C11.1.3. "T1PROGRAM undefined" reported by the linker [fixed in v5.1] As explained in section 7.3 "Assembler and Linker Errors" in the compiler reference manual [MIA 90-02], if an unbound SLOT of category Descriptor or Dopart exist in your program, then this is currently not reported by the compiler itself, but will be detected as an "Undefined Entry" by the linker. Especially if you are new to BETA programming, you may wonder why compiling this fragment (foolib.bet): ORIGIN '~beta/basiclib/current/betaenv'; --- lib: attributes --- foo: (# (* ... *) #); with "beta foolib" causes the linker error "T1PROGRAM undefined". In this case the reason is that the fragment is actually a library fragment - it only declares attributes to be used by some program. Specifically the PROGRAM descriptor SLOT defined in "betaenv" has not been bound, and thus the error. The solution is quite simple: Just compile the program as "beta -c foolib" instead. The next version of the BETA compiler will not attempt to do the linking if the PROGRAM SLOT is not bound. If you think this is strange, compare to the equivalent situation in C (foolib.c) foo() { /* ... */ } If you compile this file with e.g. "cc foolib.c", you will often get the linker error that "_main" is not defined. The solution here is like in BETA: "cc -c foolib.c" Version v5.1 of the compiler may under rare conditions exhibit the above behaviour, in which case you should use the above workaround, except the the compiler switch -c in v5.1 have been renamed to -x. C11.1.4. Reference assignment of repetitions [fixed in v5.1] Consider the following example: ORIGIN '~beta/basiclib/v1.6/betaenv'; --- program: descriptor --- (# P0: (# #); P1: P0 (# #); R1: [5] ^P0; R2: [5] ^P1; do R1[]->R2[]; (*not legal*) #) It is not legal to assign a repetition reference to another repetition reference. Unfortunately the compiler does NOT catch this error. The program compiles and gives unpredictable results when executed. It is possible to have the following assignment R1->R2 which makes R2 be a copy of R1. But R1 and R2 do not refer to the same repetition. Note, it is of course possible to have the elemenst of R1 point to the same elemenst as P1: (for i: R1.range repeat R1[i][]->R2[i][] for) It would be possible to extend BETA to allow assigning a reference to a repetion object to another reptition, but there are currently no plans for this. C11.1.5. Assignment to index variables not checked The BETA book states that it is not legal to assign to the index variable of a for-imperative as in: (for i: 12 repeat ...; 5->i; ... for) This restriction is currently not checked by the compiler. Version v5.1 of the compiler still does not check for these assignments. ---------------------------------------------------------------------------- C11.2) Bugs in version 5.1 of the compiler Since the release of v5.1 of the compiler ultimo 1995, the following errors have been reported. Some of these errors occur in very specific situations, that are hard to describe in general, but others may be generally presented, please see below. C11.2.1) "T1PROGRAM undefined" still reported by the linker As mentioned in C11.1.3, version 5.1 of the compiler partly fixes the problem of "T1PROGRAM undefined". To be specific, v5.1 of the compiler checks, that the PROGRAM slot is met before initiating a call to the linker. However, it may fail as follows: beta frag1 frag2 if frag1 contains a PROGRAM slot, and frag2 does not, you will get the linker error for frag2: Once a PROGRAM slot has been seen, all fragments subsequently translated will be attempted linked. This error also happens if you invoke the compiler as beta -r frag1 and then enters frag2 as second fragment to compile when the repeating compiler asks for it. Also, if you have declared a Dopart- or Descriptor-slot in one of your files, and do not have a fragment, that binds these slots in any of the files in the dependency graph, then the linker may still fail with an undefined entry for this slot. See also C11.2.2. C11.2.2) Other undefined entries (compiler import error) [hpux9pa, nti only] [corrected in r4.0] Question: I experience errors from the linker concerning undefined entries, and I am sure that all of my slots are bound. What is wrong? Answer: You may have encountered a situation where the internal import tables of the compiler gets confused because two of your slots have identical names. Consider: main.bet: ORIGIN '~beta/basiclib/v1.6/betaenv'; INCLUDE 'foo'; --PROGRAM: descriptor-- (# do foo #) foo.bet: ORIGIN '~beta/basiclib/v1.6/betaenv'; BODY 'foobody'; -- LIB: attributes -- foo: (# size: (# s: @integer <<SLOT size:dopart>> exit s #); do size -> putint; newline; #) foobody.bet: ORIGIN 'foo'; INCLUDE 'bar'; -- size: dopart -- do (&bar[]).size -> s bar.bet: ORIGIN '~beta/basiclib/v1.6/betaenv'; BODY 'barbody'; --LIB: attributes-- bar: (# size: (# s: @integer <<SLOT size:dopart>> exit s #)#); barbody.bet: ORIGIN 'bar' -- size: dopart -- do 1 -> s Although somewhat stupid, you would expect this program to print "1" onto the screen. And it does so on most platforms. But on the platforms hpux9pa (HPPA 9000/700 running HP-UX 9) and nti (Windows 95 / Windows NT), when assembling the code produced for foobody, you get an error like undefined label - M2BAR The reason for this, is that the compiler gets confused by the two dopart slots both tagged with "size". The solution is to use two distinct names, e.g. foosize and barsize. Such a naming scheme is advisable to use in general - notice that if the two SLOTs had been of kind Descriptor, then on all platforms, you would get multiply defined: M1SIZE C11.2.3) Qualification error in code generation of division expression [linux, nti only] Sometimes v5.1 of the compiler on Linux and Windows 95/NT will will crash with a Qualification Error during code generation of expressions involving division. If the resulting dump file starts with something like item <op1ToEBX#> in ~beta/.../system/v5.1/LINUXmachine -- GDIV-~ in ~beta/.../system/v5.1/LINUXmachine then it is this error that has occurred. On linux, the error will occur if you compile e.g. the demo ~beta/demo/r3.1/Xt/awenv/scroll.bet. None of the demos on Windows NT/95 contain expressions that will cause this error, but you may encounter the problem in files of your own. The solution is to split up the expression involving the division into simpler expressions. Use option --traceCode to find out what expression is causing the error. ---------------------------------------------------------------------------- C11.3) Bugs in version 5.2 of the compiler Since the release of v5.2 of the compiler august 1996, the following errors have been reported. Some of these errors occur in very specific situations, that are hard to describe in general, but others may be generally presented, please see below. C11.3.1) Strange error messages like "attempting to translate foo..db.bet" [corrected in r4.0.1] Some of the internal restructuring of the compiler that has been done for version 5.2 has caused a new bug to appear. The symptom of the bug is that .bet sometimes gets appended to the file name reported, when e.g. an attempt to write a file fails because of permission problems. An example is You are attempting to translate the file /users/smith/beta/private/sun4s/foobody..db.bet You do not have permission for doing this! in case the file /users/smith/beta/private/sun4s/foobody..db, or the directory it resides in, is write protected. There is currently no workaround for this bug, but it is usually obvious what file name should have been reported. C11.3.2) Errors when evaluating expressions involving reals and external calls [corrected in r4.0.1] On all supported platforms, using both reals and external (C) calls in an expression may yield unpredictable results. For instance the following program ORIGIN '~beta/basiclib/v1.5/math'; --PROGRAM: descriptor-- (# do (1->sqrt) -> putint; newline; (10->log10) -> putint; newline; (1->sqrt)+(10->log10) -> putint; newline; #) will give the (wrong) output 1 1 4 on Solaris. The only known workaround is to split up the expressions, so that the parts that call the external functions are isolated (like the first part of the above program). ---------------------------------------------------------------------------- C12) Tracing the work of compiler? In the extremely rare event that the compiler crashes during compilation of your program, you may yourself do some tracing of the compilation to find out what particular part of your program, that makes the compiler crash. You do this by specifying some compiler switches: 1. If the compiler crashes during *code generation* of a fragment, please do this: beta -s 308 311 0 <file> This will make the compiler print out each declaration and imperative just before code is generated for it. Thus when the compiler crashes, you can see what part of your program caused it. 2. If the compiler crashes during *checking* of a fragment, please do this: beta -s 191 192 193 0 <file> This will make the compiler print out each descriptor, declaration and imperative just before checking it. Thus when the compiler crashes, you can see what part of your program caused it. In version v5.1 of the compiler, you can use the two new compiler switches --traceCode and --traceCheck instead. ---------------------------------------------------------------------------- C13) Problem with floating point expressions in connection with repetitions [fixed in v5.1] The compiler does not generate correct code when floating point expressions are used in the calculation of repetition ranges as in: R: [FR1] ... do ... FR2->R.extend FR3->R.new where FR1, FR2 and FR3 are expressions yielding a floating point value. The compiler should convert these floating point values into integer values, but fails in doing so. You can get around the error by explicitly converting the expression to an integer value. If "I" is an integer variable, then the following will work: R: [FR1->I] ... do ... FR2->I->R.extend FR3->I->R.new This problem have been fixed in version v5.1 of the compiler. ---------------------------------------------------------------------------- C14) New features introduced in the Compiler C14.1> New features in version 5.3 of the Compiler BUILD property BUILD property now included in the BETA compiler. This replaces the use of MAKE. See the Compiler Manual p33 for more details. Binary Object Files The compiler now generates binary object files on Win95/nt (except for Borland SDK). This eliminates the need for an external assembler. Debug info The compiler now generates debug info on Win32 platforms. This enables the debugger, Valhalla, to work. Gnu The compiler now supports gnu as SDK. This makes personal use completely free on Win32. SGI: IRIX 6.x SGI: IRIX 6.x is now supported (see however SG04). C14.2) New features in version 5.2 of the Compiler The following new features have been implemented in version 5.2 of the compiler, compared to version 5.1. New Platforms Much effort has been put into porting the compiler onto new platforms: o A final version for Silicon Graphics MIPS is now available. o The Linux compiler now generates binary code directly. o Work is ongoing to make a binary compiler for Windows NT and Windows 95. o Work is ongoing to make native binary code generation for PowerPC based Macintoshes. This work has caused a lot of changes to the interior of the compiler and runtime system. These changes should, however, be transparent to the user. ## now allowed for objects as well as for patterns You may now use P## as an alternative to P.struc when P is an object. Previously ## was only allowed for patterns.$CC set in UNIX job files
The job files on UNIX platforms now set the CC environment variable to
a reasonable default value before executing the MAKE commands. Thus
$(CC) may now be used in the make files on UNIX platforms. Check for bound SLOTs The compiler will now only attempt to link if a PROGRAM slot has been found in the dependency graph (this feature was introduced in v5.1 of the compiler, but the implementation was buggy). If SLOTs of category dopart or descriptor in the dependency graph are not bound, and linking would otherwise have happened, the compiler now issues a warning and does not attempt to link. This is the kind of situation that could give an "Undefined Reference" error at link time in v5.1 (and earlier versions) of the compiler. Likewise, if two or more fragments try to bind the same SLOT, the compiler will give a warning. This is the kind of situation which could give an "Multiply Defined Symbol" error at link time in v5.1 (and earlier versions) of the compiler. Interfragment leave/restart Added support for interfragment leave/restart as in foo.bet: ORIGIN '~beta/basiclib/v1.5/betaenv'; BODY 'foobody'; --PROGRAM:descriptor--- (# do L: <<SLOT LL:descriptor>> #) foobody.bet: ORIGIN 'foo'; --LL:descriptor-- (# do leave L #) This feature did not work in previous versions of the compiler. Generalized special characters in string literals The following special characters are now allowed in BETA string literals (some of them, e.g. \t, has worked in previous versions, too): \a alert (bell) character \b backspace \f form feed \n newline \r carriage return \t horizontal tab \v vertical tab \\ backslash \? question mark \' single quote \" double quote \ooooctal number The \ooo form can be shortened to \o or \oo, provided that the character immediately following it is not a digit. Note that the backslash character is now an escape sequence which must itself be escaped if used literally. Thus, one must now write '\\' instead of the old-style '\'. Note that you may now use \' as an alternative to the old-style '' for including literal quotes in a string. Thus, 'Tom\'s Cottage' produces the same result as 'Tom''s Cottage'. C14.3) New features in version 5.1 of the Compiler The following new features have been implemented in version 5.1 of the compiler, compared to version 5.0. General Repetitions Repetitions of static objects are now allowed. That is, given A: (# ... #); V:< A; P: (# ... #); S: <<SLOT SS:Descriptor>>; then X: [10] @P; XC: [11] @|P; Y: [12] @V; YC: [13] @|V; Z: [14] @S; ZC: [15] @|S; are all allowed. The operators new and extend also applies to repetitions of this kind, like for other repetitions. Qualification from pattern attributes It is now possible to qualify a reference as in the following example: grammar: (# symbol: (# ... #); .... #); A: ^grammar.symbol This was previously forbidden because grammar is not an object. THIS(P) applies to prefix Previously THIS(P) was only known to work inside the P pattern. Now it also works for prefixes of P, e.g.: Q: (# x: @integer; ... #); P: Q(# x: @integer; do ... THIS(Q).x -> ... (* will get the x of Q *) #) Short-circuit Boolean Expressions Boolean expressions are now implemented as short-circuit. That is, B2 is not evaluated if B1 is true in B1 or B2 and B2 is not evaluated if B1 is false in B1 and B2 Final Binding to a Virtual Pattern Final binding of a virtual pattern to another pattern, which is virtual itself, is now allowed. That is, given the following: P1: (# V:< ... (* V virtual *) W:< ... (* W virtual *) #); it is now allowed to do the following in a specialization of P1: P2: P1(# W:: V (* V still virtual, but W now final bound *) #); The implementation of this is somewhat preliminary. Special Characters in String Literals The compiler will no longer accept newline, carriage return or file separator characters in string literals, not even if escaped by \. This is to prevent errors that could occur when a string literal was not closed, i.e. a closing quote was forgotten. This kind of error is no longer possible. Of course, \n is still accepted in string literals. Furthermore literal null-characters \000 in strings will now result in a warning, since this may yield unpredictable results. MAKE Property Behavior When specifying a MAKE property for automatic recompilation of external sources, the makefiles which are run are now executed relative to the directory in which the file containing the MAKE property is placed. This simplifies writing of makefiles a lot. Consistent Command Line Options The command line options that can be used when activating the compiler have been revised and are now more consistent than previously: most options now have an activating and a deactivating form. Furthermore most options now have a short one-character equivalent for the non-default form. The short options have been chosen so that the character matches the first character in the long form as often as possible. Short options can now be concatenated. Please inspect chapter 8 of the Compiler manual for details, and please note that a few options have different meanings than previously, e.g. -c now corresponds to --noCode, where it previously corresponded to --noLink. C14.4) New features in version 5.0 of the Compiler The following new features have been implemented in version 5.0 of the compiler, compared to version 4.4.2. Xor Primitive An xor primitive is now supported as a basic operation on booleans. That is b1, b2, b3: @boolean do (b1 xor b2)->b3 is now possible. Simple If Often, the following if-construct is used b: @boolean; do (if b//TRUE then ... else ... if); The BETA compiler now supports an extension to the BETA language called simple-if. This extension means that the case selector may be omitted if the evaluation on the left hand side exits a boolean; it will default to //TRUE. That is, the above may be written: b: @boolean; do (if b then ... else ... if); Labelled imperatives Labelled imperatives were previously defined in two forms: L: Imp; and (L: Imp1; ...; :L) The second form has now been removed from the language. Instead, the compiler offers the form L: (# do Imp1; ... #) Note that this form is implemented very efficiently in the case where there are no declarations in the object descriptor. ---------------------------------------------------------------------------- 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<return> foo<return> 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<return> 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 System file directory structures? This entry describes the file structure of the Mjolner 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 System to structure the various subsystems of the Mjolner 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/ | +-- (* ast 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 (* ast files *) indicates that there will be an Fi.ast file (or an Fi.astL for Intel-based 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: sun4s, sgi, hpux9pa, ppcmac, nti, and linux. There may be one subdirectory of each machine type. The substructure consisting of (* ast 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/ | +-- (* ast 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 System. 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 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. ---------------------------------------------------------------------------- B06) Error in v1.4/seqContainer.bet? [corrected in r4.0] The queue pattern in v1.4/seqContainer.bet contains an error that makes the pattern behave like a stack and not a queue. This error is removed in v1.5/seqContainer.bet. ---------------------------------------------------------------------------- B07) Error in v1.4/regexp.bet? [corrected in r4.0] The v1.4/regexp.bet library contains an error that manifests itself by repetition index runtime errors when regexp is used on empty texts. This error will be removed in v1.5/regexp.bet. ---------------------------------------------------------------------------- B08) Error in v1.4/basicsystemenv.bet? [corrected in r4.0] The objectPort pattern in v1.4/basicsystemenv.bet contains an error that makes it almost unusable. This error is removed in v1.5/basicsystemenv.bet. ---------------------------------------------------------------------------- B09)Why does my guienvsystemenv program stop at startup? Possible problems in your program: * Your program was not a specialisation of systemenv * You did not set theWindowEnv to the guienv instance in setWindowEnv * Your program forks in the dopart of guienv. You should fork systems in the dopart of systemenv. This might change in a future release Your program should look like this: -- program: descriptor -- systemenv (# setWindowEnv:: (# GUI[] -> theWindowEnv[] #); GUI: @guienv (# do ... (* open windows here *) #); do ... (* fork systems here *) #) ---------------------------------------------------------------------------- PART V: Platform Specific Issues ---------------------------------------------------------------------------- SECTION V: BETA on Macintosh ---------------------------------------------------------------------------- M01) What are the system requirements to run BETA on Macintosh? Release 3.1: BETA for Motorola Mac * CPU: MC68020 processor or later (Release r3.1 works on PowerPC, please look at question M05) * RAM: 5 Mb memory (8 or 16 Mb is recommended) * Disk: 16 Mb of free space on harddisk * OS: System 7.x or later (or Multifinder under System 6.x) * The MPW environment version 3.2 or later (please see question M02 for details). * An FPU to be able to use reals, please see question M04 for more details. That is, Release 3.1 runs on machines like Classic II, SE/30, LC, LC II, LC III, Centris, and all Macintosh II, Quadra and PowerBook models (except PowerBook 100). Release 3.1 cannot be used at Mac Plus, SE, and Classic. Release 3.1 works on PowerPC, please look at question M05. Release 4.0.2 or later: BETA for PowerMac * CPU: PowerPC 601 processor or later * RAM: 40 Mb memory * Disk: 60 Mb of free space on harddisk * OS: System 7.x or later * The MPW environment, version 3.4.1 or later (please see question M02 for details), including o MPW Shell o Interfaces&Libraries o PPCLink version 1.4 or later; or MWLinkPPC from Metrowerks, see M02 o Rez These can be obtained from Apple from the Essentials-Tools-Objects (ETO) volume 20 or later. * FPU to be able to use reals (please see question M04 for more details). However, a hardware FPU is build into most PowerPC Macintosh. That is, Release 4.0.2 should work for alle PowerMac models. Please note that, Release 4.0.2 or later does not work on motorola macintoshes. ---------------------------------------------------------------------------- M02) What is MPW. Where do I get it? MPW stands for "Macintosh Programmers Workshop", which is the official programming environment for the Macintosh, developed by Apple, Inc. The BETA compiler runs as an MPW tool, that is, it is a command, that can be invoked from the MPW Shell (command interpreter). You will need MPW 3.4 or later to use BETA. In addition to the MPW Shell, the compiler uses the MPW Link and Rez tools to build the programs. As of october 1997, Apple has decided to make MPW freely available for downloading. You can download it from * ftp://dev.apple.com/devworld/Tool_Chest/Core_Mac_OS_Tools/. The current versions of the packages needed are * MPW-3.4.2.sit.hqx. * Interfaces_Libraries-3.0.1.sit.hqx. Please notice, that new versions may have been available when you read this. As an alternative to Apple's MPW, you can use the MPW supported by Metrowerks CodeWarrior. The MWLinkPPC linker included in this commercial package is is up to 10 times faster than PPCLink from Apple. ---------------------------------------------------------------------------- M03) How do i download MPW from Apple? To download MPW follow these steps: 1. Launch 'Fetch 3.0.1' 2. To make the connection, paste ftp://dev.apple.com/devworld/Tool_Chest/Core_Mac_OS_Tools/MPW_etc./ in the "New Connection" dialog. 3. In the menu, choose Customize Post Processing and disable the "Stuffit Archive" post processing options, if there are any. This will allow you to only unpack the items that you need. 4. Select the "MPW-GM" directory in the file list and Choose Remote Get Directories And Files... in the menu. This will download the entire MPW-GM directory to your disc. 5. Now you need to unpack the items that are needed. A sit archive are unpacked by dragging it to the "Stuffit Expander" application. You need to unpack the following items: 1. Interfaces and libraries Unpack: MPW-GM:Interfaces&Libraries:Interfaces:RIncludes.sit.hqx MPW-GM:Interfaces&Libraries:Libraries: SharedLibraries.sit.hqx MPW-GM:Interfaces&Libraries:Libraries: PPCLibraries.sit.hqx 2. The mpw shell application and workfiles Unpack MPW-GM:MPW:MPW_Shell.sit.hqx This will create a folder named "MPW_Shell.sit.hqx Folder". Move all the items in that folder one level up so they are placed directly in the "MPW-GM:MPW:" folder. 3. The tools Command ('i' to return to index): Unpack all files in the "MPW-GM:MPW:Tools: " folder. 6. Rename the MPW-GM to "Development" or some other name not containing a special character (or space). This is needed because there is an error in the Userstartup*beta script concerning spaces in the MPW pathname. You should also give your hard disc a name without special characters. 7. Set the preferred size of the MPW Shell in the Finder Info to 20 000 k or more. 8. Drag the UserstartUp*Beta file into the MPW Shell folder. Launch MPW Shell and point out the Beta folder in the dialog that will appear. ---------------------------------------------------------------------------- M04) Do I need a floating point unit to use BETA? Yes, to be able to run BETA programs, that use "reals", your machine should have a built-in FPU, *or* you can install an FPU simulator. Several free/shareware FPU simulators are available, e.g. SoftwareFPU, which can be fetched from most macintosh archives, or from the writer, John Neil, at http://www.jna.com/software.html. ---------------------------------------------------------------------------- M05) Does BETA work on PowerPC machines? As of release 4.0.2, PowerPC based macintoshes are the only macintoshes supported. Release 3.1 of BETA can be run on PowerMac's using the MC680x0 simulator. That is, the applications will run with the usual slowdown for simulated programs on PowerMac. ---------------------------------------------------------------------------- M06) Does BETA work on Motorola machines? Release 3.1 of the Mjolner System is the last supporting Motorola Macintoshes. As of release 4.0.2, PowerMacintosh is the only Macintosh platform supported. ---------------------------------------------------------------------------- M07) Known bugs, limitations and inconveniences in release 4.0.2 The current release 4.0.2 is the first for power mac, and is still considered an "alpha release". There are a number of known bugs, limitations and inconveniences: 1. Link time is very long for BETA programs. We have not been successful in getting appropriate documentation from Apple to make optimal generation of the XCOFF files. 2. Freja is not yet available for PowerMac 3. Valhalla is not yet available for PowerMac 4. bobsit will not work, because the exbobs program did not get ready for r4.0.2 5. Problems with Sif o Closing a workspace may make the machine crash 6. Persistence does not work 7. Check for suspend involving callbacks is not done. If you do a suspend in a callback situation the program is likely to crash. 8. Integer division by zero will yield unpredictable results (should be caught as an exception as on other platforms). 9. The pattern doGC in betaenv does not work on ppcmac. This is used in implementation of sysutils/v1.5/scanobjects used in the demo demo/sysutils/objinterface/scanobj which consequently does not work 10. The PutReal pattern in ~beta/basiclib/v1.5/numberio does not work. This is used in the demo programs in ~beta/demo/basiclib/reals/ and ~beta/demo/basiclib/random/tstgenchi.bet which does not produce a correct output. 11. The touch and modtime.set operations on diskentry does not work 12. The iget operation on keyboard is not implemented. This is used in the demo programs in: ~beta/demo/basiclib/iget/ which consequently does not work 13. Systemenv is not implemented 14. Process is not implemented 15. Bifrost is not implemented 16. Frigg is not available, due to some problems (Will be fixed in the next release). 17. There is a number of problems with GuiEnv: o There is no support for resources like icons, cursors etc. o There are some update problems. o The only way to make a window appear like a modal dialog is by further binding "menubarVisible" to exit false. o figureItems does not work yet. 18. The "Commando BETA" command in the Beta menu, does not work 19. the new timedate library does not work (linker error). ---------------------------------------------------------------------------- M08) Known bugs, limitations and inconveniences in release 4.1 M08.1) Why do I get a linker warning about errno? There is two macintosh libraries that contains errno: StdCLib and OTXTILib - hence the warning. OTXTILib only is used if you include the process or distribution library. This warning can safely be ignored. M08.2) How do I open a PersistentStore in psbrowser on the macintosh? You have to move the psbrowser application into the directory that contains the persistentstore you want to open before launching psbrowser. Now you can open the persistentstore via the open command in the file menu. Be aware that the program that generated the persistentstore must call persistentstore_fullnamepatch included from ~beta/objectbrowser/v1.6/psbrowser/psfullnamepatch M08.3) Why does my systemenv program not work as expected in MPW? If you link a systemenv program as a MPW tool, the keyboard will block all systems when you call any of the get operations: getLine, getInt etc. The solution is to link your program as an application. ---------------------------------------------------------------------------- M09) I cannot compile Beta programs with MPW that ships with CW Pro 2. The problem is caused by a reorganization of the files in Interfaces&Libraries:Interfaces:RIncludes: A solution would be to replace the RIncludes folder with an older version. If you have CW Pro 1, you can grab the Rincludes in the 'CodeWarrior MPW:Interface&Libraries:Interfaces:' folder on that disc. Otherwise, a compatible version of Rincludes can be downloaded from ftp://dev.apple.com/devworld/Tool_Chest/Core_Mac_OS_Tools/MPW_etc./MPW-GM/In terfaces&Libraries/Interfaces/ ---------------------------------------------------------------------------- SECTION VI: BETA on Windows 95 and Windows NT ---------------------------------------------------------------------------- W01) What are the system requirements to run BETA on Windows 95 and Windows NT? * CPU: Intel 386/486/Pentium * RAM: 16Mb (32 recommended) * Disk: 45 Mb of free space. * OS: Windows 95 or Windows NT 3.5.1 or later. * Microsoft SDK, Gnu SDK or Borland SDK (only assembler, linker, make utilities and C libraries required). Microsoft SDK recommended. For more information, see W02. ---------------------------------------------------------------------------- W02) SDK Requirements for Windows 95 or Windows NT In order to use the Mjolner System you need to have an assembler, a linker, a make utility and C libraries from either Microsoft or Borland. The Microsoft utilities are recommended. These utilities must satisfy the following: 1. Microsoft Assembler: Starting from release r4.0.1, no assembler is needed any longer. For older releases (e.g. r4.0) an assembler is needed. You can install one of the following + MASM386.EXE and EDITBIN.EXE from the Microsoft WIN32SDK. + ML.EXE, which can be bought as a separate tool from Microsoft. ML.EXE is also part of Microsoft Development Network MSDN (level 2) and the Windows NT 3.5.1 DDK. Linker: + LINK.EXE from e.g. Microsoft Visual C++. Make: + NMAKE.EXE from e.g. Microsoft Visual C++. If you do not plan to use the BETA MAKE facility, you can do with a dummy NMAKE program, that simply exits 0. C libraries: + from e.g. Microsoft Visual C++. If you have installed Microsoft Visual C++ 2.0 or later for Windows 95 or Windows NT, you do not need any more software to run the Mjolner System. If you do not have Visual C++, you will have to get a linker and C libraries from Microsoft (http://www.microsoft.com/). 2. Gnu. Assembler: No assembler is needed. Linker: gcc and ld. Make: The Gnu make utility. C libraries: The C libraries that come with gcc for Win32. 3. Borland. Assembler: + TASM32.EXE, which is sold as a separate tool from Borland. Notice, that version 4.0 of TASM32.EXE does not work on Windows 95. A patch is available from the Borland "Patchs Available" WWW Page at http://loki.borland.com/cpp/Patchs.htm. The patch is directly available by FTP from ftp://ftp.borland.com/pub/techinfo/techdocs/language/tools/turboasm/. Linker: + TLINK32.EXE (version 1.0), which is included in the above Assembler package from Borland, does not work under Windows 95. It aborts with an "Illegal Instruction" error. + You need to obtain the TLINK32.EXE linker (version 1.50), which is part of the Borland C++ (version >= 4.5). Make: + MAKE.EXE, which is included in the above Assembler package from Borland, and is also part of Borland C++ (version >= 4.5). C libraries: + must be obtained from e.g. Borland C++ (version >= 4.5). If you have installed Borland C++ for Windows 95/NT, version 4.5 or later, all you need to install additionally is Borland Assembler (available from Borland). You can purchase these utilities from either Microsoft (http://www.microsoft.com/) or Borland(http://www.borland.com/). Please contact their national representatives for ordering information. ---------------------------------------------------------------------------- W03) Why do I need a MAKE facility? Question: I do not have a MAKE facility on my Windows 95/NT machine. Why do I need that - I thought that the BETA compiler analyzed the dependencies itself? Answer: The BETA compiler keeps track of dependencies between all involved beta files. However, if you want to link in object files generated by an external C compiler og assembler, you may add a MAKE property to make the BETA compiler invoke the make-facility to keep the external objectfiles up-to-date (see section 2.4 in "The Mjolner System - Using on Windows 95 / Windows NT [mia94-32]). If you do not use the MAKE property in your programs, in principle you do not need a make facility. But since a few of the standard libraries included in the Mjolner System contains such MAKE properties, you will need a make-facility anyway. However, since all external object files in the standard libraries are up-to-date when distributed by Mjolner Informatics, you can do with a dummy make-utility. For instance you may create a C file like this: main() { exit(0); } compile it with your C compiler, and install it in your path with the name MAKE.EXE (if you use the Borland SDK) or NMAKE.EXE (if you use the Microsoft SDK). ---------------------------------------------------------------------------- W04) Error in directory scan using Borland SDK? [corrected in r4.0] Question: Why does the following program fail with a memory exception on my windows 95/NT machine? I am using v5.1(6) of the compiler and SDK=bor. ORIGIN '~beta/basiclib/v1.4/directory'; --PROGRAM:descriptor-- (# d: @directory; do '.' -> d.name; d.scanEntries (# do select (# whenDir::< (# do (theDir).entry.path.name -> screen.putline #); #); #); #) Answer: This is due to an error in the directory library. The problem is, that the file %betalib%\sysutils\v1.4\private\nti\bor\directory_ntbody.obj in the release 3.1 distribution of the Mjolner System has been compiled with an older version of the compiler. The solution is to delete the obj-file and recompile %betalib%\sysutils\v1.4\private\directory_ntbody.bet. ---------------------------------------------------------------------------- W05) Make-error for lazyref_gc.c using Borland SDK? [corrected in r4.0.2] Question: When I use persistentstore or objectserver in my Windows 95/NT application I get this error from the compiler: MAKE Version 3.7 Copyright (c) 1987, 1994 Borland International Fatal: 'c:\beta\betarun\v2.7\nti\c\lazyref_gc.c' does not exist - don't know how to make it I have installed BETA in C:\BETA. Answer: The reason is that there were some problems to get the two make facilities from Microsoft and Borland to work with BETA. The solution was to handle the lazyref_gc.c file specially in the make files. However, the lazyref_gc.c file is part of the source code for the BETA runtime system, which is not distributed with the release. Solution: Create a dummy lazyref_gc.c and update timestamp of corresponding .obj file. This can be done by compiling and executing the following program: ORIGIN '~beta/basiclib/v1.4/directory'; INCLUDE '~beta/sysutils/v1.4/envstring'; --PROGRAM: descriptor-- (# d: @directory; f: @file; do ' Create directory for C file ' -> putline; '$(BETALIB)/betarun/v2.7/nti/C' -> expandEnvVar -> d.name;
(if not d.entry.exists then d.touch if);

' Create dummy C file ' -> putline;
'/lazyref_gc.c' -> ((d.name).copy).append -> f.name;
(if not f.entry.exists then f.touch if);

' Update timestamp of dependant object file ' -> putline;
'$(BETALIB)/objectserver/v2.1/private/nti/$(SDK)/lazyref_gc.obj'
-> expandEnvVar -> f.name;
f.touch;
#)

----------------------------------------------------------------------------

W06) Known bugs, limitations and inconveniences in release 4.0.2

1. Most parts of systemenv are still not implemented. Most of the demos in
demo\basiclib\systemenv fails. Specificly using the operation
"keyboard.get" will block.
2. Process and socket communication is currently NOT supported. It may
work, but known errors exist in these modules. These modules have been
scheduled for re-structuring. It is possible, though not likely, that
the interface specification changes.
3. Binary/ASCII files has a work-around (kluge) to compensate for a bug(?)
in Windows NT/95. If a text file with UNIX style EOL characters (\n) is
opened as a text file the offset (ftell) of the first character in the
file is the negative of the number of '\n's found in the first 512
bytes. The kluge is that if a file is opened as a text file and a '\n'
(UNIX EOL) is found before '\r\n' (Windows NT EOL) it will be opened as
a binary file.
4. File time stamps have proven difficulties in BETA on Windows NT. We (at
GMT+1) experience the problem that files are reported to have a
timestamp one hour less than the real time stamp of the file. This also
means that when touching a file entry the file will be touched with a
wrong time stamp (in out case one hour later than the real time).
5. Freja is not available for nti
6. Valhalla is not available for nti
7. The new timedate library does not work (linker error).

----------------------------------------------------------------------------

W07) Known bugs, limitations and inconveniences in release 4.1

1. Some parts of systemenv are still not implemented. Some of the demos in
demo\basiclib\systemenv fails. Specificly using the operation
"keyboard.get" will block the entire process, not only the component
issuing the call.
2. Binary/ASCII files has a work-around (kluge) to compensate for a bug(?)
in Windows NT/95. If a text file with UNIX style EOL characters (\n) is
opened as a text file the offset (ftell) of the first character in the
file is the negative of the number of '\n's found in the first 512
bytes. The kluge is that if a file is opened as a text file and a '\n'
(UNIX EOL) is found before '\r\n' (Windows NT EOL) it will be opened as
a binary file.
3. File time stamps have proven difficulties in BETA on Windows NT. We (at
GMT+1) experience the problem that files are reported to have a
timestamp one hour less than the real time stamp of the file. This also
means that when touching a file entry the file will be touched with a
wrong time stamp (in out case one hour later than the real time).
4. Freja is not available for nti
5. BETACC.EXE misplaced on CD:

The program BETACC.EXE is misplaced on the CD distribution of release
4.1
BETACC.EXE is used by the compiler when compilation of c-files is
required, eg. when beta-programs use the BUILD directive/external
pattern.
On the CD BETACC.EXE is placed in BETALIB but should be moved to
BETALIB\bin. eg.

move c:\BETA\BETACC.EXE c:\BETA\BIN\BETACC.EXE

----------------------------------------------------------------------------

SECTION VII: BETA on HPUX

----------------------------------------------------------------------------

HP01) What are the system requirements to run BETA on HPUX workstations?

HP9000/700:

* RAM: 16 MB, 32Mb recommended.
* Disk: 150 MB disk space
The installation is approx. 100 MB + documentation approx. 13 MB.
* OS: HP-UX 9
* X window system (Rel. 11.3 or newer)
* Motif 1.2 or later (not required for textual BETA programs)

----------------------------------------------------------------------------

HP02) Why do some callbacks cause "Illegal Instruction" on hpux9pa (using
v5.0 of the compiler)?

If the following program is compiled and run on an hpux9pa (HP series 700
HPPA, HP-UX 9.x) using the BETA compiler version v5.0), it displays a window
with the text "Timer" in it, prints a random number of 7'digits on the
screen, and then dies with "Illegal Instruction":

ORIGIN '~beta/Xt/v1.8/awenv';
--- program: descriptor ---
AwEnv
(# l: @Command
(# init:: (# do 'Timer'->label #)#);
t: @Timer
(# timeOut:: (# do 10->start; '7'->Put; #) #);
do l.init;
10->t.start;
#)

The reason for this, is that in v2.6 of the hpux9pa runtime system for BETA
there is an error, which occurs if a callback is called very soon after it
is installed. In this case it is called ~10 ms after being installed, and
almost no other code has been executed in this period of time. In this
situation an HPPA cache should have been flushed to ensure the correct
behaviour, but there was an error in the runtime system delivered with
release 3.0 of the Mjolner System. The solution is to acquire a patched
runtime system from Mjolner Informatics.
----------------------------------------------------------------------------

SECTION VIII: BETA on Linux

----------------------------------------------------------------------------

Lx01) What are the system requirements to run BETA on Linux machines?

* Linux (release 2.0 or later)
* CPU: Intel 386/486/Pentium
* RAM: 8Mb (16 to 32 recommended)
* X11 Release 5 or later
* OSF/Motif 1.2 or later (not required just to run compiler)
* Programs needed: (g)as, ld, make.

In lack of Motif libraries, you can use the Lesstif Motif clone. These
libraries works acceptable, but they are not 100% stabil. See
BETA-LESSTIF-FAQ
----------------------------------------------------------------------------

Lx02) How to make the BETA compiler version 5.0/5.1 work with Linux ELF
libraries [corrected in r4.0]

If you are using a Linux version with support for the ELF libraries, the
Mjolner System (release 3.1) cannot be used immediately. You will have to
introduce the following patch:

1. Make sure that /usr/lib/crt0.o can be found. E.g. do this:

pushd /usr/lib; ln -s /usr/i486-linuxaout/lib/crt0.o; popd

2. Make sure the linker is called with "-m i386linux", either by adding

in the top of basiclib/v1.4/private/betaenv_unixbody.bet, or

export BETALINKOPTIONS='-dc -dp -X -m i386linux';

The BETALINKOPTIONS environment variable sets *all* options to the
linker, that is why you have to set the other stuff in the variable
too.

Disclaimer: This has not been tried with the Motif libraries, but it ought
to work.

Thanks to Erik Ernst <eernst@daimi.aau.dk> and Stephen J Bevan
<bevan@cs.man.ac.uk> for their investigations on this subject.
----------------------------------------------------------------------------

Lx03) Why does GuiEnv demos segmentation fail? [error in r4.0 & r4.0.1]

With some Linux distributions, the demos in $BETALIB/guienv/v1.4/demos (aka BETALIB/demo/guienv) all fail with a segmentation fault upon startup, whereas, e.g. the MotifEnv demos all work correct. The reason for this seems to be a buggy gcc used for producing some of the files in the BETA releases r4.0 and r4.0.1. This was done at the time that the Linux community was switching towards ELF binaries, and possibly this is the reason, that gcc produced wrong files. The problem has not been observed for release 4.0.2. A workaround is to do the following (as the owner of BETALIB): cd$BETALIB/guienv/v1.4/private/X11
chmod -R u+w .
rm linux/guienv_unix.o
rm linux/Canvas.o
rm linux/Button.o
rm linux/IconButton.o
rm linux/ToggleButton.o
beta guienv_unixbody
chmod -R a-w .

----------------------------------------------------------------------------

SECTION IX: BETA on Silicon Graphics

----------------------------------------------------------------------------

SG01) What are the system requirements to run BETA on Silicon Graphics
workstations?

* RAM: 16 MB, 32Mb recommended.
* Disk: 150 MB disk space
The installation is approx. 100 MB + documentation approx. 13 MB.
* OS: IRIX 5.3 or 6.2 (32 bit)
* X window system (Rel. 11.3 or newer)
* Motif 1.2 or later (not required for textual BETA programs)

If you run IRIX 5.3, you must have installed patch 410 from SGI in order to
fix the linker to generate pure ELF binaries. If you have not applied this
patch, the linker will fail like this:

Unknown flag: -woff

----------------------------------------------------------------------------

SG02) Gnu C Compiler gcc not supported

You cannot link applications, that specify external OBJFILEs compiled with
gcc. You must use cc for external object files. If you get an error like:

ld: FATAL 2: Internal: at ../commonlib/ld3264/relocate.c \
merge_ext returns nil during relocation

this may be caused by an attempt to link a gcc-produced file into your
application.

If you use make files invoked via the MAKE property in a BETA fragment, you
should use \$(CC) instead of a hardcoded C compiler name. The BETA compiler
sets CC to a proper default value on alle UNIX platforms.

If you do not know which external object file caused the error to happen,
you may find out like this:

1. Compile the program with beta -p. This will preserve the job-file,
containing the link-directive(s) for the program.
2. Open the preserved jobfile in a text-editor. The job-file is located in
the sgi subdirectory, and has the same name as the application, but
with ..job appended.
3. Add -v as argument to the last invocation of /bin/ld in the job file.
4. Save and execute the job-file.

When the job-file starts to link the final application, it will now print
out the name of each file in the last link-directive as they are processed.
This includes all external object files (specified by OBJFILE in the BETA
code), and you should thus be able to see what file causes the linker to
fail: It is likely to be the last one printed out before the linker crashes.
----------------------------------------------------------------------------

SG03) Remember to set LD_LIBRARY_PATH

After linking shared objects, the LD_LIBRARY_PATH should be set so that it
includes the directory, where the shared object files reside. The compiler
will tell which directory this is. If you get an error like:

793:./foo: rld: Fatal Error: cannot map soname 'foo1..gso' \
using any of the filenames /usr/lib/foo1..gso:/lib/foo1..gso:\
/lib/cmplrs/cc/foo1..gso:/usr/lib/cmplrs/cc/foo1..gso: \
-- either the file does not exist or the file is not mappable \
(with reason indicated in previous msg)

when running you application (here foo), this may be caused by
LD_LIBRARY_PATH not being set correctly.
----------------------------------------------------------------------------

SG04) Using BETA on IRIX 6 machines

On the newest Silicon Graphics OS, IRIX 6, three binary object file formats
are supported by the OS - old 32 bit format, new 32 bit format and new 64
bit format. The BETA compiler in release 4.1, however, only supports the old
32 bit format - the format also used for IRIX 5.

There are 3 implications of this:

The compiler automatically fixes the link directive on IRIX 6 machines
2. Using BUILD:
If you are using BUILD properties, and may thus need to invoke the C
compiler, please note that you have to specify the CC environment
variable before compiling your BETA program:

setenv CC 'cc -32'

If you are compiling with beta -d ..., you may also set CC like this:

setenv CC 'cc -O2 -32'

In a future version of the compiler, this will be done automatically.
3. LD_LIBRARY_PATH specification:
If your program is linked using shared object files (the compiler will
tell you so), as always, you should set LD_LIBRARY_PATH to point to the
directory, where the shared object files are places (usually directory
sgi). Since the compiler uses old 32 bit object files, it is enough to
set LD_LIBRARY_PATH. That is, do not set any of the new
LD_LIBRARYN32_PATH or LD_LIBRARY64_PATH variables. If you need to set
any of these, then all 3 variables should be set, and the sgi directory
should be included in all three.

----------------------------------------------------------------------------

SG05) Limitations, bugs and inconveniences

SG05.1) Limitations

The following limitations are currently specific to the SGI implementation:

1. Lazy Fetch in persistence is not implemented. This means that the
following demos fail:

demo/persistentstore/crossloc

2. Check for suspend involving callbacks is not done. If you do a suspend
in a callback situation the program is likely to crash.
3. It is uncertain if valhalla (v2.2) will work for executables that
contain shared object files.
4. Integer division by zero will yield unpredictable results (should be
caught as an exception as on other platforms). [corrected in r4.1]
5. The compiler may sometimes crash during code generation. Normally you
can just restart the compilation in this case. [corrected in r4.1]
6. There is sometimes a problem with real expressions involving external
calls. This is e.g. the case in the demo

demo/r4.0/tutorial/SquareRoot

which currently does not work on sgi. [corrected in r4.1]
7. The following runtime errors may not always result in correct dumps:

Repetition subrange out of range
Text parameter to C routine too big (max. 1000 bytes)

8. Do not specify an output file in the sgi-directory to the compiler.
I.e. do not do this:

beta -o sgi/foo foo.bet

beta -o foo foo.bet
mv foo sgi/

The first method may fail when linking shared. The problem is, that the
shared object files are renamed to the file sgi in the sgi directory,
and thus the program will fail to execute. [corrected in r4.1]
9. Do not use the current notation in fragment paths. E.g. use
You may get linker errors, if you use the current notation.

SG05.2) doGCand scanobjdoes not work

The pattern doGC in betaenv does not work on SGI. This is used in
implementation of

sysutils/v1.6/scanobjects

used in the demo

demo/sysutils/objinterface/scanobj

which consequently does not work.

SG05.3) About ld: WARNING 56: Invalid warning number (133)

When the beta compiler is used on IRIX 5.3 it may give the warning ld:
WARNING 56: Invalid warning number (133) at link time. This warning is
caused by the compiler trying to turn of an IRIX 6.2 warning (number 133),
which does not exist on IRIX 5.3. The warning can be safely ignored.

SG05.4) About ld: WARNING 85: definition of vendorShellWidgetClass...

When compiling awenv programs on SGI, the linker will give the following
warnings:

ld: WARNING 85: definition of vendorShellWidgetClass in /usr/lib/libXaw.so
preempts that definition in /usr/lib/libXt.so.
ld: WARNING 85: definition of vendorShellClassRec in /usr/lib/libXaw.so
preempts that definition in /usr/lib/libXt.so.

These warnings are caused by (intentional) overriding of the X Toolkit
VendorShell in the SGI athena libraries. The warnings can be safely ignored.
----------------------------------------------------------------------------

SG06) Disclaimer (Slow startup of tools)

Startup time for SGItools(compiler, frigg, sif, psbrowser, ...) are quite
significant. This is due to the dynamic linker, and may be fixed in a future
version.
----------------------------------------------------------------------------

SECTION X: BETA on Sun workstations

----------------------------------------------------------------------------

Sun01) What are the system requirements to run BETA on Sun workstations?

* RAM: 16 MB, 32Mb recommended.
* Disk: 150 MB disk space
The installation is approx. 100 MB + documentation approx. 13 MB.
* Sun SPARC/Solaris:
o OS: Solaris 2.x
* X window system (Rel. 11.3 or newer)
* Motif 1.2 or later (not required for textual BETA programs)

----------------------------------------------------------------------------
Jorgen Lindskov Knudsen / Aarhus University / jlk@daimi.aau.dk
--
* Jorgen Lindskov Knudsen        | Phone:  +45 8942 3233 Fax: +45 8942 3255 *
* Dept. of Computer Science      | GSM:    +45 2099 7357                    *
* Univ. of Aarhus, Building 540  | E-mail: jlknudsen@daimi.aau.dk           *
* Ny Munkegade, DK-8000 Aarhus C | WWW:    http://www.daimi.aau.dk/~jlk     *