Oil Reference Manual
Some `usual' problems in operator identification are presented with some
suggested work-arounds using OIL(along
with general guidelines for effective use of OIL.)
It is relatively easy to design and implement with OIL in incremental
steps. One can work with the atomic/primitive types of your schema
first and get the desired behavior with only
identification. You can then add coercion sequence construction. And
then work on the class specifications. Last of all one should work on
compile time entity definition. These guide lines can be easily ignored
but I would suggest that you find replacements for these rules rather
than not do incremental design and implementation.
For some problems it is easier to identify the operand types and
associated coercion sequences independently of the operator. When using
OIL to select addressing modes for assembly language this is often the
case as the instruction set is factored into operation and operand
address. Operations can be factored into classes which support
different operand address mode signatures. The classes can be defined
as an indication and the different patterns of address modes are the
strongly typed data flow operators for the instruction.
If we didn't use this method of `instruction classes' then we would have
to duplicate the address mode patterns for each instruction in the
class. This would be time consuming, redundant, and a strain on our
name generation faculties. And such a multiplicity of names would cause
its own confusion, reducing the benefit of using OIL.
There are two ways to handle errors with OIL:
use your own error type and
Each has its own advantages.
OIL's error type is
OilInvalidType and is by definition coercible
to and from any type. Thus once an expression is assigned this value it
will make an end-run on OIL's strong typing and match any operator which
satisfies the other argument constraints. In the degenerate case where
all operands are
OilInvalidType then any identifiable operator will
If your own type is used(say
ErrorType) you must define an
operator with it in its signature(the only way to define a type other
than class instantiation.)
By not having any type coercible to it no operator will be identified
and thus no valid operator will be returned and the function
OilIsValidOp will return false allowing easy error detection.
The error operator(
OilInvalidOp) has a type signature of all
OilInvalidType. Thus if it is identified, which in the error case
it is, no type errors will be propagated up or down the tree.
If you need to model OIL in your compiler design, one of the most
convenient ways is to consider the set of declarations which the OIL
library manages as a database. This data base is initialized by the OIL
specification and modified and accessed via the library functions.
OIL has a very simple schema model. All of the library routines only add
declarations to an OIL schema. There is no way to remove a declaration
from an OIL schema once it has been added. This can have two impacts
on your use of OIL. Every added declaration increases the cost of an
identification which it may impact. Once an identification is added to
the schema it may satisfy an identification request, the only way to
prevent it is to control what kinds of requests are made.
OIL has a two level search strategy: minimum cost identification and if
costs are equal the most recent identification added to the schema.