2009-12-29

frame-based type systems

11.8: adda/oop/frame-based type systems:

. a critical clarifier is how a frame-based subsystem
can be used by the type-checking subsystem .
def's:
. the purpose of the kb system is to support programs that are
acting on the domain as it is represented by the database .
. the type system needs to find a symbol's intended uses or roles,
and make sure it's not used in unintended ways .


web.adda/{frame lang, metaprogramming, quasiquote, Component-based}:



FLORA-2 is an advanced object-oriented knowledge base language
and application development environment.
The language of FLORA-2 is a dialect of F-logic
with numerous extensions,
including meta-programming in the style of HiLog
and logical updates in the style of Transaction Logic.
FLORA-2 was designed with extensibility and flexibility in mind,
and it provides strong support for modular software design
through its unique feature of dynamic modules.
. it's based on XSB
a Logic Programming and Deductive Database system .
a few open-source projects that use XSB:
# Flora is an object-oriented language
for building knowledge-intensive applications, which is based on the ideas of
F-Logic, HiLog and Transaction Logic.
# XMC is the main product of the Logic-based Model Checking project.
# Logtalk is an open source object-oriented logic programming language
that can make use of multi-threading.
# OpenSHORE is a hypertext repository
that stores data about and described by documents.
Access to this information is provided as hypertext.

OpenSHORE (Semantic Hypertext Object Repository)
an XML based Semantic Document Repository (SDR)
with a free definable meta model
that builds up a semantic network from sections
and relations in documents.
OpenSHORE is an hypertext repository:
The repository stores objects that appear in documents
together with their relations in the semantic net.
Hypertext navigation follows these relations
in the semantic net.

Frame-based systems represent domain knowledge
. frames are a notion originally introduced by Marvin Minsky (1975)
in the seminal paper
"A framework for representing knowledge" .
. prior to that, domain knowledge was represented by
rule-based and logic-based formalisms .

Minsky proposed organizing knowledge into chunks called frames.
These frames are supposed to capture the essence of
concepts or stereotypical situations,
by clustering all relevant information for these situations together.

Important descendants of frame-based representation formalisms
are description logics
that capture the declarative part of frames using a logic-based semantics.
Most of these logics are decidable fragments of first order logic
and are very closely related to other formalisms
such as modal logics and feature logics.

. Minsky's 1975 ideas were evolved into FRL and KRL
(Bobrow and Winograd 1977).
KRL addressed almost every representational problem
discussed in the literature.
-- a very rich repertoire and almost unlimited flexibility.

Features that are common to FRL, KRL, and later frame-based systems
(Fikes and Kehler 1985) are:
(1) frames are organized in (tangled) hierarchies;
(2) frames are composed out of slots (attributes)
for which fillers (scalar values, references to other frames or procedures)
have to be specified or computed; and
(3) properties (fillers, restriction on fillers, etc.)
are inherited from superframes to subframes in the hierarchy
according to some inheritance strategy.
. from math, a monotone function is order-preserving:
x less than y implies
f(x) less than f(y),

. monotonic logic is a formal logic whose consequence relation
is monotonic
meaning that adding a formula to a theory
never produces a reduction of its set of consequences.
Intuitively,
monotonicity indicates that learning a new piece of knowledge
cannot reduce the set of what is known.
A monotonic logic cannot handle various reasoning tasks
such as reasoning by default
(consequences may be derived only because of
lack of evidence of the contrary),
abductive reasoning
(consequences are only deduced as most likely explanations)
and some important approaches to reasoning about knowledge
(the ignorance of a consequence must be retracted
when the consequence becomes known)
and similarly belief revision
(new knowledge may contradict old beliefs).

An example of a default assumption is that the typical bird flies.
As a result, if a given animal is known to be a bird, and nothing else is known,
it can be assumed to be able to fly.
The default assumption must however be retracted if it is later learned
that the considered animal is a penguin.
This example shows that a logic that models default reasoning
should not be monotonic.

a clash of intuitions: the current state of nonmonotonic multiple inheritance
ijcai.org/Past%20Proceedings/IJCAI-87-VOL1/PDF/094.pdf
frame lang's are found in the context of inheritance networks
. these are building relations, eg the assertion prop(x)
is represented as a positive link x -> (class for which prop is true)
while a complementary assertion can have a negative link
nonmonotonic system permits exceptions to inherited properties
eg, neg'links can override pos'links .

. the type systems of oopl's are unipolar (positive linking only) monotonic
but frame systems (eg FRL) are unipolar non-monotonic .

homogeneous inheritance system (unlike hetero)
are one or the other but not both of
{ monotonic: all links are strict
, thoroughly nonmonotonic: links are defeasible
} the concern of this paper is
non-mono homo multiple inheritance systems
. a property of many logic systems
that states that the hypotheses of any derived fact
may be freely extended with additional assumptions.
Any true statement in a logic with this property
continues to be true, even after adding new axioms.
Logics with this property may be called monotonic,
to differentiate them from non-monotonic logic.
. typing systems that work similarly to frame'based kb systems
are termed prototype-based languages that use delegation:
the language runtime is capable of dispatching the correct method
or finding the right piece of data simply by following a series of
delegation pointers (from object to its prototype)
until a match is found.
As such, the child object can continue to be modified
and amended over time without rearranging the structure of its associated prototype
as in class-based systems.
It is also important to note that not only data but also methods
can be added or changed.
For this reason, most prototype-based languages
refer to both data and methods as "slots".

