MML Design Document: 1
Author: Tony Clark
Date: 10/11/00
Title: Analysis of multiple classification.
Problem
-------
All MML objects have a single 'of' link. All classifiers have
corresponding semantic classes. This leads to a conflict: an
object which represents the meaning of some classifier should have
an 'of' link that leads to the classifier, currently the 'of' link
leads to the appropriate sub-class of Instance.
Example
-------
Package is a classifier, PackageInstance is a semantic domain class.
Given a package p and a package instance pi where should the 'of'
link go to? pi.of = p or pi.of = PackageInstance?
Exp is a classifier, Calc is a semantic domain class. Given an expression
e and a calc c then c.of = e or c.of = Calc?
Solution
--------
It has been suggested that we need to have multiple 'of' links
from objects. This would allow a semantic object to be linked to
its
data type AND the appropriate instance of Classifier. This has
significant
implications for the rest of MML and MMT.
The following examples show how this scheme might work. Suppose
that
the only thing we can create are objects with slots. The current
MMT
syntax for this is:
@C s = v; ... end
where C evaluates to produce a classifier, s is a slot name and
v
evaluates to produce the corresponding slot value. There can be
any
number of slots.
The proposal is to generalise this to:
@{C1,C2,...} s = v; ... end
so that an object has any number of classifiers so long as it has
at
least one. Therefore, if:
o = @{A,B,C} x = 10 end
then o.of = {A,B,C} and o.isKindOf(A) = true, o.isKindOf(B) = true,
o.isKindOf(C) = true and o.x = 10.
Suppose that this is applied to the package and package instance
problem.
Define package p:
p = @{Package,Object}
name = "P";
parents = {};
contents = Set{
@{Class,Object}
name = "Dog";
parents = {};
attributes = Set{
@{Attribute,Object}
name = "owner";
type = String
end}
end}
end
NB Dog.parents = {}, this is a change to the current situation where
Dog would have to inherit from Object. Of course we could get it
to
inherit from the appropriate model class if necessary (e.g. ModelElement).
Create a package instance:
pi = @{p,PackageInstance}
contents = Set{
@{p.Dog,Object}
owner = "Mr. Brown"
end}
end
So now, pi.isKindOf(p) = true and pi.isKindOf(PackageInstance) =
true.
Note that in both cases the invariants for p and PackageInstance
will
run.
Dealing with expressions as classifiers is a bit more fiddly since
there is more going on. Here is a sketch:
e = @{Multiply,Object}
left = @{Literal,Object}
value = 10 end;
right = @{Variable,Object}
name = "x" end
end
c = @{e,BinCalc}
bindings = env;
left = @{e.left,LiteralCalc}
bindings = env;
result = 10
end;
right = @{e.right,VariableCalc}
bindings = env;
result = 20
end
end
env = @{Binding} name = "x"; value = 20 end
I would suggest that the following defaults are adopted:
@X ... end is shorthand for @{X,Object} ... end
@ ... end is shorthand for @{Object} ... end
Benefits
-------
(1) Model elements no longer have to inherit from instance classes.
(2) Multiple classes are mixed together at the point of use.
(3) Very expressive when dealing with semantic mappings.
(4) The multiple inheritance specificity problem appears simplified.
Note
----
It has also been proposed that the processing of ... in an expression
@C ... end is handed over to the class C, i.e. the meta-level defines
how to
create objects of specific types. This is consistent with other
approaches.
Therefore, the low-level syntax used in this proposal would probably
only
be used by MML systems engineers.
Warning
-------
Having multiple 'of' links is very non-standard, I cannot think
of any
other system that has it. It has significant benefits, but may
cause
problems that have not yet surfaced. It the very least the guts
of MMT
will have to be modified and the whole of the definition of MML
will
have to be checked very carefully.
The same effect can be achieved using multiple inheritance. However,
such
a solution winds up with ugly kludges where packages (e.g. p) inherit
from both packages and classes.