-
Notifications
You must be signed in to change notification settings - Fork 2
/
TODO
111 lines (72 loc) · 3.59 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
These should be added to the GForge site of the project. :)
================================================================================
Place holders could contain a number.
Term <-> Object conversions
---------------------------
Almost complete but should be reviewed. Much more test cases needed.
Always the converter assigned to Object[].class is used for converting arrays.
This is not ideal. (Arrays of interfaces or primitive types should be handled
specially as well.)
================================================================================
Alternative implementations
---------------------------
Alternative implementations should be developed for CIAO Prolog, SWI-Prolog and
so on.
Not of high priority.
================================================================================
JUnit tests
-----------
Much more tests needed. Cobertura may help to find the weaknesses.
Scheduled for 0.2.0
================================================================================
Prolog4J site
-------------
Overview, tutorial, FAQ, etc.
Downloads.
Scheduled for 0.2.0
================================================================================
Annotation framework
--------------------
The annotation framework provides simple annotations for defining Java
interfaces for goals. Such an interface is a method annotated by @Goal. The
formal arguments and the return type of the method can be annotated by @In,
@Out, @InOut and @NonNull.
Annotations can be used for static type checking and code generation as well.
See below.
================================================================================
Static type checking
--------------------
The checks which can be performed:
- check the "format string" against the argument types.
- check the requested variable name (if specified by a literal) against the
expected type.
e.g. aGoalMethod().<String>on("X")
- ???
================================================================================
Generating goal method body
---------------------------
Goal methods contain only the invocation of the prover. Normally the prover
associated to the class is to be used, however, the name of the prover should be
able to be specified as the argument of @Goal.
It should be possible to use a quasi empty method body (e.g. throw null;). In
this case, the invocation of the Prover can be generated at compile time if the
Sun Java compiler is used. If not, the body can be generated at load time.
The preferred way is to generate them at load-time by a Java agent.
================================================================================
Theories
--------
Theories can be specified by the @Thery specification on types or packages. The
theory will be added to the prover associated to that type or package, respecti-
vely. Theories should be loaded automatically. The code that adds the theory to
the appropriate prover can be generated at compile-time if the Sun Java compiler
is used. If not, the theory can be added to the prover at load-time.
The preferred way of loading theories is to load them at the load-time of the
class or package by a Java agent.
================================================================================
Terms
-----
Term classes can be specified by @Term. The instances of term classes should be
able to be converted to terms automatically. The way of this should still be
elaborated. Similarly, if the functor of a compound term equals the name of a
term class (or the argument of @Term) then the term will be converted to an
instance of the class. Also, the way of this should be elaborated.