Metaobjects are lightweight classes that have but a single instance
(the metaobject's referent)
A metaobject contains an explicit reference to its referent.
An object, working in tandem with a metaobject,
is functionally similar to a SELF object that describes its own behavior.
. any entity that manipulates, creates, describes, or implements other objects.
The object that the metaobject is about is called the base object.
Some information that a metaobject might store
is the base object's type, interface, class, methods,
attributes, variables, functions, control structures, etc.
A metaobject protocol (MOP)
is an interpreter of the semantics of a program that is open and extensible.
Therefore, a MOP determines what a program means
and what its behavior is,
and it is extensible in that a programmer (or metaprogrammer)
can alter program behavior by extending parts of the MOP.
The MOP exposes some or all internal structure of the interpreter
to the programmer.
The MOP may manifest as a set of classes and methods
that allow a program to inspect the state of the supporting system
and alter its behaviour.
MOPs are implemented as object-oriented programs
where all objects are metaobjects.
ompiling process, but do not exist when the program is running.
One of the best-known runtime MOPs is the one described in the book
The Art of the Metaobject Protocol (often referred to as AMOP);
One example use of a MOP is to alter the implementation of multiple inheritance.
A recurring issue is how to resolve conflicting slots and methods of the superclasses.
Typically, language designers select one solution,
and language users must live with it.
A metaobject protocol is one way to implement aspect-oriented programming languages.
Many of the early founders of MOPs, including Gregor Kiczales
have since moved on to be the primary advocates for
aspect-oriented programming.
http://en.wikipedia.org/wiki/Aspect-oriented_programming
Aspects emerged out of object-oriented programming and computational reflection.
AOP languages have functionality similar to, but more restricted than
metaobject protocols.
Aspects relate closely to programming concepts like
subjects, mixins, and delegation.
Other ways to use aspect-oriented programming paradigms include
Composition Filters
and the hyperslices approach.
Since at least the 1970s, developers have been using forms of
interception and dispatch-patching that are similar to
some of the implementation techniques for AOP,
but these never had the semantics that
the crosscutting specifications were written in one place.
Designers have considered alternative ways to achieve separation of code,
such as C#'s partial types,
but such approaches lack a quantification mechanism
that allows reaching several join points of the code
with one declarative statement.
an object-oriented software paradigm
in which the state (fields) and behavior (methods) of objects
are not seen as intrinsic to the objects themselves,
but are provided by various subjective perceptions (ÒsubjectsÓ) of the objects.
The term and concepts were first published in September 1993
in a conference paper[1] which was later recognized as being
one of the three most influential papers to be presented at the conference
between 1986 and 1996[2]. As illustrated in that paper,
an analogy is made with the contrast between the philosophical views of Plato and Kant
with respect to the characteristics of ÒrealÓ objects,
but applied to software ones.
For example, while we may all perceive a tree as having a
measurable height, weight, leaf-mass, etc.,
from the point-of view of a bird,
a tree may also have measures of relative value for food or nesting purposes,
or from the point-of-view of a tax-assessor,
it may have a certain taxable value in a given year.
Neither the bird's nor the tax-assessor's additional state information
need be seen as intrinsic to the tree,
but are added by the perceptions of the bird and tax-assessor,
and from Kant's analysis,
the same may be true even of characteristics we think of as intrinsic.

Like aspect-oriented programming,
subject-oriented programming, composition filters, feature oriented programming
and adaptive methods
are considered to be aspect-oriented software development approaches.

Further advances in FOSD arose from recognizing the following facts:
Every program has multiple representations
(e.g., source, makefiles, documentation, etc.)
and adding a feature to a program could elaborate each of its representations
so that all representations are consistent.
The language in which the metaprogram is written is called the metalanguage.
The language of the programs that are manipulated is called the object language.
The ability of a programming language to be its own metalanguage
is called reflection or reflexivity.

Having the programming language itself as a first-class data type
(as in Lisp, Forth or Rebol) is also very useful.

Generic programming invokes a metaprogramming facility within a language,
in those languages supporting it.

generative programming vs incremental compilation vs modifiable at runtime:
. the compiler is a metaprogramming tool;
if incremental compilation is available to a program
then metaprogramming can be performed without actually generating source code.


In Lisp metaprogramming, the quasiquote operator (typically a comma)
introduces code that is evaluated at program definition time
rather than at run time.
The metaprogramming language is thus identical to the host programming language, and existing Lisp routines can be directly reused for metaprogramming if desired.

. in lisp a quote is a hard quote,
meaning there is no attention payed to unquote as an escape .
. the quasiquote does allow the unquote to work as an escape from quote .


Accord Programming Framework (pdf)
The Accord programming framework supports the development of
autonomic Grid applications .
Accord enables runtime composition and autonomic management
of these components using dynamically defined rules.

. current (2004) frameworks have interaction patterns
that can't be defined dynamically .
. compon'based frameworks don't have
the context-aware self-mgt of individual compon's .
. service'based models implicitly assume
that context does not change during app`lifetime .
. dynamic context requires autonomic computing,
capable of managing themselves using high-level rules
with minimal human intervention.

The Accord programming framework consists of 4 concepts.
* an application context
that defines a common semantic basis for the application.
* the definition of autonomic components
as the building blocks of autonomic applications.
* the definition of rules and mechanisms for
the dynamic composition of autonomic components.
* an agent infrastructure
to support rule enforcement to realize self-managing
and dynamic composition behaviors.

Accord builds on the AutoMate middleware infrastructure
that provides the essential services required to support
the development and execution of autonomic applications.
( naming service,
discovery service,
lifecycle management service,
and registration service.
)