Component Pascal

Abstract: The second part of the two-part account of the enabling technologies behind a successful completion of the Troitsk-nu-mass experiment, summarizes an almost 20 years' experience of using Oberon/Component Pascal in complex applications ranging from the cutting-edge computer algebra (b-quark decays etc.) to experimental data processing (neutrino mass etc.) to exploratory algorithm design work (the optimal jet finder etc.) to systematic computer science education (the international project Informatika-21).

Abstract: Computer implementation of sophisticated algorithms for physics applications is greatly facilitated by the new generation of component-oriented SD technologies pioneered by Wirth's Oberon and embraced by the software industry (Sun's Java and Microsoft's C#). In a stark contrast with the deeply flawed C++, the Oberon technologies (specifically, the Component Pascal and the BlackBox development environment) offer an unparalleled SD platform for building scientific applications from sophisticated data processing to demanding symbolic calculations. Specific examples are discussed. This workshop is taking place against the backdrop of a theoretical crisis with calculations for the existing and future colliders; theorists are behind experimentalists precisionwise, and it is not clear when (and if) the gap will be significantly narrowed. The theory for LEP1 [1] was implemented within the framework of the calculational paradigm based on the use of Schoonschip and derivatives [2] for vector and spinor algebra; dilogarithms for (one loop) integrals [3]; and FORTRAN for numerical calculations; with the different pieces connected [4] by a tremendous amount of hand work. But already the one-loop calculations for LEP2 are far from being complete. What about 2 loop calculations in the Standard Model that are needed for theoretical numbers to match data precision-wise? The purpose of this workshop as explicitly set forth by

Abstract: Computer implementation of sophisticated algorithms for physics applications is greatly facilitated by the new generation of component-oriented SD technologies pioneered by Wirth's Oberon and embraced by the software industry (Sun's Java and Microsoft's C#). In a stark contrast with the deeply flawed C++, the Oberon technologies (specifically, the Component Pascal and the BlackBox development environment) offer an unparalleled SD platform for building scientific applications from sophisticated data processing to demanding symbolic calculations. Specific examples are discussed.

Abstract: ions and Discipline => Complexity Control => Reliability Reliability and Flexibility => Evolvability Fig. 1 Main Forces of Effective Design Evolvability is the second basic property of system design — to be ready for a long life in volatile world. Complexity control is the first condition for evolvability because unreliable system can't have long life. But not all reliable systems are evolvable. Squeeze structure is a cost of reliability. Therefore flexible areas should be established during design if we need some freedom for system evolution. We introduce reliable skeletons over a homogeneous set of elements (for example, strict typing over plain memory) and after than we'll be forced to introduce facilities for flexibility over the squeeze layer. Such contraries should not be perceived as disappointing. True system design demands wellbalanced thinking from an engineer. There are many well-known things in IT history (LISP, Forth and some of modern dynamic languages), that have beautiful abstractions and homogeneous structure. But abstractions without a discipline (that need to be implemented as some concrete facilities) don't achieve true complexity control and reliability. And flexibility without reliability don't achieve evolvablity. All languages used for large system design (Ada, Java, Component Pascal, C#, chronologically, and others) are balanced for all sides of described above. 2. Modular and Object-Oriented (OO) Facilities Modular and object-oriented facilities were introduced in porgramming languages independently one of another, but because of similar problem's vision. Actually, two these approaches may be considered in overlaped notions — let's try to do it. We'll tell about so called «true modules» based on D. Parnas conceptions and supported by special language constructions in modular languages (Mesa, Modula-2, Ada, Object Pascal, Oberon, chronologically, and others). True module is: 1. a part of division system; 2. a unit of hiding internals (hiding statical information); 3. a unit of hiding dynamical state (by an inteface consisting of abstract operations; and it's nothing like encapsulation). There are some other practical flavors of true modules: they are units of separate (but not independent!) compilation and dynamical loading and linking (as it's prevalent in the Oberon's family). More than, we should behold that a module may be a unit of variation several implementations of one interface (several implementations for one definition). And it's nothing like polymorphism. So, true modular programming helps us to create complex and easily modifiable systems. But modification is not as yet evolution generally.