drt24 / gnuprologjava Goto Github PK

View Code? Open in Web Editor NEW

7.0 7.0 5.0 2.62 MB

GNU Prolog for Java

Shell 0.07% Java 76.41% Prolog 21.25% Makefile 0.01% HTML 2.27%

gnuprologjava's People

Contributors

Stargazers

Watchers

Forkers

rishabhgarg nbkn thetrime orbiter yyl-20020115

gnuprologjava's Issues

Is a compiled jar file for 0.3.1 released?

Hi,

Thanks. I got the latest release. However, I cannot build this project. I got the following error

Buildfile: /home/yuan2/gnuprologjava-0.3.1/build.xml

init:

compile:
    [javac] Compiling 243 source files to /home/yuan2/gnuprologjava-0.3.1/build/code
    [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.6
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParser.java:13: error: cannot find symbol
    [javac]   JavaCharStream stream;
    [javac]   ^
    [javac]   symbol:   class JavaCharStream
    [javac]   location: class TermParser
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParser.java:140: error: cannot find symbol
    [javac]   public TermParser(JavaCharStream str, Environment env)
    [javac]                     ^
    [javac]   symbol:   class JavaCharStream
    [javac]   location: class TermParser
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParser.java:151: error: cannot find symbol
    [javac]   public TermParser(JavaCharStream stream)
    [javac]                     ^
    [javac]   symbol:   class JavaCharStream
    [javac]   location: class TermParser
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParserTokenManager.java:10: error: package ognl does not exist
    [javac] import ognl.JavaCharStream;
    [javac]            ^
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParser.java:816: error: cannot find symbol
    [javac]   JavaCharStream jj_input_stream;
    [javac]   ^
    [javac]   symbol:   class JavaCharStream
    [javac]   location: class TermParser
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParserTokenManager.java:1391: error: cannot find symbol
    [javac]     public TermParserTokenManager(JavaCharStream stream){
    [javac]                                   ^
    [javac]   symbol:   class JavaCharStream
    [javac]   location: class TermParserTokenManager
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParserTokenManager.java:1400: error: cannot find symbol
    [javac]   public TermParserTokenManager (JavaCharStream stream, int lexState){
    [javac]                                  ^
    [javac]   symbol:   class JavaCharStream
    [javac]   location: class TermParserTokenManager
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParserTokenManager.java:1406: error: cannot find symbol
    [javac]   public void ReInit(JavaCharStream stream)
    [javac]                      ^
    [javac]   symbol:   class JavaCharStream
    [javac]   location: class TermParserTokenManager
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParserTokenManager.java:1423: error: cannot find symbol
    [javac]   public void ReInit(JavaCharStream stream, int lexState)
    [javac]                      ^
    [javac]   symbol:   class JavaCharStream
    [javac]   location: class TermParserTokenManager
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParserTokenManager.java:1451: error: cannot find symbol
    [javac]     protected JavaCharStream  input_stream;
    [javac]               ^
    [javac]   symbol:   class JavaCharStream
    [javac]   location: class TermParserTokenManager
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParser.java:137: error: cannot find symbol
    [javac]     this(new JavaCharStream(r, line, col), environment);
    [javac]              ^
    [javac]   symbol:   class JavaCharStream
    [javac]   location: class TermParser
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParser.java:854: error: reference to TermParser is ambiguous
    [javac]      this(stream, null);
    [javac]      ^
    [javac]   both constructor TermParser(JavaCharStream,Environment) in TermParser and constructor TermParser(InputStream,String) in TermParser match
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParser.java:858: error: cannot find symbol
    [javac]     try { jj_input_stream = new JavaCharStream(stream, encoding, 1, 1); } catch(java.io.UnsupportedEncodingException e) { throw new RuntimeException(e); }
    [javac]                                 ^
    [javac]   symbol:   class JavaCharStream
    [javac]   location: class TermParser
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParser.java:884: error: cannot find symbol
    [javac]     jj_input_stream = new JavaCharStream(stream, 1, 1);
    [javac]                           ^
    [javac]   symbol:   class JavaCharStream
    [javac]   location: class TermParser
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParserTokenManager.java:1393: error: cannot find symbol
    [javac]       if (JavaCharStream.staticFlag)
    [javac]           ^
    [javac]   symbol:   variable JavaCharStream
    [javac]   location: class TermParserTokenManager
    [javac] /home/yuan2/gnuprologjava-0.3.1/src/gnu/prolog/io/parser/gen/TermParserTokenManager.java:1393: error: illegal start of type
    [javac]       if (JavaCharStream.staticFlag)
    [javac]          ^
    [javac] 16 errors
    [javac] 1 warning

BUILD FAILED
/home/yuan2/gnuprologjava-0.3.1/build.xml:103: Compile failed; see the compiler error output for details.

{} is not parsed as an atom

A simple test case of

   x({}).

produces a compile error. This is a legal atom according to the ISO standard (specifically section 6.3.1.3)

Provide a mechanism for extending AtomicTerm

Currently TermWriter will only print terms it knows about. If you extend AtomicTerm yourself to provide something more exotic, it will never be printed.

I suggest that AtomicTerm gets an empty method
public void displayTerm(WriteOptions o, TermWriter writer)
which can be used by TermWriter to print terms it doesn't implicitly know about

member(X, <anything which is not a list>) raises an ArrayIndexOutofBounds exception, but instead should fail

The ISO standard seems to imply that member/2 should be defined as if
```
member(X, [X|]).
member(X, [|Y]):-member(X,Y).

(and indeed, Predicate_member.java includes this in the javadoc). However, the implementation assumes that the second argument of a list cell is either an emptyListAtom or another list. While this /should/ be the case, we should cater for the case where it is not

Parser fails to parse "00" as a number

There is special handling for "0.*" in (amongst other places) BigIntegerTerm, but it fails to take into account that people might try and parse "01" or "04"

TermWriter writes \== as '\==' because isGraphicsChar is false for backslash

The ISO standard says that graphics-token-char is graphic-char OR backslash-char. Since we don't distinguish, I think isGraphicsChar should return true for '\'

TermWriter thinks the empty list needs to be quoted

I'm pretty sure that [] is always safe to write. In some systems, [] is not necessarily equal to '[]'

Now that we have modules, implement meta_predicate directive

To see why this is necessary, consider the following:

:-module(a, []).

foo:-
   findall(X, some_goal(X), Xs, []).

some_goal(a).
some_goal(b).

Suppose that findall/4 (a variation on findall/3 where the last two args are a difference list) is defined, rather hurriedly, in module(b):

:-module(b, [findall/4]).

findall(A,B,C,D):-
   findall(A,B,T),
   another_goal,
   append(C, D, T).

When we first call findall/4 from module(a), we compile a linking shim like this:

a:findall(A,B,C,D):- b:findall(A,B,C,D).

But when we execute this, we get the exception that some_goal/1 is not defined, since we're looking for it in module(b). If we don't change the context to b when executing code exported from b, then findall/4 will complain it cannot find another_goal/0. In other words, logically we have to be able to tell the compiler that what we really want is this:

a:findall(A,B,C,D):- b:findall(A,a:B,C,D).

The way this works in SWI-Prolog, YAP, SICStus and Quintus is to use a declaration like (the specifics vary by system)

:-meta_predicate(findall(?, 0, -, ?)).

X is sign(0) binds X to 1, not 0

Javadoc creation reports a vast number of warnings (and 7 errors)

It may not be possible to do much about this since it seems the errors are primarily in code generated by javacc, but it might still bear investigating

Not all test cases pass

A few of the test cases currently distributed do not pass due to unimplemented features or unfixed bugs. It'd be nice to clean these up - either disabling the tests and raising issues to fix the bugs/implement the missing functionality, or better still by fixing the bugs/implementing the missing functionality directly

Predicate_is_proper_list does not dereference the tail when iterating through the list

This can lead to failures when one of the elements in the list is a bound variable

:/2 attempts to reuse a backtrack point

If a call to :/2 succeeds nondeterministically more than twice, the second time the backtrack point pushed is reused from the first time. Backtracking over this a third time causes a NullPointerException

Jumps limited to 16-bit

GNU Prolog for Java is limited to 16-bit pointers in the VM. For example, the retry-me-else opcode has a maximum argument of 65535. If you create a predicate with a lot of complicated clauses, this can easily be exhausted, and you end up with pointer truncation, and ultimately undefined behaviour.

CompoundTerm.toCollection() always returns false

bea6823 refactored this to be significantly more efficient, but unfortunately changed the final check to see that the list item was listAtom, and not emptyListAtom. This means the only list that will correctly parse is of the form [a,b,c|'.']

The list itself is formed correctly, but tests should take the return value into account

Update debian packaging for the junit dependencies for testing

Will need to ensure we don't embed the jars in the debian package and that we do include them as build dependencies.