JPL release notes



JPL 3.0.3 Release Notes

Changes within the distribution

Java API changes

new Query("statistics")
and allows arbitrarily complex goals to be created textually, e.g.
new Query("setof(_A,current_atom(_A),_As),length(_As,N)")
NB _A and _As are dont-tell-me variables (this property is determined by their initial underscore), whose bindings are by default not returned when the query is called (saving computational time and space).  This behaviour can be overridden (globally) with
jpl.JPL.setDTMMode( false)
to allow Java+JPL+Prolog implementation of a Prolog IDE which emulates the behaviour of the traditional top-level interpreter. 
"setof(P,mypred(?,P,?),Ps), length(Ps,?)"
and the args comprise as many terms as there are questionmarks, then the new query's goal is a rewriting of text's term, with each questionmark replaced by the corresponding element of args.  This is designed to mimic the established and useful idiom of passing parameters into SQL prepared statements.  It allows all the constant parts of a parameterised query to be defined textually.

Paul Singleton
Friday12th March 2004
 

JPL 3.0.2 Release Notes

Changes within the distribution

C library changes:

Java API changes


Paul Singleton
Sunday 22nd February 2004
 

JPL 3.0.0 Release Notes

This release is a work-in-progress, and 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.
new Variable("X")
or as an anonymous variable
new Variable("_")
or as a dont-tell-me variable
new Variable("_Q")
Each binding within a solution is now indexed by the name of its associated Variable, hence
solution.get("X")
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 constructor
Query( String sourcetext)
allows queries to be created from source text, e.g.
new Query("findall(_A,current_atom(_A),_As),length(_As,N)")
and oneSolution(), allSolutions() and nextSolution() will return bindings of N (but not of the dont-tell-me variables _A and _As), e.g.
q.oneSolution().get("N")
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

use Query.hasSolution() instead
use Query.close() instead

Java API: fixes

array methods inherited from java.lang.Object are now callable, e.g.

Java API: planned or under consideration

jpl_call(+Obj, +Class:Method, +Args, -Result)
jpl_new('Timestamp', X, R)
when we mean
jpl_new('javax.sql.Timestamp', X, R)
public final Term[] args;
Paul Singleton
Wednesday 4th February 2004
 

JPL 2.0.2 Release Notes

Java API: canonical representation of terms

rationale

"List" and "Tuple" terms are not recognised as distinct types by the Prolog engine: they are just conventions: it doesn't follow that every ./2 or []/0 should be represented externally as instances of List or Nil, nor that {}/2 should be represented as Tuple.  There are many other informal types, and it's not clear which of them deserve the same treatment.  The simplest policy is to provide special support for none of them, and this is what JPL 2.x.x does.  This also ensures that there is only one valid representation of a Prolog term as JPL class instances (otherwise we would have to be careful to recognise every Atom whose name is "[]" as being equivalent to an instance of Nil).

 Java API: lazy initialisation

It is no longer necessary to explicitly initialise JPL before calling any of the methods which access the Prolog engine.  This allows you to develop Java classes which make use of JPL, and to make them available as "library" classes for use freely in applications, without placing a burden upon the application programmer to explicitly initialise JPL.

Instead, JPL (and, if necessary, the Prolog engine) is initialised "lazily", at the first attempt to invoke the Prolog engine.  At this point, a "default" sequence of initialisation parameters is used: initial values for these are compiled into JPL, but they can be redefined at any time up until initialisation occurs.

It is also possible for Java applications to discover (as a String[]) exactly what sequence of JPL initialisation parameters were actually used (this call returns null if Prolog is not yet initialised, and can thus be used as a test of this state).

If a Java application needs to use Prolog with, say, a larger than normal heap or stack, it should attempt to redefine the default initialisation parameters, and hope that the Prolog engine is not yet initialised (if it is, there's not much it can do about it) (in newer versions of SWI-Prolog it could restart it, but this is rather drastic, might disrupt other activities, and is not yet supported via JPL).

Finally, the JPL 1.0.1 static jpl.JPL.init() method is still supported, for backwards compatibility.

These changes are not only for convenience, and to allow development of easy-to-use library code, but are part of a plan to combine Fred Dushin's  Java-calls-Prolog interface with Paul Singleton's Prolog-calls-Java interface, to support hybrid Prolog+Java application programming in which either

Java API: miscellaneous changes

Java API: bug fixes

Only one "bug" has been fixed, and this was already flagged by Fred as an issue: it concerns the conversion, from Prolog into JPL, of terms which contain shared variables (i.e. several instances of the same variable).  Transput of any (non-cyclic) term from Prolog into Java and back, using JPL, should yield a new term which is identical to the original apart from having all new variables (but in a similar pattern of sharing).

Paul Singleton
drafted Tuesday 20th February 2001
revised Thursday 19th April 2001