Logical Foundations of object oriented

and frame based language

JAMIL
Abstract

We propose a novel logic, called Frame Logic

(abbr., F-logic), that accounts in a clean,
declarative fashion for most of the structural
aspects of object-oriented and frame-based
languages. These features include object
identity, complex objects, inheritance,
polymorphic types, methods, encapsulation,
and others. In a sense, F-logic stands in the
same relationship to the object-oriented
paradigm as classical predicate calculus stands
to relational programming.
 The syntax of F-logic is higher-order,
which, among other things, allows the
user to explore data and schema using
the same declarative language. F-logic
has a model-theoretic semantics and a
sound and complete resolution-based
proof procedure. This paper also
discusses various aspects of
programming in declarative object-
oriented languages based on F-logic
A perspective of object oriented vs
declarative programming
 A number of researchers argued that objectoriented
languages are fundamentally dierent from and
 even incompatible with other paradigms especially with
logic programming This point of
 view was reecting disappointment with the lack of early
success in formalizing a number of central
 aspects of objectoriented programming Compounding
the problem was the lack of a framework in
 which to compare various approaches so that dierences
and similarities could not be seen in a common
 framework In this section we make an attempt to
clarify these issues
F-logic
 collections of class members ie of
semantically related objects the
latter denotes collections of objects
 that are structurally related Since
semantic similarity usually implies
structural similarity the two uses
 of the term type are closely related
 say that plus is a method that returns an integer
when invoked on an integerobject with an integer
 argument However when plus is invoked on an
object in class real with an argument that also
comes
 from that class the method returns an object in
class real In general just as in specifying poly
 morphic types requires more than one signature
The polymorphism of the kind illustrated in is
 called overloading
Syntax
 Informally an object molecule in ii above asserts that
the object denoted by O has properties spec
 ied by the method expressions listed inside the
brackets Data expressions are used to dene
 properties of objects in terms of what their methods
are supposed to do Inheritable data expressions
 may be inherited by subclasses and individual members
of the object when it plays the role of a class
 in contrast properties specied as noninheritable cannot
be inherited A signature expression in ii
 species type constraints on the methods applicable to
the objects in class O Typing is given both for
 method arguments and for their result
Semantics
 The dierence between the versions and
the versions in the above mappings is
that the
 versions are used to interpret
noninheritable data properties while the
versions are for the
 inheritable ones The distinction between
inheritable and noninheritable properties
was explained in
 Section the formal treatment will be
given in Section
Predicate and their semantics
 It is sometimes convenient to have usual rstorder predicates
on a par with objects cf
 as certain things are easier to specify in a valuebased setting
and because experience shows that using
 predicates alongside with objects leads to more natural
specications For instance a program may
 manipulate mostly objects but occasionally it may need to
check if a symmetric relationship eg
 equality or proximity holds among these objects Although
relationships can always be encoded via
 objects these encodings may be contrived or cumbersome In
this subsection we rst explain how
 predicates can be encoded as Fmolecules Then we show that
with only minor extensions to Flogic
 we can incorporate predicates directly both into the syntax
and the semantics
 Although relationships can always be
encoded via
 objects these encodings may be contrived
or cumbersome In this subsection we rst
explain how
 predicates can be encoded as Fmolecules
Then we show that with only minor
extensions to Flogic
 we can incorporate predicates directly both
into the syntax and the semantics
Skolemization and Clausal Form
 As in classical logic the rst step in developing a
resolutionbased proof theory is to convert all
formulas
 into the prenex normal form and then to
Skolemize them Skolemized formulas are then
transformed
 into an equivalent clausal form
 It is easy to verify that the usual De Morgans laws
hold for Fformulas Therefore every Flogic
 formula has a prenex normal form
 Once a formula is converted into an equivalent
prenex normal form it is Skolemized
Herbrand structure
 The denition of Hstructures indicates that as in classical
logic there might be a simple way to construct
 Fstructures out of Hstructures and vice versa One
minor problem here is that the Herbrand universe
 the domain of all Hstructurescannot always serve as a
domain of an Fstructure Indeed in F
 structures dierent domain elements represent dierent
objects However this is not the case with
 Herbrand universes For instance if john
 $
 fathermary belongs to an Hstructure then the terms
 john and fathermary represent the same object yet
they are dierent elements of the Herbrand universe
Herbrands Theorem
 In classical logic a set of clauses S is unsatisable if and
only if so is some nite set of ground instances
 of clauses in S this property is commonly referred to as
Herbrands theorem In Flogic Herbrands
 theorem plays the same fundamental role We establish
this theorem by considering maximal nitely
 satisable sets similarly to the proof of the compactness
theorem in A set S of ground clauses is
 nitely satisable if every nite subset of S is satisable A
nitely satisable set S is maximal if no
 other set of ground clauses containing S is nitely
satisable
WellTyped Programs and Type Errors
 In a strongly typed language a method
can be invoked only when the invocation
is allowed by one of
 the signatures specied for this method For
instance in the relational model one can
use only those
 attributes that are dened for the
particular relation at hand attempting to
use an attribute that is not
 dened for this relation will normally result
in an error
Encapsulation
 Encapsulation is a major concept in the suite of
notions comprising the objectoriented paradigm
In
 a nutshell encapsulation is a softwareengineering
technique that requires special designations for
each
 method in a class Methods designated as public
can be used to dene other methods in other
classes
 In contrast methods designated as private can be
used only in the class where they are declared
Other
 methods may be exported to some specic classes
but not to all classes
Inheritance
 The concept of inheritance is fundamental in AI
and objectoriented programming and a number of
 researchers have been working on combining this
idea with programming languages There are two
 main aspects of inheritance structural inheritance
and behavioral inheritance Structural inheritance
is
 a mechanism for propagating method declarations
from superclasses to their subclasses On the
other
 hand behavioral inheritance propagates what
methods actually do rather than how they are
declared
Further Issues in Data Modeling
 Flogic has a wide range of objectoriented
concepts represented directly in its
semantics several
 other ideas have been left out These
include complex values path expressions
and others In this
 section we propose ways to model these
missing concepts using the rich arsenal of
the builtin features
 available in Flogic
CONCLUSION
 Flogic would be a misnomer Indeed ) is merely an
algorithm that sheds little light on the nature of
 objectoriented concepts the logic is designed to
model The proof sketch of Theorem should make
 it clear that even for simple Fprograms their )
image is not easily understandable Another
argument
 which is well articulated in the concluding section
to can be summarized as follows The syntax of
 a programming language is of great importance
as it shapes the way programmers approach and
solve
 problems
 However syntax without direct semantics
is not conducive to programming Third a
direct
 semantics for a logic suggests ways of
dening proof theories tailored to that logic
Such proof theories
 are likely to be a better basis for
implementation than the generalpurpose
classical proof theory
 Unlike the relational approach that was based on
theoretical grounds from the very beginning the object
 oriented approach to databases was dominated by
grassroots activity where several systems were built
 without the accompanying theoretical progress As a
result many researchers felt that the whole area of
 objectoriented databases is misguided lacking direction
and needing a spokesman like Codd who could
 coerce the researchers in this area into using a
common set of terms and dening a common goal that
 they are hoping to achieve