RuleWorks

RuleWorks

Portability and Compatibility Issues

This chapter provides information on differences between platforms. It includes:

  • File specifications
  • Input Source and Output Destination
  • Hardware and Operating System Restrictions
  • Internationalization Issues
  • RuleWorks and OPS5 Compatibility Issues

 

File Specifications

The restrictions on file names vary according to operating system. The following characteristics are typical of file names on various platforms, but are restricted when using RuleWorks:

Brackets ([]) signify an index into a compound attribute. The comment character for RuleWorks is a semicolon (;). Therefore, if the file specification you supply includes any of these characters, you must enclose it in vertical bars ( | | ).

The following command illustrates VMS-style file specifications:

@ |USER$1:[SMITH.WORK]INITIALIZE-MEMORY.WM|

If your file specification needs to be passed to the operating system in lowercase letters, you must enclose it in vertical bars ( | | ).

The following command illustrates UNIX-style file specifications:

@ |usr/users/smith/work/initialize-memory|

If your file specification contains any of the following characters, you must enclose the file specification in vertical bars ( | | ): caret (^), tilde (~), number sign (#), percent sign (%), ampersand (&), parentheses (()), and braces ({ }).

The following command illustrates MS-DOS-style file specifications:

@ |C:\smith\work\init%mem.com|

 

Input Source and Output Destination

If you do not use the DEFAULT command or action to specify otherwise, RuleWorks uses standard input and standard output (SYS$INPUT and SYS$OUTPUT on VMS systems).

 

 

Hardware and Operating System Restrictions

On VMS systems, you cannot write more than 252 atoms at a time.

 

 

Internationalization Issues

On VMS systems, RuleWorks collates symbols according to the Digital Multinational Character Set.

This does not follow the I18N Guidelines. Please use the specified NCS routines.

On MS-DOS, RuleWorks does not change the active code page (see your DOS manual for the Chcp command). On Windows NT, RuleWorks does not change the Internationalization setting.

 

Compatibility Issues

There are two major differences and numerous minor differences between RuleWorks and OPS5:

  • The first major difference is that RuleWorks, makes no attempt to be 100% compatible with the public domain OPS5. Constructs like LITERALIZE, LITVAL, and VECTOR-ATTRIBUTE are not available in RuleWorks.
  • The second major difference is that the public domain OPS5 provides none of the modularity features that RuleWorks provides, although most of the other integration features were provided.

 

These modularity features are covered briefly in Chapter 12. See Chapter 5 for more details.

 

  • The minor differences include several match extensions, optional data typing on attributes, some new actions and functions, and other changes.

 

Constructs Obsolete in RuleWorks

None of the features described as obsolescent in the OPS5 Compatibility and Migration guide is implemented in RuleWorks. Constructs that were obsolescent in OPS5 and are obsolete in RuleWorks include:

· All of the OPS$... API routines

· CE variables

· Value disjunctions or variables in the class position in a CE

· LITERAL, LITVAL, and LITERALIZE

· SUBSTR and VECTOR-ATTRIBUTE

· EXTERNAL declaration

· CALL action and command

· CBIND action

· HALT action

· COMPUTE function

· ACCEPT function

· ACCEPTLINE function

Features Added to RuleWorks

The following differences between RuleWorks and OPS5 are side-effects of the new modularity features:

· An ENTRY-BLOCK (or DECLARATION-BLOCK, or RULE-BLOCK) construct and an END-BLOCK construct are now required as wrappers around all other constructs.

· There is a new compiler command with a completely new set of compiler qualifiers.

· There is now no negated refraction. The new refraction semantics are simply: "Within an invocation of an entry-block, once an instantiation has fired, that specific instantiation will never fire again."

· MEA is now the default conflict resolution strategy.

· The conflict resolution strategy can only be set at compile time as an ENTRY-BLOCK clause, so there is now no STRATEGY command. An entry block checks when it starts up that each rule block it activates has the same strategy as it does.

· There is no RUN action, where in OPS5 it is allowed only in the STARTUP. By default, an entry block always starts running.

· The appearance of the command interpreter can now be controlled by the programmer using the Debug compiler command qualifier, the DEBUG action, and the rul_debug API routine. This is unlike OPS5 where source code changes had to be made to control the interpreter's appearance.

· Because the same entry block can now be invoked multiple times recursively, when a rule instantiation is fired, it is not actually removed from the conflict set, even though it ceases to be visible there. If you are watching CS changes, be warned that you may see a fired instantiation leaving the conflict set long after it ceased to be visible via the CS command.

· There is no ^C handler in the interpreter, as this could interfere with a user-supplied handler.

· Direct instances of the class $ROOT cannot be created in RuleWorks because of the data modularity.

· The name MAIN (or |main|), when used as an entry block name without an ACCEPTS clause or a RETURNS clause for the ENTRY-BLOCK creates a C compliant entry point named "main" by automatically adding a return type of long.

· RETURN is now a command as well as an action.

· The extra-name argument to all the API routines that accept class names is now used. If supplied the extra-name should be the name of the block where the class was declared. This allows independent rule subprograms to each have a class defined that happen to have the same class name.

· There is no RESTART command.

Minor Changes in RuleWorks

This section covers differences between RuleWorks and OPS5 that were not described as obsolescent in OPS5, and are not due to the new RuleWorks modularity features.

Match Extensions

Several new matching features have been added, including:

· Variables and other value expressions are now evaluated within a value disjunctions, including variables bound in other condition elements.

· Relational predicates (>, <, >=, <=, =) can compare integers versus floats, and symbols versus symbols using localizable lexicographic ordering.

· New similarity predicate, ~=, that for numbers compares integers and floats for equality within a 1% margin, and for symbols uses the SOUNDEX algorithm to compare phonetic (in English) similarity.

· New dissimilarity predicate, -~=, that matches when the similarity test fails.

· Comparisons of compound attributes and a COMPOUND function are now supported.

· The containment and non-containment predicates can now be applied to scalar attributes, as long as the argument to the predicate is a compound value (e.g. ^name [+]). In addition, You can now use the containment and non-containment predicates in conjunction with a scalar predicate. This allows you to specify the test to be performed between a scalar value or attribute and each element of a compound attribute or value. Previously, the containment tests were always for identity.

Optional Attribute Data Type Restrictions

Optional attribute data types allow you to restrict the domain of an attribute to a specific type of value. The set of supported domain restrictions are: INTEGER, SYMBOL, FLOAT, OPAQUE, and INSTANCE-ID. If the INSTANCE-ID domain is specified, then a specific class may optionally be identified by stating: INSTANCE-ID OF <class>.

For example:

(OBJECT-CLASS job-category

^category-name SYMBOL

^max-salary FLOAT

^min-salary FLOAT

^employees COMPOUND INSTANCE-ID OF employee

^salaries COMPOUND FLOAT)

You are not required to supply attribute domain restrictions. If you do, however, the compiler (and if necessary, the run-time system) rigorously enforces those restrictions.

The PPCLASS command shows any domain restrictions along with the class's attributes.

New RHS Actions

The following RHS actions are new in RuleWorks

· The IF...THEN...ELSE... and WHILE...DO... actions provide conditional control over other RHS actions in rules or ON- statements.

· The REMOVE-EVERY action provides a means to delete objects by class.

New Functions

The following functions are new in RuleWorks

· The EVERY function (for RHS only) collects all instances of a class. Accepts a class name, returns a compound of INSTANCE-IDs.

· The GET function (for RHS only) can retrieve arbitrary attribute values from arbitrary instances. (NOTE: GET can be used with unmatched objects. Unmatched objects are objects that were not in the firing instantiation. For example, a variable bound to the ^foo attribute, if it was an instance identifier, would be an unmatched object.)

· The new GENINT function returns a system-generated INTEGER. The GENATOM function changed to take an optional argument that specifies a prefix for the generated symbol. The default prefix is still G:.

· The IS-OPEN function checks whether a file stream is open. It accepts a file-id; returns OUT or IN if open, NIL if not.

· The MAX and MIN functions find the largest or smallest value among their arguments.

· The SUBCOMPOUND function (and the new SUBSYMBOL) can be used on the LHS.

· The SUBSYMBOL function extracts a segment of a symbol.

· The SYMBOL-LENGTH function counts the characters in a symbol. Accepts a symbolic value, returns an integer.

Miscellaneous Changes

· As a result of the introduction of the new semantics for the relational predicates, the predicate, = (now called the equality predicate), is no longer equivalent to the implied identity predicate, and it cannot bind an unbound variable.

· The implied predicate is now identity, not equality. The identity predicate can bind a variable.

· Definition of equality for symbols has changed: it is no longer case-sensitive.

· Containment predicate has changed: you can now test whether a scalar value is contained by a compound, as well as whether a compound value contains a scalar.

· Variables inside disjunctions of values are evaluated in RuleWorks.

· First argument to COPY, MAKE, MODIFY and SPECIALIZE actions is no longer required to be a variable bound to a ^$ID attribute on the LHS. Can be bound to a different attribute or the result of a GET function, but must evaluate to an INSTANCE-ID of an object class that is visible to the active entry block.

· External routine names are not allowed to be the same as actions or construct types.

· External routines can accept a dynamically-size array.

· Rules or classes can not have names that are predicate operators or non-symbolic values.

· The name of the WATCH command has been changed to TRACE.

· The output from PPWM, WM, and TRACE WM now shows the readforms of all attribute values, instead of the printforms. The output from WRITE still shows the printforms.

The syntax for many of the debugging commands has changed. Using the old syntax now generates a syntax error but also usage and example messages.

· The behavior of the EXIT command has changed since OPS5. Previously, if the OPS5 routine was not your main program, EXIT would return control to the calling program. In RuleWorks, EXIT always returns to the operating system.

· Unmatched objects can now be acted upon by the REMOVE, COPY, MODIFY, and SPECIALIZE actions. The compiler gives an informational message (and generates extra run-time checking code) whenever it is unable to verify that the instance argument passed to one of these actions is indeed a valid instance identifier of an existing object.

· Two new special atoms; one for each of the new types: the null Instance-id, #0, and the null Opaque value, %x0 (equivalent to C's NULL).

© RuleWorks.co.uk | | Sitemap