NetNews Usenet Archive 1992 #30

home *** CD-ROM | disk | FTP | other *** search

/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / fj / comp / oops / 345 < prev next >

Wrap

Internet Message Format | 1992-12-14 | 60.5 KB

Path: sparky!uunet!stanford.edu!sun-barr!sh.wide!wnoc-tyo-news!sranha!sran265!hironobu From: hironobu@sra.co.jp (Hironobu Suzuki) Newsgroups: fj.comp.oops Subject: What is true OOPS? Answer is "BETA". Message-ID: <HIRONOBU.92Dec14213001@sran265.sra.co.jp> Date: 14 Dec 92 12:30:01 GMT Sender: news@sran265.sra.co.jp Distribution: fj Organization: Software Research Associates, Inc., Japan Lines: 1340 BETA$B$H$$$&(B$B$N$O(BSimula$B$+$iL.!9$HN.$l$k%*%V%8%'%/%H;X8~$NNr;K$r0z$-$D$$$F(B $B$$$kKL2$$G:n$i$l$?%*%V%8%'%/%H;X8~8@8l$G(B$B$9!#(B $B$H!"$$$C$F$b<B:]$K;H$C$?$3$H$,$J$$(B($B$=$NJU$,Ha$7$$$s$@$J(B)$B%7%9%F%`$@$1$I!"(B $B$3$$$D$NOC$rJ9$$$F$$$k(B$B$H!V$3$l$>??$N%*%V%8%'%/%H;X8~8@8l$+$J(B?$B!W$H;W$o(B $B$;$F$/$l$^$9!#(B $BKL2$$N;:3X6(F1$N%W%m%8%'%/%H(BMjolner($B%_(B$B%h%k%J!<(B)$B$N@.2LJ*$G$9!#J#?t$N4k(B $B6H$HBg3X$G:n$C$F$$$kAH?%$G$9!#(BMjolner$B$H$$$&$N$O!"KL2$$NMr$N?@MM$N;}$D(B $B6bDH$N$3$H$G!"$3$l$r0l?6$j$9$k$H!"6/NO$J%$%+%E%A$,Mn$A$k$=$&$G$9!#$G!"(B $B%=%U%H%&%(%"9)3X$H$$$&$N$b$NBP(B$B$7$F%*%V%8%'%/%H;X8~5;=Q$r?)$i$o$=$&$H$$(B $B$&$N$@$=$&$G$9!#(B Mjolner$B$NK\It$K%a!<%k$r=P$7$FJV;v$,$-$?$N$G(B$B!"$=$NJV;v$N(BBETA$B$N:G?7$N%7(B $B%9%F%`$K4X$7$F$N>pJs$NItJ,$b:\$;$^$9!#$A$g$C$HBg$-$$$G$9!#%W%i%$%9%j%9(B $B%H$b(B$B?=$79~$_@h$b$<$s$VF~$C$F$$$k$N$G!"Bg3X$d8&5f=j$G6=L#$N$"$kJ}$O$3$N(B $B>pJs$G9XF~$9$k$3$H$b$3$l$G$G$-$k$G(B$B$7$g$&!#(B BETA$B$OF|K\=iEP>l$+$J(B? $B%3%s%T%e!<%?$N$3$H$H8@$($P!"KM$b$=$&$@$1$I!"%"(B $B%a%j%+$7$+$_$F$$$J$$!#(B$B%h!<%m%C%Q$K$b?'!9$$$$$b$N$,$"$k$s$G$9!#;DG0$J$,(B $B$iF|K\$K$=$N>pJs$,KX$IN.$l$F$-$^$;$s$7!"N.$l$F$b$"$s(B$B$^$j6=L#$r<($7$^$;(B $B$s$1$I!#(B $B$R$m$N$V(B ----------------------------( cut here)------------------------------- Mjolner Informatics is happy to announce the commercial release of: The Mjolner BETA System A software development environment supporting object-oriented programming in the BETA programming language BETA is a modern object-oriented language from the Scandinavian School of object-orientation with powerful abstraction mechanisms for identification of objects, classification and composition. It has strong typing, whole/part objects, reference attributes, general block structure, coroutines and concurrency. The BETA implementation has native code generation, garbage collection, separate compilation, configuration control, interface to C and assembly, source-level debugger, and persistent objects. There is a large library of class patterns and application frameworks. - Class patterns for text, file, set, multiset, set with subsets, hashtable, list, stack, queue, priority queue, deque, etc. - Powerful and easy to use application frameworks on top of the X Window System, Athena Widgets, and Motif. - Powerful and easy to use application frameworks on top of the Macintosh Toolbox. - Powerful metaprogramming system for manipulating programs as data. - Interface to operating system and external languages. - Powerful graphical system based on the Stencil & Paint imaging model. A pre-release is available of the Hyper Structure Editor for programs and text documents supporting integrated syntax directed and textual editing, incremental parsing, abstract presentation and browsing, integration of documentation and comments, hypertext facilities, and adaptive pretty printing. A demo version is available of the Mjolner BETA CASE Tool, with support for design diagrams and simultaneous editing of design diagrams and program text. Eliminates CASE gap by using one single abstract language-BETA for design as well as for implementation. The system has taken its name from the Nordic mythology where Mjolner is the name of the hammer of the god Thor. According to the mythology, this hammer is the perfect tool that cannot fail, grows with the task, and always comes back in the hand of Thor. The BETA Language BETA is developed within the Scandinavian School of object- orientation, where the first object-oriented language, Simula, was developed. BETA is a modern language in the Simula tradition. The resulting language is smaller than Simula in spite of being considerably more expressive. BETA is a strongly typed language like Simula, Eiffel and C++, with most type checking being carried out at compile-time. It is well know that it is not possible to obtain all type checking at compile time without sacrificing the expressiveness of the language. BETA has optimum balance between compile-time type checking and run-time type checking. Powerful Abstraction Mechanisms BETA has powerful abstraction mechanisms that provides excellent support for design and implementation, including data definition for persistent data. The powerful abstraction mechanisms greatly enhances reusability of designs and implementations. The abstraction mechanisms include: class, procedure, function, coroutine, process, exception, and many more, all unified to the ultimate abstraction mechanism: the pattern. In addition to the pattern, BETA has subpattern, virtual pattern and pattern variable. This unification of abstraction mechanisms gives a uniform treatment of abstraction mechanisms and a number of new abstraction mechanisms. Most object-oriented languages have classes, subclasses and virtual procedures and some have procedure variables. Since a pattern is a generalization of abstraction mechanisms like class, procedure, function, etc., the notions of subpattern, virtual pattern and pattern variable also apply to these abstraction mechanisms. The following table shows some of the possible combinations supported by BETA: class proce- func- co- process excep- dure tion routine tion pattern + + + + + + subpattern + + + + + + virtual pat. + + + + + + pattern var. + + + + + + Pattern: The pattern is the ultimate abstraction mechanism that generalizes class, procedure, function, coroutine, process, exception, etc. Subpattern: The subpattern covers subclasses as in most other languages. In addition, procedures may be organized in a subprocedure hierarchy in the same way as classes may be organized in a subclass hierarchy. Since patterns may also be used to describe functions, coroutines, concurrent processes, and exceptions, these may also be organized in a pattern hierarchy. Virtual pattern: The notion of virtual pattern covers virtual procedures like in Simula, Eiffel and C++. In addition, virtual patterns cover virtual classes, virtual coroutines, virtual concurrent processes, and virtual exceptions. Virtual classes provide a more general alternative to generic classes as in Eiffel or templates as in C++. Pattern variable: BETA includes the notion of pattern variable. This implies that patterns are first class values, that may be passed around as parameters to other patterns. By using pattern variables instead of virtual patterns, it is possible dynamically to change the behaviour of an object after its generation. Pattern variables cover procedure variables (i.e. a variable that may be assigned different procedures). Since pattern may be used as classes, it is also possible to have variables that may be assigned different classes, etc. Coroutines and Concurrent Processes 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 be executed concurrent (non pre-emptive scheduling in current version). The basic mechanism for synchronization is semaphores, but high-level abstractions for synchronization and communication, hiding all details about semaphores, are easy to implement, and the standard library includes monitors and Ada-like rendezvous. The user may easily define new concurrency abstractions including schedulers for processes. Support for subfunctions of abstraction BETA supports the three main subfunctions of abstraction: It is possible to describe objects that are not Identification generated as instances of a class pattern, so- of Objects called "class-less objects". This is in the many cases useful when there is only one object of a kind. In most object-oriented languages, it is necessary to define superfluous classes for such objects. In analysis and design, it is absolutely necessary to be able to describe singular objects without having to define them as instances of classes. Classification is supported by patterns, Classification subpatterns and virtual patterns that makes it possible to describe a classification hierarchy of objects and patterns (i.e. objects, classes, procedures, functions, coroutines, processes, exceptions, etc.). Objects and patterns may be defined as a Composition composition of other objects and patterns. The (Aggregation) support for composition includes: An attribute of an object may be a part object. Whole/part This makes it possible to describe objects in composition terms of their physical parts. An attribute of an object may be a reference to Reference another object. Reference composition forms the composition basis for modeling arbitrary relations between objects. In the form of block-structure: An attribute of an Localization object may be a (nested) pattern. The block- structure mechanism makes it possible to create arbitrary nested patterns. This makes it possible for objects to have local patterns used as classes, procedures, etc. Local patterns greatly enhances the modeling capabilities of an object- oriented language. Inheritance In BETA, inheritance is not only restricted to inheritance from superpatterns. It is also possible to inherit from a part object. Virtual patterns in the part object may be redefined to influence the enclosing object. Multiple inheritance is supported through inheritance from multiple part objects. This gives a much cleaner structure than inheritance from multiple superpatterns. The Implementation of BETA The Mjolner BETA System includes an implementation of the BETA programming language. The implementation has the following characteristics: - Native code generation The compiler generates assembly code. - Garbage collection Automatic storage management and garbage collection is used. The techniques used for garbage collection are generation-based scavenging and mark-sweep. - Separate compilation Programs may be divided into smaller fragments (modules) for separate compilation. The compiler makes an automatic dependency analysis on the fragments structure. When a fragments has been changed, the system keeps track of the dependent fragments that must be recompiled. - Interface to C and assembly language There is a general interface to C and assembly language. This includes call of C procedures, call-back and parameter transfer of simple types, text and C structures. For Macintosh, there is also a Pascal interface. - Source-level debugger A source-level debugger for the BETA language is available on the Unix platform. Contains facilities for specifying break- points, single stepping, inspection of object states, inspecting the run-time organization, etc. The debugger uses a graphical interface running under the X Window System. - Persistent objects 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 typesafe. An object-oriented database for BETA objects is currently under development. - Distributed objects Support for distribution of objects to support a client-server model is being developed. - Platforms The Mjolner BETA System is available on the following platforms: Macintosh, with at least 5 MB RAM, at least a 68020 CPU, and with MPW Sun-3, Sun SPARC, 8 MB, SunOS 4.0 HP 9000/300 series, HP9000/400 series, HP/UX 7 and HP/UX 8. HP9000/700 (to appear) Apollo 3000 series, with at least Domain OS 10.1 Mjolner Informatics ApS offers to port the MBS to other platforms. Ask for more information. - Implementation Language The entire Mjolner BETA System is written in BETA, except for a few run-time routines. The Mjolner BETA 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: Modularization Programs can be split into modules of logically related elements, called fragments. A fragment is not restricted to a specific BETA element such as a pattern. A fragment may e.g. contain one or more patterns, a set of attributes of a pattern, or the imperative bodies of one or more procedure patterns. Separation of A fragment can be split into interface interface and fragments and implementation fragments. It implementation is thus possible to hide the implementation details of a fragment from the client fragments using the fragment. Alternative It is possible to have alternative implementations and implementations of a fragment. Such variant control alternative fragments may be machine dependent and used for organizing different variants of the same fragment. Configuration control The system automatically combines the necessary fragments needed for a complete program. This includes selection of machine dependent fragments. The system handles organization of code for different machines. Units for separate A fragment may be separately compiled. The compilation compiler makes an automatic dependency analysis on the fragment structure. When fragments have been changed, the system keeps track of dependent fragments that must be recompiled. Grammar based The fragment system is grammar based in the sense that a fragment is a legal sequence of terminal and nonterminal symbols of the grammar. The fragment system may thus be used to implement a fragment structure for any language, based on its context-free syntax. Metaprogramming The fragment system is part of the metaprogramming system Yggdrasil, and enables the management and manipulation of coherent BETA programs located in different files. Mj|lner BETA System The Basic Libraries The Container Patterns The standard container datastructures are organized in the following inheritance hierarchy of patterns: container _________________|_______________________ | | | | collection arrayContainer list sequentialContainer ______|_______ ___________|_______________ | | | | | | multiset hashTable stack queue deque prioQueue | set __|_____________________ | | 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. MultiSet is an unstructured collection of element references, where duplicates are allowed. Set is like multiSet, except that duplicated are not allowed. ClassificationSet (and the accompanying classificationSubset) is used for dynamic classification of objects. HashTable implements a standard hash table datastructure. ArrayContainer is an abstraction of an element repetition, augmented with sorting operations Stack implements a stack datastructure. Queue implements a queue datastructure. Deque implements a double-ended queue datastructure. PrioQueue implements a priority queue datastructure. List implements a list data structure. Lists may be recursive (i.e. lists may have sublists). The Basic Patterns The basic patterns are the object-oriented variants of the standard simple datatypes, such as char, boolean, integer and real. These patterns make it possible to treat e.g. integers as ordinary objects. The basic patterns also includes the Object patterns, which is the implicit superpattern for all patterns that have no explicit superpattern. The Streams Patterns A Stream is a generalization of internal and external text objects. An internal text object (Text) is a sequence (repetition) of chars. An external text object (File) corresponds to a traditional text file. Stream, Text and File are organized in the following hierarchy: Stream: (# ... #); Text: Stream(# ... #); File: Stream(# ... #); UnixFile: File(# ... #); MacFile: File(# ... #); As part of the interface to the operating system, the basic libraries include patterns for accessing the directory structures of hierarchical file systems: Directory: (# ... #); UnixDirectory: Directory(# ... #); MacDirectory: Directory(# ... #); The Process Patterns The Process interface facilitates execution of subprocesses, communication between several independent processes, client/server architectures, and it is even possible to establish communication between Unix and Macintosh processes. The Concurrency Patterns The basic libraries defines various patterns for dealing with concurrency, synchronization and communication. These patterns are: system, semaphore, fork, monitor, port, restrictedPort, objectPort, qualifiedPort, conc, and alt. The External Language Interface Patterns To enable interfacing into external languages (such as C), the basic libraries defines the external, cStruct, and externalRecord patterns. Yggdrasil The Mjolner BETA Metaprogramming System A metaprogram is a program that manipulate other programs. Yggdrasil is a metaprogramming system, that supports creation of metaprograms. Yggdrasil is grammar based: a metaprogramming environment may be generated from the grammar of any language The metaprograms manipulate programs through a common represen tation called abstract syntax trees (ASTs) An AST is modelled as an instance of a pattern. There is a pattern corresponding to each syntactic category (non-terminal) of the grammar. The grammar hierarchy is modelled by a corresponding pattern hierarchy, derived automatically from the grammar. Grammar Based Interface The grammar for a specific language result in a grammar based interface-a metaprogramming environment with a set of patterns for the language. A metaprogram using the grammar based interface will thus be language specific. Examples of tools that benefit from using the grammar based interface are: semantic checkers, program analyzers, interpreters, browsers, and graphical presentation tools. Three Levels of Support The AST may be manipulated at different levels of specialization: - Tree level: Here the AST is viewed as a tree. Examples of tools accessing the AST using the tree level are table-driven parsers and syntax-directed editors - Context-free level: This is the grammars based interface generated automatically from the grammar. Graphical presentation tools and browsers and examples of tools using the context-free level. - Semantic level: At this level semantic attributes may be added to the AST. The compiler is an example of a tool using the semantic level to access the AST. Users may develop their own metaprogramming tools. Yggdrasil supports generation of metaprogramming environments from a grammar. Users can then use this environment to develop their own metaprogramming tools-tools that manipulate other programs. The Fragment System The fragment system is a part of Yggdrasil, and enables the management and manipulation of coherent ASTs located in different files. The functionality of the fragment system allows splitting of an AST into a number of sub-ASTs (sub-trees) by allowing some inferior nodes in the original AST to be replaced by special nodes. The AST, originally positioned at the position of that node, is called a fragment and may be located in a totally different file. "Yggdrasil is the tree of the world. The ash tree of which the crown covers the whole world. The tree gets power from the gods, from the evil giants and from the kingdom of the death. Everything in the world happens under the mighty crown of Yggdrasil." Valhalla The Mjolner BETA Debugger The Mjolner BETA Debugger is a symbolic source level debugger with an easy-to-use graphical user interface. Using the Mjolner BETA Debugger you may - Trace the execution of a BETA program by setting breakpoints and stepping at the level of single BETA sourcelines, stepping over procedure-calls and even singlestep at the level of machine code instructions. - Simultaneously examine the state of any number of objects. - Examine the execution stack and view code and objects on the stack. - Examine the program heaps and view objects on the heaps. - Relative to any object find and display the object that is the value of an expression. - Simultaneously view any number of windows containing sourcecode. - Execute the program until a runtime error occurs and then examine the program state. The Mjolner BETA Debugger is currently available on the UNIX systems supported by the Mjolner BETA System. It runs under the X Window System. "Valhalla is Odins hall whereto all the dead warriors come, when they have fallen as heros in battle. Odin is the highest of all gods in Asgaard." XtEnv Mjolner BETA Interface to X Toolkit Widgets The Mjolner BETA object oriented interface to the X Toolkit Intrinsics (Xt) is called XtEnv. This pattern contains the basic patterns common for many user-interface toolkits build upon the X Window System, but it does not contain any higher level user interface elements. It is typically used together with a widget set containing such user interface elements build on top of it. Examples of such widget sets are the Athena Widgets, OPEN LOOK, and Motif. The Mjolner BETA system currently includes object- oriented interfaces to the Athena Widgets (AwEnv) and to Motif (MwEnv). XtEnv XtEnv includes patterns corresponding to the widgets of the X Toolkit Intrinsics, i.e., Core, Composite, Constraint, and the various Shell subclasses. Also it includes interface to Xt resources, displays, translations, actions, timers and work procedures. An application is created by specializing the XtEnv pattern, creating various widgets and initializating them. When the XtEnv pattern starts executing, it does some initialization itself. Then it calls the BETA construct INNER, thus allowing the specialization to initialize itself. When the control returns to XtEnv, a global event handler is started, which distributes events to the various widgets. In Xt, the widgets form a hierarchy, used for distributing events and when specifying resources. The block-structure of the BETA program is used to determine the hierarchy automatically. This is a major enhancement compared to the C interface to Xt. AwEnv AwEnv is a specialization of XtEnv, which adds the patterns corresponding to the Athena Widgets. This includes the simple widgets Label, Scrollbar, Grip, Stripchart, Command, Toggle and List. It also includes the text editor called AsciiText, menus and submenus. Finally it includes the layout widgets called Form, Dialog, and Box. MwEnv MwEnv is a specialization of XtEnv, which adds the patterns corresponding to the Motif widgets and gadgets. This includes the primitive widgets Label, Cascadebutton, Drawnbutton, Pushbutton, Togglebutton, Arrowbutton, List, Scrollbar, Separator, and Text; the Motif specific Shells like DialogShell and MenuShell; the Manager widgets BulletinBoard, RowColumn, ScrolledWindow, DrawingArea, VPaned, Frame, Scale, SelectionBox, MessageBox, Form, FileSelectionBox, and CommandBox. Patterns also exist for the corresponding gadgets (windowless widgets), and finally interface to the Motif specific resources, like Motif Strings, is included. Example This is a realistic example of using AwEnv. It is a small text editor with full support for loading, editing, and saving files. The screen snapshot following the code shows how this application appears on the screen after another small AwEnv program has been loaded into it for editing. ORIGIN '~beta/Xt/current/awenv' (* Fragment to fill slots in is AwEnv *) [[ (* Include interface to disk files *) -- INCLUDE '~beta/basiclib/current/file' -- PROGRAM: Descriptor -- (* Specify PROGRAM slot *) AwEnv (# Main: @Form (* Main window is a Form widget *) (# dirty: @boolean; (* Have there been changes since last save? *) Bell: (# do ascii.bel -> put #); (* Pattern to invoke the bell of the machine *) DoLoad: (* Load the file named in Filename into Buffer *) (# theFile: @File; do (if dirty // true then Bell else (* Clear Buffer *) Buffer.asciiString-> Buffer.type; '' -> Buffer.string; (* Load new file *) filename.string -> theFile.name; (if theFile.entry.exists // false then theFile.touch if); Buffer.asciiFile -> Buffer.type; theFile.name -> Buffer.string; if)#); Filename: @AsciiText (* AsciiText widget used to specify file name *) (# init::< (# do edit -> editType; true -> resize; true -> resizable; 'Untitled' -> string; (* Initial file name is 'Untitled' *) #)#); ShapedCommand: Command (* Pattern for an oval shaped command widget *) (# init::< (# do oval -> shapeStyle; INNER #)#); Quit: @ShapedCommand (* Quit button: quit if changes are saved *) (# callback::< (# do (if dirty//true then Bell else Stop if)#) #); Load: @ShapedCommand (* Load button: invoke instance of DoLoad *) (# callback::< (# do DoLoad #)#); Save: @ShapedCommand (* Save button: save and clear dirty-flag *) (# callback::< (# do Buffer.save; false -> dirty #)#); Buffer: @AsciiText (* AsciiText widget holding text to be edited *) (# callback::< (# do true -> dirty #); init::< (# do scrollAlways -> scrollVertical; scrollWhenNeeded -> scrollHorizontal; edit -> editType; 200 -> width; true -> resize; ChainTop -> top; #)#); init::< (# do (* Initialize the widgets and specify geometric relations among them *) Quit.init; Filename.init; Quit -> filename.fromVert; Load.init; Quit -> Load.fromVert; Filename -> Load.fromHoriz; Save.init; Quit -> Save.fromVert; Load -> Save.fromHoriz; Buffer.init; Load -> Buffer.fromVert; #)#); do (* Initialize the main window *) Main.init; #) --]] MacEnv An object-oriented interface to the Macintosh Toolbox. MacEnv is a family of libraries abstracting the Macintosh Toolbox into an object-oriented framework. Every object in the Macintosh user interface, like windows and menus, has a corresponding BETA pattern definition in MacEnv. In order to create, say, a new window, you just create an instance of the Window pattern and tell it to display itself. All the other Macintosh user interface objects can be created and displayed in the same way. User defined objects like dialog boxes, are easily created by specializing the Dialog pattern, and using the various Control patterns defined in MacEnv. MacEnv includes a series of predefined patterns for making text editors, scrolling windows with pictures, object-oriented graphics with QuickDraw, easy interface to the Macintosh resources, files, clipboard, sound, and QuickTime. The object-oriented abstractions in MacEnv is more general, flexible, and easier to use, than e.g. MacApp of Apple Computer, Inc., due to the strengths and powerfulness of the BETA programming language. Highlights of the object-oriented abstractions in MacEnv: User interface All interface objects (menus, windows, graphical objects objects) are subpatterns of the InterfaceObject pattern. The InterfaceObject defines two common properties of all interface objects: event handling and access to Macintosh resources. Event handling One of the strengths of MacEnv is the ease with which the event handling is conducted. MacEnv takes care of all the details of the Macintosh event dispatching and handling. MacEnv converts all Macintosh event occurrences into invocation of special virtual patterns (event patterns) within the appropriate user interface object. The application programmer only has to further bind these event patterns of the individual user interface objects to specify the actions to be taken in response to user interaction. Windows Macintosh windows are easily created and manipulated using the BETA pattern Window. The Window includes definitions of all standard actions, such as dragging, resizing, and scrolling (using the Scroller pattern). A window can have subwindows called canvases. A Canvas is a subwindow inside a window, defining its own coordinate system and event handler. Floating windows can also easily be created using MacEnv. Menus The Menu pattern interfaces to the Macintosh menu. Menus defined using resources can be easily created. Actions are bound to the items by virtual procedures. The standard menus: , File, and Edit are predefined in MacEnv, and will always appear in a MacEnv application. Object-Oriented MacEnv defines an object-oriented abstraction on QuickDraw top of the Macintosh QuickDraw graphics library. For each graphical entity (rectangle, region, line, text, etc.) a corresponding BETA user interface pattern is defined. Direct user interaction with these graphical entities, including interactive creation is fully defined in the corresponding BETA pattern. The following example shows a complete MacEnv application. The example program defines a window, DrawWindow, with definition of a graphical object OvalClass, and with the EventHandler of the window further bound. Finally, the standard item New in the File menu is further bound to create the DrawWindow. In the example, the ovals can be moved by direct manipulation with the mouse, and new ovals are created by direct rubberbanding in the window background. ORIGIN '~beta/macenv/v3.1/basicmacenv' (* use the basic MacEnv environment *) [[ (* include the figureitem library *) -- Include '~beta/macenv/v3.1/figureitem' -- Program: Descriptor -- Macenv (* execute one instance of pattern MacEnv *) (# (* specialized with: *) DrawWindow: Window (* a window *) (# HasClose::< TrueObject; (* the window has closebox *) (* Action to be bound in Close menu item in File menu *) DoClose: @theFileMenu.Action (# hit::< (# do Close #)#); OvalClass: Oval (# eventHandler::< (* called when the mouse is pressed inside the Oval *) (# MouseDown::< (# do DragOutline #)#) #); EventHandler::< (# MouseDown::< (* called when the mouse is pressed inside the window *) (# theOval: ^OvalClass; do (* create a dynamic instance of the OvalClass *) &OvalClass[] -> theOval[]; (* open and attach the oval to the window so it can * receive events*) theOval.open; theOval[] -> Attach; (EventInfo.localPosition,EventInfo.localPosition) -> theOval.Frame; (2,3) -> theOval.pen.size; (* set border width *) (*set fill to a gray pattern *) patterns.gray[] -> theOval.fill.FillPattern; Colors.Red -> theOval.fill.ForeGroundColor; (* display rubber feedback until the mouse is released *) theOval.dragResize; #); Activate::< (# (* called when the window (de)activate: * binds close action to Close menu *) do DoClose[] -> theFileMenu.CloseItem.Attach #); Deactivate::< (# do theFileMenu.CloseItem.detach #); #); Open::< (# do 'Draw' -> Title; (300,200) -> Size; #); #); FileMenu::< (* a virtual further binding *) (# iNew::< (* called when New is selected in File Menu *) (# hit::< (* create, open, and display the window *) (# theWindow: ^DrawWindow; do &DrawWindow[] -> theWindow[]; theWindow.open; #); #)#); #) --]] Bifrost An interactive object-oriented graphics system Bifrost is based on the Stencil & Paint imaging model. Bifrost models computer graphics images by abstracting the geometric and color properties of graphical objects. The important new concept introduced in Bifrost is that there is one basic drawing primitive, the graphical object. The graphical object unite interaction, graphics modelling and graphics context. Bifrost includes extensive support for various kinds of interaction: interactive creation, reshaping, translation, scaling, and rotation of graphical objects. The object-oriented approach makes extensibility and tailorability a simple task, and facilitates object-oriented drawing applications. One of the main goals of the development of Bifrost was to make the graphics system independent of underlying graphics and hardware systems. Important concepts of Bifrost Canvas Representation of the drawing surface, and is the connection between the display device and Bifrost. The canvas contains a picture, and all graphics shown in the canvas must be in the canvas picture. Picture Is a collection of graphical objects, and realizes the concept of graphics modelling. The graphical object is the smallest possible entity that can be drawn, and is complete in the sense, that it contains all necessary information about how the graphical object appears on the canvas, and is therefore independent of any other graphical objects in a picture. Graphical The graphical object concept is a composition of two Object concepts: shape and paint: Shape The shape describes the outline of the object, and the paint describes the color or raster to be pushed through the shape of the object, thus making it appear in the canvas. The shape of a graphical object is described by segments. A segment is either a straight line segment or a spline segment. Spline segments are used to describe curves. The shape is analogous to the stencil in the Stencil & Paint imaging model. Paint The paint of Bifrost represent what is pushed through the shape of the graphical object. The Paint can be simple solid colors using a predefined name of the color or relative to some color space, e.g. RGB, HSV, CMY. Tiles and rasters, e.g. scanned images, can also be used as paint, The basic imaging model of Bifrost is thus very simple: define a shape that represents the outline of the object you want to draw, select a paint as the color for the object, construct a graphical object with the shape and paint just defined, and draw the object in a canvas, i.e. insert the graphical object into the canvas picture. If the object must have several different colors the object must be split into more graphical objects and assembled in a picture. The picture is a graphical object itself, and can thus be drawn in a canvas. Bifrost is currently avaliable on Unix models only. The following complete program is a small example showing how to make a simple Shape consisting of Line- and SplineSegments, and then filling the Shape with a pink SolidColor: ORIGIN '../bifrost'; [[ --- INCLUDE '../ColorNames' --- PROGRAM: descriptor --- bifrost (# application::< (# (* define two object representing the back- and *) canvasbordercolor: @SolidColor; (* foreground color of the canvas *) canvasbackgroundcolor: @SolidColor; myCanvas: @Canvas (* create a singular Canvas object *) (# aGO: @GraphicalObject; aSolidColor: @SolidColor; myshape: @Shape (# do (100,100) -> open; (* start defining the shape *) (100,150) -> lineto; (* create a line segment *) (125,200) -> splineto; (* create a spline segment *) (200,170) -> splineto; (195,100) -> splineto; close; #); onOpen::< (* called when the canvas is initialized and * ready to show graphics *) (# do aSolidColor.init; (* initialize the solid color *) pink -> aSolidColor.name; aGO.init; (* set the shape in the graphical object *) myshape -> aGO.setShape; aSolidColor[]-> aGO.setpaint; (* draw the graphical object in the canvas *) aGO[] -> draw; aGO[] -> hilite; (* and hilite it *) #); onButtonPress::< (* when user presses a mouse button: stop program execution *) (# do (normal, '') -> stop #); #); do (* application *) myCanvas.init; 4 -> myCanvas.Borderwidth; lightblue -> canvasbackgroundcolor.name; canvasbackgroundcolor[] -> myCanvas.backgroundpaint; violet -> canvasbordercolor.name; canvasbordercolor[] -> myCanvas.borderpaint; (100,100) -> myCanvas.Position; (300,300) -> myCanvas.Size; myCanvas.open; (* show the canvas *) #); #) --- ]] "Bifrost is the luminous bridge, the rainbow, that leads from Midgaard to Asgaard. Midgaard is the place where the human beings live. Asgaard is the habitat of the gods in the middle of the world." Sif The Mjolner BETA Hyper Structure Editor 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. Also a program constructed by syntax-directed editing needs not be parsed, thereby saving time in the development phase. One characteristic of syntax-directed editing is choosing templates from a menu, containing only the legal choices at any time. 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. This mechanism is completely general since the user may decide the level of granularity. The three dots ... , called contractions, indicate details that are suppressed. By clicking on contractions the next level of detail is shown. 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. An example is the different presentation of Record and Person. Text editing and incremental parsing The programmer may freely alternate between syntax directed editing and textual editing. Any program part may be textually edited using keyboard, mouse and menus in the usual style known from the Macintosh or the X Window System, respectively. Any program part that has been textually edited is immediately parsed. Fragment manipulation and browsing The editor provides an interface to the fragment system. It is possible to browse in the fragment structure and to create and combine fragments. Grammar basis The editor is generic. It may be adapted to specific languages. An editor for a given language is generated from a context free grammar for that language. Grammars exist for a number of programming languages, including BETA, Simula, Modula-2, Pascal, Standard ML and Object-Oriented SDL. Grammars have also been made the query language SQL and for various document types in the style of SGML and ODA. 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. This facility together with abstract presentation has turned out to be one of the most useful features of the editor. Programmers are motivated for integrating code and documentation since it is easy to extract part of the program and the comments as functional specifications and other documentation. 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). Examples of such semantic links are putInt and putText that are used in Employee and defined in Stream. Another kind of links are links between program and documentation. Anchors, i.e. link end-points are indicated by means of the special symbol (^). Fragment manipulation and browsing The editor provides an interface to the fragment system. It is possible to browse in the fragment structure and to create and combine fragments. Grammar basis The editor is generic. It may be adapted to specific languages. An editor for a given language is generated from a context free grammar for that language. Grammars exist for a number of programming languages, including BETA, Simula, Modula-2, Pascal, Standard ML and Object-Oriented SDL. Grammars have also been made the query language SQL and for various document types in the style of SGML and ODA. Availability Sif is currently available as a pre-release only. "The wife of Thor is Sif with the golden hair." The Mjolner BETA CASE Tool The Mjolner BETA CASE Tool provides - graphical structure editing of design diagrams - textual structure editing of programs - automatic program generation from design diagrams - reverse engineering from programs to design diagrams - simultaneous editing of design diagrams and programs No CASE gap One single abstract language is used throughout analysis, design and implementation. Different concrete syntaxes are used to present the different models: - graphical syntax for design - textual syntax for programs. This gives a significant advantage compared to other object- oriented CASE tools that support object-oriented notations for analysis and design that are isolated from the language used for implementation. Isolated notations for analysis and design introduce a new CASE gap because there are still consistency problems between design and implementation The single language approach puts strong requirements on the language used. It must be executable and it must be powerful enough to model the application domain. BETA meets these requirements. Implementation - common representation for design diagrams and programs - graphical abstract presentations of the common representation in the graphical structure editor Freja - textual abstract and detailed presentations of the common representation in the textual structure editor Sif - the common representation is abstract syntax trees - experimental version exists on Unix workstations - Freja is implemented on top of Design/OA Example In the example a class library containing a record hierarchy is shown in each editor simultaneously. Freja shows the library at two levels of abstraction. Sif shows the corresponding example in textual and more detailed form, but abstract presentation is also used in the textual presentation to provide overview. The three dots (...) indicate that some details are suppressed by the editor. In both editors the definition of the variable Key has been selected. Whenever the user changes the current selection in either of the two editors the current selection in the other editor is updated accordingly. In the case that the corresponding construct is not visible the proper abstraction level is automatically chosen. Availability The Mjolner BETA Case Tools is available on Unix systems as an experimental version. The CASE Tool requires Design/OA. "Freja is 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." Mjolner BETA System ORDER FORM* Name:________________________________ Title:________________________ Organization:_______________________________________________________ Address:____________________________________________________________ Phone:_______________________________ Fax:__________________________ E-mail:______________________________ Signature:____________________ Please ship the following items: ____________________________________________________________________ |# Description | Quant. | Machine |Media | Price | | | | and OS | | | |_______________________________|________|_________|______|_________| |1 Unix Workstation models | | | | | |_______________________________|________|_________|______|_________| |2 Unix Server models | | | | | |_______________________________|________|_________|______|_________| |3 Manual set | | | | |_______________________________|________|________________|_________| |4 BETA book pre-print | | | | |_______________________________|________|________________|_________| |5 Delivery Cost | | | |_______________________________|_________________________|_________| | | Total: |_________| The purchase will be delivered through air-mail. Delivery through courier services is available on request (see item #6) Credit Card Payment: ==================== Please tick the appropriate card type, and fill in the form properly. Remember to sign the form ____________________________________________________________________ |MasterCard: | | Card Number: | |____________|__|___________________________________________________| |VISA: | | Expiration date: | |____________|__|___________________________________________________| |EuroCard: | | Total amount: US $ | |____________|__|___________________________________________________| |JCB: | | Date: Signature: | |____________|__|___________________________________________________| _______________________________ * Please note, that the ordfer form will only be processed if accompanied with a signed licence agreement. Please fill-in this order form with care to ensure correct processing of the request. Please use capital letters or typewriter and make sure that the information entered is complete and correct. Please send the order form to Mjolner Informatics, Science Park Aarhus, Gustav Wiedsvej 10, DK-8000 Aarhus C, Denmark, or fax to: +45 86 20 12 22. In case of questions or difficulties, please contact Kim Jensen Moller, Mjolner Informatics using phone: +45 86 20 20 00, fax: +45 86 20 12 22, or e-mail: support@mjolner.dk. Supported Unix models: Sun-3, Sun SPARC, HP 9000/300 series, HP 9000/400 series, and Apollo 3000 series. Supported Unix OS versions: SunOS 4, HP-UX 7 and 8, and DomainOS 10. Requires 8Mb RAM. Media is for Unix models either stream or DAT tape, and for Macintosh diskettes. _______________________________ Mjolner BETA System PRICE LIST All prices are in US $ ______________________________________________________________________ |Description | 1 CPU | 5 CPUs | 10 CPUs | 20 CPUs | |_______________________|_________|__________|__________|____________| |Unix workstation models| $ 2.890 | $ 7.700 | $ 11.550 | $ 17.325 | |_______________________|_________|__________|__________|____________| |Unix server models | $ 7.450 | $ 19.860 | | | |_______________________|_________|__________|__________|____________| incl. 1 incl. 2 incl. 3 incl. 4 man. set man. sets man. sets man. sets _____________________________________________ |Additional documentation | 1 set | 10 sets | |_________________________|________|_________| |Additional manual sets | $ 50 | $ 400 | |_________________________|________|_________| |BETA book preprint | $ 40 | $ 300 | |_________________________|________|_________| If ordered separately, add $ 10 for handling and shipment of the order. Educational prices: 25% of the above prices. ================== === Upgrade: 30% of the above prices. Hot-line support: $ 500 pr. month pr. CPU licence. Ask for details. The Mjolner BETA System includes the BETA compiler, the basic libraries, the graphics libraries, the user interface libraries, the operating system interface, the external language interface, and the metaprogramming system. The system also includes a source-level debugger (only on the Unix platforms). Finally, the system contains a demo version of the hyper structure editor for the BETA language. The purchase of the Mjolner BETA System includes access to e-mail support. This support will be open to all questions related to the purchased system (installation, use and error reports). Mjolner Informatics will respond to the questions on the e-mail support as quickly as possible. However, note that this e-mail support is not a hotline. Mjolner Informatics is offering consultancy services and training in connection with the Mjolner BETA System. Ask for details. Mj|lner BETA System Macintosh Order Form Name:________________________________ Title:________________________ Organization:_______________________________________________________ Address:____________________________________________________________ Phone:_______________________________ Fax:__________________________ E-mail:______________________________ Signature:____________________ Please ship the following items: ____________________________________________________________________ |# Description | Quant. | Machine | OS | Price | | | | | | | |_______________________________|________|_________|______|_________| |1 Macintosh models | | | | | |_______________________________|________|_________|______|_________| |2 Additional Manual set | | | | |_______________________________|________|________________|_________| |4 BETA book pre-print | | | | |_______________________________|________|________________|_________| |5 Delivery Cost | | | |_______________________________|_________________________|_________| | | Total: |_________| The purchase will be delivered through air-mail. Delivery through courier services is available on request. Credit Card Payment: ==================== Please tick the appropriate card type, and fill in the form properly. Remember to sign the form ____________________________________________________________________ |MasterCard: | | Card Number: | |____________|__|___________________________________________________| |VISA: | | Expiration date: | |____________|__|___________________________________________________| |EuroCard: | | Total amount: US $ | |____________|__|___________________________________________________| |JCB: | | Date: Signature: | |____________|__|___________________________________________________| _______________________________ Supported Macintosh models: at least 68020 CPU, OS versions: System 6 and 7. Requires MPW 3.2 and 5Mb RAM. Please fill-in the order form with care to ensure correct processing of the order. Please use capital letters or typewriter and make sure that the information entered is complete and correct. Please send the order form to Mj|lner Informatics, Science Park Aarhus, Gustav Wiedsvej 10, DK-8000 ]rhus C, Denmark, or fax to: +45 86 20 12 22. In case of questions or difficulties, please contact Kim Jensen M|ller, Mj|lner Informatics using phone: +45 86 20 20 00, fax: +45 86 20 12 22, or e-mail: support@mjolner.dk. * Price list on reverse side (all prices are in US $). Please note that delivery cost will be added. Mj|lner BETA System Macintosh System Price List All prices are in US $ ______________________________________________________________________ |Description | 1 CPU | 5 CPUs | 10 CPUs | 20 CPUs | |_______________________|_________|__________|__________|____________| |Basic Package | $ 295 | $ 775 | $ 1575 | $ 2950 | |_______________________|_________|__________|__________|____________| |Meta programming System| $ 200 | $ 675 | $ 1275 | $ 2050 | |_______________________|_________|__________|__________|____________| incl. 1 incl. 2 incl. 3 incl. 4 man. set man. sets man. sets man. sets _____________________________________________ |Additional documentation | 1 set | 10 sets | |_________________________|________|_________| |Additional manual sets | $ 50 | $ 400 | |_________________________|________|_________| |BETA book preprint | $ 40 | $ 300 | |_________________________|________|_________| Upgrade: 30% of the above prices. Hot-line support available. Ask for details. The Mj|lner BETA Basic Package includes the BETA compiler, the basic libraries, the container libraries, the persistent store, the user interface library MacEnv, the interface to the Macintosh Toolbox, and the external language interface. The purchase of the Mj|lner BETA System includes access to e-mail support. This support will be open to all questions related to the purchased system (installation, use and error reports). Mj|lner Informatics will respond to the questions on the e-mail support as quickly as possible. However, note that this e-mail support is not a hotline. Mj|lner Informatics is offering consultancy services and training in connection with the Mj|lner BETA System. Ask for details.