release is a
is being made available only to a few enthusiasts who don't mind the
likelihood that the API will change before 3.x becomes stable.
Java API: new Variable semantics
A Variable must be
created with a name, e.g.
or as an anonymous variable
or as a dont-tell-me variable
Each binding within a solution is now
indexed by the name of
its associated Variable, hence
New variables returned in bindings are
given new, sequential names, e.g. "_283".
Each Variable instance within
a Java application is just a lexical token in the alternative Prolog
concrete syntax which Term and
its subclasses comprise. Two instances of Variable("X") are no different
from one shared instance: you are free to reuse such lexical elements,
but this has nothing to do with the sharing of variables which can
occur within a Prolog engine.
The bindings of anonymous and dont-tell-me
variables (i.e. those whose names begin with an underscore character)
are not returned to Java: use them to avoid the computational time and
space costs of constructing Term
representations of bindings in which you are not interested.
Java API: easier Term and Query construction
Now that Variables
are named, and bindings are keyed by the names of variables, it is
easier to construct Term (and
hence Query) instances.
This utility (NB liable to be renamed or moved into a different class)
converts a valid Prolog source text representation of a term into a
corresponding Term hierarchy:
Term jpl.Util.textToTerm( String sourcetext)
A new (in JPL 3.0.0) Query
Query( String sourcetext)
allows queries to be created from source text, e.g.
and oneSolution(), allSolutions() and nextSolution() will return
bindings of N
(but not of the dont-tell-me
returns a jpl.Integer
representing the Prolog integer value to which N was bound by the successful
call of the query.
Java API: deprecated methods
Java API: fixes
array methods inherited from java.lang.Object are now callable,
which cutely displays any Term
in a Swing tree view in a new window.
support non-virtual method calls, e.g. by
jpl_call(+Obj, +Class:Method, +Args, -Result)
finish the current tidy-up
passing (or returning) Prolog terms to Java by reference; we
might stash them in Prolog's recorded
database (see PL_record
in the SWI-Prolog Reference Manual), and return an instance of some
yet-to-be-designed JPL class which erases the recorded term when the
referring object is garbage-collected
convenience constructs in Prolog akin to import in Java, allowing
us to write e.g.
jpl_new('Timestamp', X, R)
when we mean
jpl_new('javax.sql.Timestamp', X, R)
renaming the package jpl more
globally: unfortunately, org.jpl has
already been taken :-)
ditching jpl.Util and
moving its (static, utility) methods into jpl.JPL
deprecate all .args(),
.arg0(), .arg1() methods and replace with
public final Term args;
require any Variable's
name to conform to Prolog source syntax, so that valid source texts can
be reconstructed from Term
instances by the toString()