a portable approach for bidirectional integration between a logic and a statically-typed...
DESCRIPTION
This dissertation seeks to improve on the state of the art for creating systems integrating modules written in both a logic and a statically-typed object-oriented language. Logic languages are well suited for declaratively solving computational problems that require knowledge representation and reasoning. Modern object-oriented programming languages benefit from mature software ecosystems featuring rich libraries and developer tools. The existence of several integration approaches testifies the interest of both communities in techniques for facilitating the creation of hybrid systems. In this way, systems developed in an object-oriented language can integrate modules written in a logic language that are more convenient for solving declarative problems. On the logic side, non-trivial declarative applications can take advantage of the existence of large software ecosystems such as those surrounding contemporary object-oriented languages. The combination of both paradigms allows a programmer to use the best language available for a given task. Existing integration approaches provide different levels of abstractions for dealing with the integration concern (i.e., the required interoperability in order for logic routines to access the object-oriented world, and vice versa). Some of them still require significant amounts of boilerplate code which hinders their adoption and steepens their learning curve. Others provide a high degree of integration transparency and automation which simplifies their usage. However, many of those approaches often impose strong assumptions about the architecture of a system (e.g., a logic program must run embedded in an object-oriented one) thus suffering from portability issues. Furthermore, most approaches provide limited support for custom context-dependent reification of objects in the logic world and custom mappings of arbitrary logic terms to objects in the object-oriented world. To address these problems, we introduce our portable and customisable approach for bidirectional integration between a logic and a statically-typed object-oriented language. This approach enables a transparent and (semi-) automatic communication between routines in these two worlds. In addition, it provides a customisable context-dependent mechanism for defining how artefacts in one language should be reified in the other language. A concrete implementation is provided as a portable Java--Prolog interoperability framework. To ensure portability, our framework has been made compatible with three open source Prolog engines (SWI, YAP and XSB) by means of drivers. We validated our approach through case studies requiring a seamless integration of declarative programs in Prolog with object-oriented programs in Java.TRANSCRIPT
Université catholique de Louvain Information and Communication Technologies,
Electronics and Applied Mathematics
!
Public Defense!!
Sergio CASTRO MEJIA Master of Science in Computer Science
!
For Obtaining the Degree of PhD in Engineering Sciences, Computer Science!
1
:- object(phd_thesis).!!! :- info([!! ! author is 'Sergio Castro',!! ! date is '8th of September 2014']).!!!! title('A Portable Approach for Bidirectional Integration!between a Logic and a Statically-Typed Object-Oriented Programming Language').!!!! advisor ('Prof. Kim Mens', 'UCL', 'Belgium').!!! chairman('Prof. Charles Pecheur','UCL', 'Belgium').!!! jury ('Prof. Anthony Cleve', 'UNamur', 'Belgium').!!! jury ('Prof. Paul Tarau', 'University of North Texas',! 'USA').!!! jury ('Dr. Jan Wielemaker', 'Vrije Universiteit Amsterdam', !! ! 'The Netherlands').!! !:- end_object.!
2
:- object(content).!!! section(1, 'Motivation').!!! section(2, 'An Integration Framework Architecture').!!! section(3, 'Context-Dependent Inter-Language Conversions').!!! section(4, 'Integration from the OO Language Perspective').!!! section(5, 'Integration from the Logic Language Perspective').!!! section(6, 'Conclusions and Future Work').!!:- end_object.!
3
Subliminal message!A logic program is extremely
intuitive to understand
Motivation
4
?- content::section(Part,Desc).!Part = 1,!Desc = 'Motivation';
5
Enabling the Interaction between the Inhabitants of Different Worlds
6
Enabling the Interaction between the Inhabitants of Different Worlds
A smooth interaction is often difficult to accomplish.
7
!Classes!
Packages!Objects!Fields!
Methods!Return values!
!
!Modules!Terms!Facts!Rules!
Queries!Query solutions!
!
The OO world The Logic world
Enabling the Interaction between the Inhabitants of Different Worlds
Object-Oriented vs Logic Programming
OOP!
The decomposition of a system is based upon the notion of objects.
8
LP!
A program is conceived as a logic theory.
class Person {!!! String name;!!! double temperature;!!! boolean hasFever() {!! ! return temperature>38;!! }!!}
person(peter).!!temperature(peter,39).!!has_fever(X) :- person(X),! temperature(X,N),! N>38.
Classes model a family of objects Facts
Rule
}
Object-Oriented and Logic Languages are equivalent in power.
9
They both have the expressive power of a Turing Machine.
10
Appropriate for modelling real-world concepts
Rich general-purpose software ecosystem
[⊨]
Logic programming software ecosystem
Declarative reasoning, knowledge-intensive systems
OO programming
Logic programming
But they are not equivalent in their ease of expression.
11
OO programming
Logic programming
+
Multi-Paradigm programming
12
OO programming
Logic programming
+
Multi-Paradigm programming
Multi-Paradigm Programming
13
Multi-Paradigm programming
languages
Inter-Operability approachesvs.
- Only one (complex) language is required.
- A mature software ecosystem is not always available.
!
- Distinct languages belonging to different paradigms.
- Complex mapping of concepts. - Reuse of existing software
ecosystems. !
Both present advantages and limitations
A Hybrid System Example
14
<osm version="0.6" generator="CGImap 0.0.2">
<bounds minlat="50.8319000" minlon="4.3355000" maxlat="50.8599000" maxlon="4.3708000"/>
<node id="145324" lat="50.8468554" lon="4.3624415" user="BenoitL" uid ="101145" visible="true" version="18" changeset="7864502" timestamp="2011-04-14T20:01:32Z">
<tag k="highway" v="traffic_signals"/>
</node>
...
</osm>
Pre-processing raw data (e.g., converting it
into a logic theory).
Logic LanguageOO Language OO Language
Querying, analysing and/or transforming
the data.
Post-processing the data (e.g.,
displaying it, distributing query results, etc.).
Related Work
15
Eval
uatin
g O
O e
xpre
ssio
ns
from
the
logi
c la
ngua
ge
Com
plex
que
ries
from
th
e O
O la
ngua
ge
OO
to L
ogic
lang
uage
Logi
c to
OO
lang
uage
Obl
ivio
usne
ss fr
om th
e Lo
gic
lang
uage
Obl
ivio
usne
ss fr
om th
e O
O la
ngua
ge
Shar
ing
unbo
und
logi
c va
riabl
es
Shar
ing
obje
ct s
tate
Non
-det
erm
inis
m s
uppo
rt
Invo
king
OO
met
hods
fro
m th
e Lo
gic
lang
uage
Que
ryin
g pr
edic
ates
from
th
e O
O la
ngua
ge
Mul
tiple
Log
ic e
ngin
es
Mul
tiple
OO
env
ironm
ents
Porta
bilit
y
Cus
tom
isab
ility
16
Related Work
Related Work
17
Obliviousness from the logic perspective Obliviousness from
the OO perspective
Obliviousness
Common Inter-Operability Problems
18
Explicit boilerplate integration code
Integration-code tangled with the main
programming concern
“Let us make a special effort to stop communicating with each other, so we can have some conversation.”
—Mark Twain
19
Oblivious Integration
20
Objects from different worlds must understand each other without effort. (e.g., invoking routines from the foreign language as if they were defined
in the native language).
Oblivious integration is already complex to achieve if the languages belong to the same paradigm
21
Integrating Same-Paradigm Languages
A Paradigm Mismatch
22
… but it is even harder if some concepts in one language do not straightforwardly match in the other.
Limitations of Oblivious Integration Approaches between OO and Logic Languages
23
Strong architectural assumptions (e.g., assuming the logic
program runs embedded in the OO programming environment).
Lack of customisability (e.g., difficult to switch between
integration policies).
Compromises portability.
Compromises applicability.
Proposed Approach
Oblivious language integration as a portable and customisable language-interoperability technique for achieving multi-paradigm programming.
24
VisionTo provide a conceptual framework and its corresponding implementation that simplifies the creation of hybrid systems composed of both logic and statically-typed object-oriented code.
25
… or declaratively specified
Integration aspects should be
automatically inferred
Why a Statically-Typed Language?
26
The additional type data provided by statically-typed languages makes them more amenable to integration techniques based on static analysis.
An Integration Framework Architecture
27
?- content::section(Part,Desc).!Part = 2,!Desc = 'An Integration Framework Architecture';
Java and Prolog as our Target Languages
28
[⊨]
Java guarantees portability and deployability
Prolog facilitates the exploitation of decades of
research in logic programming
Abstract architectural view
29
PVM
JVM
JVM abstraction
Drivers
PVM abstraction
Java program
Prolog integrationframework
Prolog program
Java integrationframework
Abstract architectural view
30
PVM
JVM
JVM abstraction
Drivers
PVM abstraction
Java program
Prolog integrationframework
Prolog program
Java integrationframework
Abstract architectural view
31
PVM
JVM
JVM abstraction
Drivers
PVM abstraction
Java program
Prolog integrationframework
Prolog program
Java integrationframework
The Inhabitants of Our Two Worlds
32
!Classes!
Packages!Objects!Fields!
Methods!Return values!
! The OO world
The Logic world
!Modules!Terms!Facts!Rules!
Queries!Query solutions!
!
33
The Logic world
An OO layer
Reducing the Paradigm Mismatch
34
LogtalkAn Object-Oriented Layer
PrototypesClasses
Methods
Inheritance
Protocols
Categories
Encapsulation
TermsFactsRules
QueriesQuery Solutions
The Logic World
Reducing the Paradigm Mismatch with Logtalk
35
Concrete architectural view
PVM
Logtalk
JVM
JPC
JPC Drivers
JPC
Java program
LogicObjects
Prolog/Logtalk program
LogicObjects
36
Abstract architectural view
PVM
JVM
JVM abstraction
Drivers
PVM abstraction
Java program
Prolog integrationframework
Prolog program
Java integrationframework
Concrete architectural view
PVM
Logtalk
JVM
JPC
JPC Drivers
JPC
Java program
LogicObjects
Prolog/Logtalk program
LogicObjects
LogicObjects
37
Transparent integration by means of (semi-) automatic
mappings between artefacts.
Relies on advanced reflection techniques (e.g., runtime code
generation and byte-code instrumentation).
PVM
Logtalk
JVM
JPC
JPC Drivers
JPC
Java program
LogicObjects
Prolog/Logtalk program
LogicObjects
Java-Prolog Connectivity (JPC)
38
Abstracts a Prolog VM in the Java world and a Java VM in the
Prolog world.
Framework for context-dependent inter-language
conversion of artefacts.
PVM
Logtalk
JVM
JPC
JPC Drivers
JPC
Java program
LogicObjects
Prolog/Logtalk program
LogicObjects
JPC Drivers
39
PVM
Logtalk
JVM
JPC
JPC Drivers
JPC
Java program
LogicObjects
Prolog/Logtalk program
LogicObjects
Concrete Prolog engines
Engine-specific drivers
JPLPDT InterProlog
SWI XSBYAP
Context-Dependent Inter-Language Conversions
40
?- content::section(Part,Desc).!Part = 3,!Desc = 'Context-Dependent Inter-Language Conversions';
To provide a customisable framework for the inter-language conversion of artefacts.
41
GoalJava world
Prolog world
Objects !(e.g., a String)!
and primitive types!(e.g., an int, float, char, etc.)
compound!(e.g., student(‘name’))
atom!(e.g., ‘hello’)
integer!(e.g., 4)
float!(e.g., 4.0)
variable!(e.g., Var)
Context Matters
42
Context Matters
43
The right conversion is often context-dependent
new Person(“name”)
person(‘name’)
‘name’
context A
context B
Java world
Prolog world
The Conversion Context
44
A conversion context encapsulates a bi-directional
conversion policy.
JPC //default context builder JpcBuilder builder = JpcBuilder.create(); !//default conversion context Jpc jpc = builder.build();
Pre-Defined Catalog of Converters
45
String helloString = jpc.fromTerm(new Atom(“hello”)); Atom helloAtom = jpc.toTerm(helloString); boolean bool = jpc.fromTerm(new Atom(“true”)); Atom trueAtom = jpc.toTerm(bool);
JPC pre-defines a default catalog of converters (primitives, multi-valued, exceptions, etc).
Some primitive conversions:
Type-Guided Conversions
46
String trueString = jpc.fromTerm(new Atom(“true”), String.class); int i = jpc.fromTerm(new Atom(“1”), int.class); Atom atom = jpc.toTerm(i, Atom.class);
the atom ‘true’ should not be interpreted as a boolean, but as a string
the atom ‘1’ should not be interpreted as a string, but as an int
the int 1 should not be interpreted as an integer term,
but as an atom
Defining Custom Converters
47
public class StationConverter implements ToTermConverter <Station , Compound>, FromTermConverter <Compound , Station > { public static final String STATION_FUNCTOR = "station"; ! @Override public Compound toTerm(Station station, Class<Compound> termClass, Jpc context) { return new Compound(STATION_FUNCTOR , asList(new Atom(station.getName()))); } ! @Override public Station fromTerm(Compound term, Type type, Jpc context) { String stationName = ((Atom)term.arg(1)).getName(); return new Station(stationName); } }
Registering Converters
48
//custom context builder JpcBuilder builder = JbcBuilder.create().register(new StationConverter()); !//custom conversion context Jpc jpc = builder.build();
registering the custom converter StationConverter
Registering Converters for Specific Terms
49
//custom context builder JpcBuilder builder = JbcBuilder.create(); !//targetTerm = hello(_) Term targetTerm = new Compound(“hello”, asList(Var.ANONYMOUS_VAR)); !builder.register(new HelloConverter(), targetTerm); !//custom conversion context Jpc jpc = builder.build();
registering the HelloConverter as able to convert terms
of the form hello(_)
A Categorisation of Converters
50
Cat
Any
Animal
Object
converter =AnimalConverter
<Animal,Compound>
HasLegsFurry
Fish
FourLegged
converter = HasLegsConverter
<HasLegs,Compound>
Resolving Converters by Means of Linearisation
51
converter = HasLegsConverter
<HasLegs,Compound>
converter =AnimalConverter
<Animal,Compound>
Fish
FourLegged
Cat
Any
Animal
Object HasLegsFurry
Integration from the OO Language Perspective
52
?- content::section(Part,Desc).!Part = 4,!Desc = 'Integration from the OO Language Perspective';
53
Case Study I!The London Underground
Relevant Concepts
54
stations
linesmetro
Nearby: At most one intermediate station,! in the same line (e.g., A with C).
Interesting Relations
55
line1A C
line2
D
F
B
Connected: Directly connected (e.g., A with B).!
Reachable: Transitively connected (e.g., A with F).
connected nearbyreachable
Interesting Relations
56
Easily expressed with logic facts and rules
Nearby: At most one intermediate station,! in the same line (e.g., A with C).
Connected: Directly connected (e.g., A with B).!
Reachable: Transitively connected (e.g., A with F).
A Rule Based System Using Prolog
57
!! ! connected(station(bond_street), station(oxford_circus), line(central)). connected(station(oxford_circus), station(tottenham_court_road), line(central)). ... ! nearby(S1,S2) :- connected(S1,S2,_). nearby(S1,S2) :- connected(S1,S3,L), connected(S3,S2,L).! reachable(S1,S2,[]) :- connected(S1,S2,_). reachable(S1,S2,[S3|Ss]) :- connected(S1,S3,_), reachable(S3,S2,Ss).! line(Name) :- setof(L, S1^S2^connected(S1,S2,L), Ls), list::member(line(Name), Ls).
FACTS
RULES
Adding an OO Layer with Logtalk
58
!! ! connected(station(bond_street), station(oxford_circus), line(central)). connected(station(oxford_circus), station(tottenham_court_road), line(central)). ... ! nearby(S1,S2) :- connected(S1,S2,_). nearby(S1,S2) :- connected(S1,S3,L), connected(S3,S2,L).! reachable(S1,S2,[]) :- connected(S1,S2,_). reachable(S1,S2,[S3|Ss]) :- connected(S1,S3,_), reachable(S3,S2,Ss).! line(Name) :- setof(L, S1^S2^connected(S1,S2,L), Ls), list::member(line(Name), Ls).
:- object(metro).
:- end_object.
:- public([connected/3, nearby/2, reachable/3, line/1]). ACCESS MODIFIERS
Logtalk Parametric Objects
59
:- object(line(_Name)).! :- public([name/1, connects/2]). name(Name) :- parameter(1, Name). ... !:- end_object.!!:- object(station(_Name)).! :- public([name/1, connected/2, nearby/1, reachable/2]). name(Name) :- parameter(1, Name). ... !:- end_object.
PARAMETRIC OBJECT
PARAMETRIC OBJECT
Invoking a Logtalk Method
60
Messages in Logtalk are expressed with the :: operator.
For example:
line(central)::connects(Station1, Station2)!
Answers all the stations connected by the line ‘central’.
The Java World
61
!public abstract class Line { String name; public Line(String name) {this.name = name;} public abstract boolean connects(Station s1, Station s2); public abstract int segments(); }!!!public abstract class Station { ...}!!public abstract class Metro { ...}
Declarative Mapping by Means of Annotations
• @LObject: Map class instances to Logtalk objects.
• @LMethod: Map methods to Logtalk predicates.
• @LSolution: Map a single solution to a method return value.
• @LComposition: Maps a set of solutions to a method return value.
62
!!!!!!!metro!!!!!!!!!line(‘line_name’)
!!!!@LObject(name = "metro")public abstract class Metro {...}!Metro aMetro = …;!!!@LObject(name = "line", args = {"name"})public abstract class Line { private String name; ...}!Line aLine = …;!
Converting Java Objects to Prolog Terms
63
Java Prolog
Mapping Java Methods to Logtalk Methods
64
metro- line/1- connected/3- nearby/2- reachable/3
line/1- connects/2
station/1- connected/2- nearby/1- reachable/2
Line- boolean connects(Station s1, Station s2)- int segments()
Station- Station connected(Line l)- List<Station> nearby()- List<Station> intermediteStations(Station s)
The Java world The Logtalk world
Metro- List<Line> lines()- Line line(String s)
Default and Custom Mappings of Java Methods to Logtalk Methods
65
!!!!!!!line(lName)::connects( station(s1Name), station(s2Name)).!!line(lName)::connects(_, _).
@LObject(name = "line", args = {"name"})public abstract class Line { private String name;! public abstract boolean connects(Station s1, Station s2); @LMethod(name = "connects", args = {"_", "_"}) public abstract int segments(); }!!!
Java Prolog
anonymous variables
Interpreting a Query Solution as a Java Object
66
The logic solutions
Varx1 x1, Vary1 y1Varx2 x2, Vary2 y2
Varxn xn, Varyn yn(set of frames binding logic
variables to terms)
frame 1frame 2
frame n
Interpreting a Query Solution as a Java Object
67
The logic solutions The method return value
aJavaObject
Varx1 x1, Vary1 y1Varx2 x2, Vary2 y2
Varxn xn, Varyn yn(set of frames binding logic
variables to terms)
one solution?
all solutions?
a property of the result set?
Interpreting One Query Solution as a Java Object
68
The logic solutions The method return value
aJavaObjectVarx1 x1, Vary1 y1Varx2 x2, Vary2 y2
Varxn xn, Varyn yn(set of frames binding logic
variables to terms)
Interpreting One Query Solution as a Java Object
69
The logic solutions The method return value
termVarx1 x1, Vary1 y1Varx2 x2, Vary2 y2
Varxn xn, Varyn yn(set of frames binding logic
variables to terms)
aJavaObject
70
•Preprocessing macros.
•Convert arguments to terms.
•Convert method to a predicate.
•Convert receiver object to a term.
•Build a query.
•Determine solution heuristic.
•Convert solution terms back to objects.
station(b)::reachable(station(a), IStations)first Java method parameter
• $1 => station (method parameter).
• (station(a), IStations)
• intermediateStations => reachable/2.
• station(b)
• station(b)::reachable(station(a), IStations)
• Binding of IStations (first solution).
• [station(x), station(y)] => List<Station>
Processing Steps Outcome
!!@LObject(name = "station", args = {"name"})public abstract class Station {! @LSolution("IStations") @LMethod(name = "reachable", args = {"$1", "IStations"}) public abstract List<Station> intermediateStations(Station station); ...}
unbound Prolog variable
(as term)
(instance of)
Returning Multiple Values from Queries
71
!!
@LObject(name = “station”, args = {"name"})public abstract class Station { ... @LComposition @LSolution("S") @LMethod(args = {"S"}) public abstract List<Station> nearby();}
each solution type
container type
!!!!!station(aName)::nearby(S).!!
LogtalkJava
Returning a Property of the Result Set
72
The logic solutions The method return value
Varx1 x1, Vary1 y1Varx2 x2, Vary2 y2
Varxn xn, Varyn yn(set of frames binding logic
variables to terms)
(a property of the result set)
is there a solution ?
how many solutions ?}
Returning a Property of the Result Set
73
!!
@LObject(name = "line", args = {"name"})public abstract class Line { private String name;! public abstract boolean connects(Station s1, Station s2); @LMethod(name = "connects", args = {"_", "_"}) public abstract int segments(); }!!!
returns if the query succeeds or not
returns the number of solutions
Integration from the Logic Language Perspective
74
?- content::section(Part,Desc).!Part = 5,!Desc = 'Integration from the Logic Language Perspective';
Automatic Delegation to the Java World
75
Prolog
an_object
Java
jobject jpc anObject
logtalk_message
javaMessage
Any message not understood by an object importing the jobject category will be automatically delegated to the Java world.
:- object(an_object ,! imports(jobject)).!! ...!:- end_object.!
Mapping a Logtalk Method to a Java Method
76
an_object::message(arg1,… argN, return(ReturnSpecifier))
object.message(arg1,… argN)
Prolog worldJava world
return value
Return Specifiers
77
term(Result)
jref(Result)
strong(jref(Result))
weak(jref(Result))
soft(jref(Result))
strong(jref_term(Result))
weak(jref_term(Result))
soft(jref_term(Result))
serialized(Result)
Return specifiers denote how a method return value should be
interpreted and represented
Alternative Mechanisms to Capture the Return Value
78
an_object::message(arg1,… argN) return ReturnSpecifier.
jobject(Expression, ReturnSpecifier)::message(arg1,… argN)
As an argument of the receiver
Using the return operator
an_object::message(arg1,… argN, return(ReturnSpecifier))
As an argument of the method
79
(a,b)!(sequence)
‘java.lang.String’(‘hello’)!(constructor)
(x,y)::a!(broadcasting)
obj::method!(method call)
x::(a,b)!(cascading)
x::[a]!(accessors)
Terms reifying Java expressions
x::[a,v]!(mutators)
80
Case Study II!The MapQuery Application
Map Query Information Flow
81
Converting OSM raw data into a logic theory.
Displaying the queried data.
Querying geographical data.
PrologJava Java<osm version="0.6" generator="CGImap 0.0.2">
<bounds minlat="50.8319000" minlon="4.3355000" maxlat="50.8599000" maxlon="4.3708000"/>
<node id="145324" lat="50.8468554" lon="4.3624415" user="BenoitL" uid ="101145" visible="true" version="18" changeset="7864502" timestamp="2011-04-14T20:01:32Z">
<tag k="highway" v="traffic_signals"/>
</node>
...
</osm>
Relevant Entities
82
Coordinates!A place in a map
identified by a latitude and longitude.
Nodes!Points of
interest in the map having a coordinate.
Ways!Collections of nodes
(e.g.,streets).
Tags!Named
properties of nodes and ways.
Java Classes
83
MapBrowser
- void goTo(Coordinates)- void zoomTo(Integer)- void draw(Taggable)- void draw(List<Taggable>)…
Coordinates
- double getLon()- double getLat()
Node
- Long getId()…
Way
- Long getId()…
Taggable
- Map<String, String> getTags()
1*
Logtalk Objects
84Entities Diagram for the MapQuery Example
mapquery_lib
coordinates.lgt
taggable.lgt
osm.lgt
node.lgtway.lgt
(external entities)
coordinates(Lon,Lat)prototype
lon/1lat/1
distancekm/2distancem/2
near/2
taggable(Tags)category
tags/1tag/2
has_tags/1
listprototype
uses
osmprototype
node/3node/2node/1
number_nodes/1way/3way/2way/1
number_ways/1
uses
node(Id,Coordinates,Tags)prototype
id/1coordinates/1distancekm/2
near/2
imports
way(Id,Nodes,Tags)prototype
id/1nodes_ids/1nodes/1node/1
distancekm/2near/2
importsuses
uses
Navigating the Map Browser
85
class('…MapBrowserStage')::launch return weak(jref(Map))
Invoking the launch static method on the
MapBrowserStage class
Map unifies with a (weak) reference to the
map browser
Map::zoomTo(int(14)), !city(brussels)::coordinates(BRU), !Map::goTo(BRU)
Zooming-in the map
Obtaining the coordinates of
Brussels Moving the map to
Brussels
Drawing on the Map
86
osm::node(Node), !Node::has_tags([railway-station]), !Node::has_tags(['name:fr'-'Bruxelles -Central']), !Node::coordinates(Coordinates), !osm::way(Way), !Way::near(Coordinates , 0.1), !Map::draw([Node, Way]). !
Node is “Brussels
Central Station”
Coordinates are the coordinates of
the node
Way is a way within 100 meters from
the nodeDraw the Node and
Way
Drawing on the Map
87
osm::node(Node), !Node::has_tags([railway-station]), !Node::has_tags(['name:fr'-'Bruxelles -Central']), !Node::coordinates(Coordinates), !osm::way(Way), !Way::near(Coordinates , 0.1), !Map::draw([Node, Way]). !
MapBrowser
- void goTo(Coordinates)- void zoomTo(Integer)- void draw(Taggable)- void draw(List<Taggable>)…
88
Brussels Central Station
OSM “ways” close to the
station
Conclusions and Future Work
89
?- content::section(Part,Desc).!Part = 6,!Desc = 'Conclusions and Future Work';
Conclusions• We provide a conceptual model of a bidirectional oblivious integration
between a logic and a statically-typed OO language.
• Our model was instantiated for Java and Prolog.
• Static-type analysis was used to infer in certain cases the best integration strategy.
• Strong focus on portability: our libraries are not constrained to a specific execution environment on the Java-side (e.g., an IDE plugin) or Prolog-side (e.g., requiring an embedded logic engine).
• Compatible with several open-source Prolog engines by means of drivers.
• Our implementation is, and will remain, open-source software.
90
Supporting Publications• Automatic Integration of Hybrid Java-Prolog Entities with LogicObjects.
Sergio Castro, Kim Mens and Paulo Moura. To appear in the Association for Logic Programming (ALP) Newsletter. Out of Left Field track. September Issue. 2014.
• JPC: A Library for Categorising and Applying Inter-Language Conversions Between Java and Prolog.Sergio Castro, Kim Mens and Paulo Moura. Submitted to Science of Computer Programming: Experimental Software and Toolkits (EST 6).
• Customisable Handling of Java References in Prolog Programs.Sergio Castro, Kim Mens and Paulo Moura. Proceedings of the International Conference on Logic Programming (ICLP 2014).
• LogicObjects: A Portable and Extensible Approach for Linguistic Symbiosis between an Object-Oriented and a Logic Programming Language.Sergio Castro. Proceedings of the International Conference on Logic Programming, Doctoral Consortium (ICLP DC 2013).
• LogicObjects: Enabling Logic Programming in Java through Linguistic Symbiosis.Sergio Castro, Kim Mens and Paulo Moura. Proceedings of the 15th International Symposium on Practical Aspects of Declarative Languages (PADL 2013).
• LogicObjects : A Linguistic Symbiosis Approach to Bring the Declarative Power of Prolog to Java.Sergio Castro, Kim Mens and Paulo Moura. Proceedings of the 9th ECOOP Workshop on Reflection, AOP, and Meta-Data for Software Evolution (RAM-SE 2012).
91
Supporting Research Artefacts!• Java–Prolog Connectivity (JPC).
A Java-Prolog integration library inspired by Google’s Gson. http://java-prolog-connectivity. github.com/.
• LogicObjects.A linguistic integration framework for Java and Prolog. https://github.com/java-prolog-connectivity/logicobjects/.
• JConverter.A Java framework to encapsulate, categorise and apply type-guided conversions between objects. http://jconverter. github.com/.
• JGum.A lightweight categorisation framework for Java. http://jgum. github.com/.
92
https://github.com/sergio-castro/ Follow/fork me at
“Talking is cheap. Show me the code.” — Linus Torvalds
Future Work• Inter-language reflection support (reflecting Java
programs from Prolog).
• Refactoring, transforming, mining, analysing & querying tools for Java programs and other artefacts.
• Improving performance.
• Development of native drivers.
• Support for additional logic engines.
93
Thank you
94
These slides!http://www.slideshare.net/SergioCastro25/sergio-castro-
phdpublicdefense
PhD thesis!http://www.info.ucl.ac.be/~sergio/files/publications/2014-phd-
castro.pdf
Pointers
My website!http://www.info.ucl.ac.be/~sergio/