Termware is computer algebra system designed for embedding into language processing systems. The formal model, that underlies language semantics, is defined in the article. Also TermWare syntax and internal Java API structure are briefly described here. The article was meant to acquaint a reader both with objectoriented and functional programming and with mathematical logic fundamentals. But if you are — a programmer, who wants to use TermWare in your own projects you can skip the reading of the article except of the first paragraph.
The usual terminal algebra is built here, where the language objects are terms (expressions of f_{i}(x_{1}…x_{n}) form, variable and elementary data types, the same as those of all functional programming languages). And its only difference from standard approach is that the ordered set constructor is the dedicated term and substitution operations retain order on those terms.
The rest of the part will be devoted to wearing construction:
Σ_{pt} = {CHAR,SHORT,INT,BigDecimal,BigInteger,BOOL,STRING,ATOM}
each constant is linked with the value on corresponding primitive type set, i.e. val : Σ_{c}^{pt} > Dom^{pt}, where
Let’s define concrete terms set T_{c} :
And substitute terms set T_{v}
Term, which belongs to T_{v}∕T_{c} we will call term with free variables. For each term T the set of substitute symbols, that form the term, will call the set of free variables of the term and will mark as v(T).
Let’s define next model functions of our term system:
i. e. term set is just partly regulated. Which allows to designate the ordered set constructor.
And fvi(x) is term indexes set .
Rewriting rule is the three: (X,t_{in},t_{out}) where:
Rewriting operation semantics is defined by following expression:
Let’s extend rewriting operations for rules set:
and for free terms set ^{1} :
Evidently, the rule can be represented as term: rule(vars,t_{in},t_{out}) where:
We will say that term set x can be rewritten into term set y, if there exists a chain z_{1}…z_{n} such as
At last , will say that term set T converges relatively to set of rules R if there exists fixed point of equation:
The set of rules R is called converging relatively to finite set of terms T, if apply^{*}(T,R) is finite.
Rule set has the noetherian property, if
Thus we come to wideknown rewriting rules theory , with some differences from canonical statements:
Those differences don’t add anything essentially new to mathematical properties of algebra except that it’s more convenient to work with it, from technical point of view .
We would extend semantics of ruleset evaluation on nonconfluent rule systems, by applying order of rule evaluations in critical pairs. I. e. rules p, s forms critical pair, if exis such term t, than: apply(p,t)≠apply(s,t). Newman’s lemna say, that if system is locallyconfluent (i.e. for each criticat pair exists common reduct for apply(p,t) and apply(s,t) than system is confluent. But many practically interested systens better described in terms of locallyincoherent rules with fixed order of evaluation.
So, let’s introduce partial ordering of rewriting rules by ’concretization’ of input patterns. I.e. we will say that t1≤_{c}t2 when t1 is ’more concrete’ than t2. And what is more concrete ?  this means that t1 can be represented as partial case of t2, i.e. exists substitution of free variables s: subst(t2,s) ≡ t1. Equivalent definition: ∀t : free_unify(t,t1) ⇒ free_unify(t,t2).
Now, let p = (in_{p} → out_{p}) and s = (in_{s} → out_{s}) are two rules, which form critical pair. we see that p ≤_{c}s if in_{p}≤_{c}in_{s}, and let’s fix the order as evaluation as: more concrete term evaluated first, i. e.
It’s easy to show, that for each ruleset r_{1}…r_{n} where ∀i,j : i≠j ⇒⁄ r_{i} ~_{c}r_{j} can be build equivalent locallyconfluent ruleset.
Next question, that should be considered is the term calculation representing. Usual approach (set of rules, that convert input term set to output) doesn’t suit us, becouse in real world we need something more:
Among the samples of such applications there are set of rules for determination of the following actions in a business process, where set depends on process variables, or the code generation process, that depends on certain architecture, or the output rules, presented by facts of the deductive database.
Consequently, we need to define operations semantics by including openly environment interaction and rules set modification dependent on state.
Terminal mechanism is the four: < S,E,ϕ_{s},ϕ_{e} > where:
Note, that the division is quite relative, for rewriting rules are presented by terms of special kind.
The terminal mechanism behavior is defined by the following transformation in discrete time unit:
(here x_{Y } denotes projection x onto coordinate Y in general sense of set theory).
The following diagram can be more clear.
phi_s
<S,E,X> > <S’,Y’> phi_e  > E’ E 
What changes we should make in the term rewriting system to reflect operation semantics requirements  we should just add some syntax of environment interaction:
Input/output pair (X : x → y) is replaced by the four (X : (x,e_{in}) → (y,e_{out}), where
We will denote the four as x[e_{in}] > y[e_{out}]. Expression x[e_{in}] for term t can be interpreted as comparison with sample x while executing subst(e_{in},snd(free_unify(t,x))) (let snd(free_unify(t,x)) = s), y[e_{out}]  as substitution of unification into y and subst(e_{o}ut,s) execution.
Lexical Units:
Syntax:
See also BNF definitions
Full description of buildin systems see in TermWareAPI reference
Samples of systems, defined by TermWare Language:
System(BooleanAlgebra,default, ruleset( $x & ($x => z) > $z , not($x & $y) > not($x)  not($y) , not($x  $y) > not($x) & not($y) , $x & ($y  $z) > ($x & $y)  ($x & $z) , not(not($x)) > $x , ), FirstTop); System(BooleanLogic,general, ruleset( import(BooleanAlgebra), true => $x > $x, false => $x > not($x), true  $x > true, false  $x > $x, true & $x > $x, false & $x > false, not(true) > false, not(false) > true ), FirstTop); 
Here, as you can see all rules are shortened (without operations and data base).
The full system model with operations and fact base demands facts semantics and operations description (or rather their programming in Java) and will be of enormous volume for this article.
Therefore below we’ll cite terminal system "of real life" ^{2}, and facts semantics and operations we’ll describe informally :
System(BugFixing,DevelopmentProcess,
ruleset( received($bug_id) > check_confirmation($bug_id) // human_task(check_bug($bug_id)), check_confirmation($bug_id) [confirmed($tester,$bug_id)] > known($bug_id) // human_task(fix_bug($bug_id), write_regression($bug_id) ), check_confirmation($bug_id) [not_confirmed($tester,$bug_id)] > true // send_not_confirmed($bug_id,$tester), known($bug_id) [ fixed($developer1, $bug_id) && added_regression($developer2,$bug_id) ] > true // send_closed($bug_id,$developer1) ), FirstTop) 
This example describes TermWare application in businessprocesses organization system. As you’ve guessed the example is software error message processing.
Here fact base (environment) can answer the questions:
And can interpret messages:
Notice, that environment data are transmitted to the system by sentential expressions in conditions. More detailed this primer is described in [1].
From terminal systems programming point of view it is convenient to use Hierarchical Name Mechanism resembling to idl modules, C++ namespaces or Java packages.
In TermWare such mechanism is represented by domain term. Syntax: domain(name,def_{1},…def_{n}), where def_{i} is systems or subdomains definition terms.
Example:
domain(algebra,
System(Semigroup), domain(LiGroups, System .. ) ) 
Also automatic system definitions loading from files is implemented: while interpreting embedded conversions in any context, if full system name (for instance:x.y.z, i.e. system with z name, which is located in x/y domain) is found, then the file is automatically loaded from according location of file system relative to termware.path  Java environment property (in case of addressing to x.y.z system an attempt to read <termware.path>/x/y/z.def file will be performed).
TermWare syntax, as it is, is not always convenient for data input: sometimes we’d like to use more natural problemoriented language for the purpose.
Toward this aim TermWare provides extension possibility: users can embed syntax parsers of their own languages by implementing verbIParser and IParserFactory interfaces in their Java classes and by registering the classes names in general dictionary.
Main TermWare entity is Term interface.
As you can see, ITerm is interface where the following elements are defined:
Unlike many computer algebra systems, term system is not build bottomup, from atomic data types, but topdown, i.e. any class, that extends abstract class Term, can be declared as term.
Of course, there exists predetermined term types set (described in Formal Model). According inheritance diagram looks as follows:
Term
 *AbstractPrimitiveTerm    *AtomTerm    *BooleanTerm    *DoubleTerm    *IntTerm    *NILTerm    *StringTerm  *AbstractComplexTerm    *SetTerm  *XTerm 
But from programmer’s point of view it’s not necessary to use these classes: it would be better for this purpose to use TermFactory interface.
TermFactory is a class, accessible from TermWare singleton, that provides methods to create terms. (API Description)
Usage examples:
Term term=TermWare.getInstance().getTermFactory().createAtom("qqq");

уПЪДБУФ
TermFactory termFactory=TermWare.getInstance().getTermFactory();
Term term=termFactory.createComplexTerm3("f_3", termFactory.createInt(3), termFactory.createComplexTerm2("f", termFactory.createAtom("a1"), termFactory.createAtom("a2") ), termFactory.createX(1) ); 
will create term f_{3}(3,f(a1,a2),x_{1}) with one free variable x_{1}.
It is just term converter: (API Description)
Main converter functioning is concealed in transform method, which transform input term to output in some system and with transformation context (which give us access to current substitution and so on).
Let’s consider how term converters are bound with rewriting rules: we can create according converter just by rewriting rule.
And at last rewriting strategy: (API Description) It’s rather difficult object, which includes rules (term converters) set and the rules application algorithm.
End user usually doesn’t work directly with rewriting strategys, but application programmers can create their own rewriting strategy by inheriting their class from AbstractTermRewritingStrategy. (API Description)
This minding of strategy come from APS [3], another approach can be found in Stratego [2].
IFacts (API Description) is terminal system knowledgebase pattern, that figures environment (or oracle) of our logic.
What we can do with fact:
Naturally, knowledge base semantics is utterly defined by data domain, implementation should be created separately each for a problem and may include requests to relation database or to input/output operators.
Rule x[condition] > y[action] is applyed to term t as follow:
TermWare provide implementation of Facts DB with name default in class DefaultClass (API Description)
In this class check and set methods implemented as follow: Logical and ariphmetical expressions are evaluated, if during evaluation we meet functional symbol, with name and arity wich matched name and arity of some method of own class, than this method is called. Argument and result are converted to Java types, if needed, using Java reflection API.
I. e. for calling methods of you facts database from rules just derive you facts database from class DefaultFacts.
Except ’logical’ environment, defined in the logic, we have also ’program’ or ’physical’ environment, that defines:
The environment is encapsulated in IEnv interface (API Description)
Now we can define Terminal System, so: Terminal System is rewriting rules with strategies and fact data base and program environment interface totality. (API Description)
Knowing all this we can define the term conversion operations: reduce.
Also we can define methods of rules adding to system, of term reduction and so on. These methods have comparatively simple interface (programmers, who use TermWare as library should start API studying exactly from these methods).
Typical code of terminal system creating looks as follows:
IEnv env=TermWare.getInstance().createEnv(
"ua.kiev.gradsoft.TermWare.envs.SystemLogEnv", envTerm ); ITermRewritingStrategy strategy=TermWare.getInstance().createJavaStrategy( "ua.kiev.gradsoft.TermWare.strategies.TopDownStrategy" ); IFacts facts=TermWare.getInstance().createFacts( "ua.kiev.gradsoft.TermWare.facts.AttributeFacts", env ); ITermSystem system=new TermSystem(strategy,facts,env); 
TermWareInstance (API Description) is , figuratively, a shank, that contains hierarchical domain system (see Domain class, (API Description), getDomain() method), user dictionaries of language parsers names and printers names.
Usially we have one instance in JVM, but it is possible to create and use few instances when we need few unrelated theories in one JVM (for example inside application server).
You can define user language parsers embedding into TermWare system with the help of these interfaces.
General usage pattern looks as follows:
TermWareInstance.addParserFactory(String language, IParserFactory factory)

method. After that verbloadFile(fname,X) call will use X language parser.
These interfaces define embedding of term own output. The actions should be the same as in previous part, except instead of input stream we use output stream. API Description:
[1] Ruslan Shevchenko. Anatoliy Doroshenko. Managing business logic with symbolic computations. Lecture Notes in Informatics V. 30  Proceeding of Information Systems Technology and its Applications 2003, pages 143–152, 2003.
[2] Visser E. Stratego: A language for program transformation based on rewriting strategies. system description of stratego 0.5. Rewriting Techniques and Applications (RTA 01), 2051.:357–361, 2001.
[3] J.V.Kapitonova A.A.Letichevsky M.S.L’vov and V.A.Volkov. Tools for solving problems in the scope of algebraic programming. LNCS, 958, 1995.