#### detailed information following

1. design ideas

1.1 package structure

com.meyling.principia
 some "main" programs that could be called directly

com.meyling.principia.module:
 starting point of all module handling business

com.meyling.principia.argument
 defines and implements the idea of argument lists containing
 atoms and/or other argument lists (lisp like)
 has (basic) pattern matching methods

com.meyling.principia.logic.paragraph
 here are objects like "Axiom"s, "Sentence"s, "ProofLine"s,
 
com.meyling.principia.logic.basic
 the basic logic operators

com.meyling.principia.logic.rules
 the logical rules that could be used

 #####


1.2 Argument

The Argument interface introduces lisp like trees with some 
pattern matching operations. There are currently two kinds of
Atoms: Text and Counter. Additionally every list has a
certain type, which restricts its possible elements.
If you write the type a list before the list you could get 
for example: 

IMPL(OR(PROP(1), PROP(2)), PROP(1))

It is a list of type IMPL that has the following two elements:
OR(PROP(1), PROP(2))
PROP(1)
The first element is a list that contains two elements:
PROP(1) and PROP(2). Each of these lists contains one Atom,
the Counter 1 and the Counter 2  respectively.
A list has certain attributes. First there is it's type.
In our example we start with a list of the type IMPL.
There is also the elements of that list. Each element is
a list itself or an atom. Both occurences are called
Argument. From every Argument you could say how many 
and which elements (Arguments) build it up. 


 #####


1.3 creators

creators are in every package which has
implementations of the Argument interface. 
They are simular constructed, but may only use the Argument
to String mapping of other creators.
A creator could create any of these classes by different
(static) methods. One import one is by an input stream (here:
TextInput). This is the deseralization of an Argument.
The seralization job could also be done by a creator.
(The  ModuleCreator is a little bit different, but look at the 
SimpleModuleCreator.)
One could easily replace an creator by another that 
operates on XML files. That's just another serealization form
There should be a creator for every package to be independent
of other packages (at least as much independent as possible).
So it would be possible to change the packages independenty.


1.4 tests

every package should have a PackageTest (basic and module
have one). Every package should be tested by starting this 
test. In package basic there is also a JUnit test 
TestConjunction for the class Conjunction. But this unit 
test tests more than Conjunction, other classes are needed
to perform the tests. So the whole(?) pattern matching stuff 
is also tested.
Perhaps the goal should be the following:
- every package has a TestSuite
- any TestSuite calls the TestSuites of packages below
- for an iteration test the topmost TestSuite is called, so
  that every test is run


2. flaws & problems

methods of a class in a package must use the correct 
Creator to get the correct answer for an getName()
call for an error message. If the call is send to the wrong
creator an error occurs - but if the call itself is only
made if an error occurs, we have a problem to find such
errors in advance.

Different creators have much in common, but that is 
formaly reflected. (Problem: static methods.)

LinkReference is in package rule and not in paragraph. (There 
were also some technical reasons for that, but i don't remember 
them). Nevertheless it should change its location.

Creators for every package? That gives dependence problems.
Perhaps there should be a common CreatorContext and where every 
Creator could be added to. And this common CreatorContext could
also be used to get information (e.g. the tag name)
about classes from other packages.

The checking mechanism is very tricky (Historical reasons). 
There must be another (simpler) solution for that problem.
Main design idea was a creation without back references -
that means that a child dosn't know its parents. I would
like to stick to that idea because ####
But the checking process must be a little bit more transparent...


Methods like getArgument() should only be used in basic 
operations. It is much better to use explicit methods like
proposition.getProof() instead of proposition.getArgument(1).
No casting, better for maintenance and far more object oriented.
This should be a general rule: no casting and no instanceof
questions...


####