From Version 10.3 to Version 11.0 ================================= Please kill all old project databases (graph pools) and recreate all specifications by reading their stored text backups (as usual). The keywords 'production', 'transaction' and 'test' are replaced. From Version 9.0 to Version 9.2 =============================== Please kill all old project databases (graph pools) and recreate all specifications by reading their stored text backups (as usual). In this version no syntactical changes have been made except for the implementation of the still missing built-in functions ord and char. We have increased the stability of the PROGRES system (hopefully) and made the scheme view appear UML-like (See CHANGES-IN-NEW-VERSION). From Version 8.0 to Version 9.0 From Version 9.0 to Version 9.4 =============================== Please kill all old project databases (graph pools) and recreate all specifications by reading their stored text backups (as usual). From Version 9.0 to Version 8.0 =============================== Please kill all old project databases (graph pools) and recreate all specifications by reading their stored text backups (as usual). The syntax of PROGRES did not change significantly from version 8.0 to version 9.0, but its implementation is a port from Modula-2 to Modula-3. A single language extension has been made. It is now possible to define repair actions for integrity constraints which are part of some node class or type declaration. Please note that the PROGRES environment offers a new command EDIT:Import in the project view window, which allows to recreate specifications from text backup files in a more convenient way as in the previous environment version 8.0. From Version 7.0 to Version 8.0 =============================== Please kill all old project databases (graph pools) and recreate all specifications by reading their stored text backups (as usual). The syntax of PROGRES has been changed (extended) considerably. a) Transactions may contain cut statements which prohibit reentrance of statement sequences during backtracking or transform potentially failing/nondeterministic statements into total/deterministic statements: ( s : [0:1] ) means execute s once and fail during backtracking instead of reentering s. ( s : [1:n] ) means stop with runtime exception if s fails instead of backtracking. ( s : [1:1] ) is the combination [0:1] and [1:n], respectively. b) Transactions have an additional cardinality qualifier which signals whether the transaction's may never fail = [1:x] or is deterministic = [x:1]. The default is [0:n] for potentially failing/nondeterministic transaction. The analyzer checks whether these hints are consistent with a transaction's body and the compiler uses these hints to improve the efficiency of generated code. c) Productions have an additional cardinality qualifier like transactions with * and + as additionally possible values: p * = ... end means that a production is applied to all occurrences of its left-hand side in parallel (with occurrences overlap in unmodified parts only). p + = ... end has the same meaning as above, except the requirement that p has at least one occurrence. d) Transactions and productions have now additional optional pre- and postconditions which are either Boolean expressions or arbitrary queries (statement sequences). e) Various forms of textual as well as graphical integrity constraints have been added. Their documentation is still under development. Integrity constraint checking is disabled as long as the corresponding interpreter switch is "off" or productions or transactions do not have the leading optional keyword "safe". f) Transforming a potentially failing/nondeterministic attribute or path expression into a total/deterministic expression is no longer a complicated task. You may simply write ( e : [x:1] ) for transforming a potentially nondeterministic expression into a deterministic expression ( e : [1:n] ) for transforming a potentially failing expression into a total (never failing) expression These conversions are important for convincing the analyzer that created specifications are consistent and they will be checked at runtime. ATTENTION: any old specification text should still be valid unless new keywords like "for" or "ensure" were used as identifiers. From Version 6.7 to Version 7.0 =============================== Please kill all old project databases (graph pools) and recreate all specifications by reading their stored text backups (as usual). From Version 6.6 to Version 6.7 =============================== Please kill all old project databases (graph pools) and recreate all specifications by reading their stored text backups (as usual). From Version 6.5 to Version 6.6 =============================== Please kill all old project databases (graph pools) and recreate all specifications by reading their stored text backups, after having made the following modifications (necessary due to syntax changes): a) replace path expressions of the form [ guard-exp ? body-exp | ... ] by [ guard-exp :: body-exp | ... ] b) replace all (attribute) expressions of the form def(exp) by not empty(exp). But preserve Def-Statements within transactions of the form def(StatExp). c) replace (again) path expressions of the form def(path-exp) by with path-exp These changes make guarded expressions and guarded path expressions more similar to each other and eliminate errorprune overloading of the keyword "def"! From Version 6.4 to Version 6.5 =============================== Please kill all old project databases (graph pools) and recreate all specifications by reading their stored text backups. From Version 6.3.1 to Version 6.4 ================================= Due to some syntax changes, the same 8 steps as described below (Conversion from 5.6 to 5.10.2) have to be applied. Of course, the list of syntax problems is different. The following problems are likely to appear: List of syntax problems ----------------------- a) "homomorphic" -> "folding" The key word "homomorphic" has been replaced by "folding". b) "=>" -> "implies" The key word "=>" has been replaced by "implies". c) When declaring attributes (meta, derived or intrinsic), you no longer have the option to put together identical declarations like MyAtt1, MyAtt2 : integer = 17; Instead, you have to write MyAtt1 : integer = 17; MyAtt2 : integer = 17; From Version 6.2 to Version 6.3 =============================== Please kill all old project databases (graph pools) and recreate all specifications by reading their stored text backups. From Version 6.1 to Version 6.2 =============================== Due to some syntax changes, the same 8 steps as described below (Conversion from 5.6 to 5.10.2) have to be applied. Of course, the list of syntax problems is different. The following problems are likely to appear: List of syntax problems ----------------------- a) "do" -> "::" In for_all-, exists- and use-expressions, the key word "do" separating the variable declaration list from the expression's body has to be replaced by a double colon "::". b) "?" -> "::" In guarded expressions, the question mark "?" separating the condition and the guarded body has to be replaced by a double colon "::". c) "valid" obsolete The key word "valid" for boolean expressions within trans- actions has become obsolete. d) postfix expressions -> function calls with arguments in brackets Postfix operators are not allowed any more. They may be replaced by function calls with arguments in brackets. e) "with" -> "def" The old key word "with" formerly used within restrictions has to be replaced by the new key word "def". f) "( BracketStat )" -> "begin BracketStat end" The brackets surrounding a BracketStat have to be replaced by "begin"/"end". see paper PROGRES-Nachtrag-94.ps for more detailed descriptions of the syntax changes From Version 6.0 to Version 6.1 =============================== No conversion necessary. From Version 5.10.2 to Version 6.0 ================================== No conversion necessary. From Version 5.6 to 5.10.2 ========================== Unfortunately, we did not have the time to write an automatically working translator which converts specifications of PROGRES version 5.6 into acceptable specications for the new PROGRES release 5.10.2. But performing this task manually will not take more than a few minutes for medium-sized specifications. You have to proceed as follows: 1) Create text dumps (with layout information) of all specifications (or use those stored in .../backups). 2) Install the new version of the PROGRES environment and delete your private progresdata directory (with exception of progresdata/backups). 3) Create a new project (pool) and a new document for each specification which should be converted. 4) Open a specification document and activate the built-in text editor. Read the old specification text (of step 1) into the appearing text window and try to commit editing. 5) The built-in parser detects now all language constructs which are no longer supported in version 5.10.2 or have a different concrete syntax. 6) Follow the following list of instructions below to eliminate all syntax errors within the old specification text. 7) After having created a context-free correct specification activate the built-in analyzer to find those parts of your specification which are erroneous with respect to the slightly more restrictive static semantics of version 5.10.2 (error messages will help you to understand the highlighted problem). 8) As a last step you may be forced to repair the layout of your specification especially concerning all graphical parts (storing layout information contains some bugs in version 5.6). List of Syntax Problems: ------------------------ 1) Constraints: not supported in the current language version due to problems with their interpretation (see paper PROGRES-Nachtrag-94.ps how to convert constraints into derived indexed boolean attributes). 2) Guards in loop and branch statements/expressions: the ":" between a condition/guard and the guarded body must be replaced by "?". 3) Variable declarations within expressions and "for_all" or "exist" conditions within boolean expressions: The ":" separating the variable declaration list from the expression's body must be replaced by "do". 4) The keywords "implies" and "equivalent" are replaced by "=>" and "<=>" respectively. 5) The "that" operator is no longer supported. You may use type checking operators to achieve the same effect (see paper PROGRES-Nachtrag-94.ps for more detailed instructions).