(* SML 93 VERSION *)

(* New implementation of Mark2 theorem prover *)
(* now officially called "Watson" *)

(* copyright M. Randall Holmes, 2000 -- you may freely distribute as long
as this notice is preserved *)

(* at this point, all commands should be documented in babydocs *)

(* August 31:

error messages now raise a flag which prevents proofs; this flag
is reset by the start command (and by derived commands like startover,
starthere).

This is a seemingly minor feature which should protect one against
the effects of overeager drag-and-drop proofs (since these carry on
through error messages without stopping).

It seems that only the prove command needs to look at this flag, and
it is sufficient to have the start family of commands set it.  Experience
will tell us whether it is too finicky!  It does mean that proofs by
hand will need to be started over whenever an error message is raised.
I added a clearerrorflag() user command which will also clear the
error flag.

Another improvement:  files with the iri "theorem";; format
for talking to the INPUT command now work as scripts. But
the format is still quite rigid:  the iri lines need to appear
one to a line with no intervening commands.  So scripts are
still much more limited than top-level dialogue at the INPUT
prompt.  Still, this makes it easier to edit interactively developed
INPUT files to scripts.

*)

(* August 22:

THINGS TO DO (no code changes):

Another idea:  make it so that iri "<term>"; works in scripts
by having the INPUT reader extract whatever is between quotes
in the line read?

Re modularity:  think about reintroducing the ability to
hide subtactics inside tactics, and further consider having
the ability to specify which theorems a theory "exports"
to other theories (and abandon/forget all others when leaving
the theory -- subtactics needed but not exported automatically
hidden?).  Also, think about restricting forget to work only
on theorems of the current theory.  But what happens when one
loads a later theory?

eliminate undeclared infix variables (automatic declaration of
opaque infix variables seems to be the way to go).

Testing:  (recent) the UP tactic (longstanding) theorem dependency.
I should probably run a test of the built-in arithmetic and consider
the upgrade to base 10000.

Development of automatic support for type inference for absolute types.
See agenda of August 22.

Append (or simply send) OUTPUT term displays to the global term window.

User command access to scin/scout info (display relevant theorems!)

Think about delayed substitution and other term type efficiencies, and
about rewrite rule compilation (Fast Tactic Prover paper).

Think about code security: possible use of abstract types (as the
HOL theorem type) and use of structures and signatures for code
modularity and SML partial compilation.

Note that an improved type system should facilitate implementation
of "Sigma_2 replacement".  (any class function from an s.c. set
to an s.c. set which doesn't run afoul of opacity should be a set
function).  This may be implementable fairly easily with current type
info, though.

Is it worthwhile to consider user extensibility of the context-dependent
properties of || to other operators?

The problem of extra parentheses around unary operators...

remember question of modular organization of theorems.  This might
assist with search for multi-step proofs -- in fact, Otter strategies
might be relevant to this line of thought.  The Mark2 idea of storing
subtactics in a hidden list inside the parent theorem and popping them
onto a cache when the parent theorem was executed deserves
consideration.  It is certainly odd that the theorem list of a theory
like omnibus is simply "flat".  Idea of having ML-like "structures"
inside theories?  Note that limiting theorem list sizes can facilitate
multi-step proof search.

Think about the problem of "proof objects" and version control for
axioms?

Idea for interface:  type terms to be "started" in the Global Term window;
then a keystroke could carry out the start command.  fields for entering
arguments to other commands would make it possible to do this with other
commands as well.  

The interface needs to be able to issue an interrupt to the mosml process.
A restart using the same windows would be handy, but may be ruled out by
the structure of the classes?


*)

(* August 20:

UP tactic has been tested and appears to work.

Version now has the UP tactic installed!  Complete installation
but not much testing.  Oddly, competing UP tactics are executed
from the back of the term.

For the moment, I think that UP tactics at top level should
be left hanging; one might want to go up and execute again,
and the droprule command exists.

Notes made on laptop after TPHOLs:

3 corrections to file made during conference.  Hypothesis display
added a return for the sake of the interface.  I changed the pause
message to Watson:  Paused, again for the sake of the interface.
Finally, I fixed an actual bug in the "functional programming"
feature:  the program attempted to execute constant names
rather than their associated programs.

As an immediate upgrade, I project the UP built-in tactic.

*)

(* August 10:

corrects an oversight re the INPUT command:  the display will now
tell you if the theorem supplied to INPUT is being applied in the
converse sense.  I don't know if anyone will ever use this, but it
should be there.

changed "errormessage" in envname() to "nopausemessage" -- probably
fixed problem with demo scripts?

The SHELL built-in tactic has been disabled, since it is now
redundant.  One still might like it in guimode, but guimode is
deprecated anyway...

Is it a good idea to display a theorem whenever it is introduced
by a ruleintro command, for purposes of the interface?

I have set up tabular displays so that they are captured in the equation
window, and messages so that they are appended to the local term window.
I think that essentially all Watson output is now captured in one of
the special windows in the GUI.

*)

(* August 9:

adding annotations to theorem and other equation displays so that
the GUI can extract them and post them to an equation window.

The GUI now displays initial displays in the global term window,
INPUT displays in the local term window, and equations, statements,
and hypotheses in a new equation window.

There ought to be a message window as well (or provision to display
messages somewhere, at any rate).

*)

(* August 8:

The intention is to install the "secure menu" of commands which can
be carried out when prover operation is paused.

Note that ; by itself now works as quit(); and e; as exit();
(though any line beginning with a non-alphanumeric currently
causes quit() and might better cause an error message).

The secure menu has been installed, and the handling of command
menus has been made (we hope) more stable.

This should mean that the new methods of handling pauses are now
stable...we hope!

*)

(* August 1:

Note that the load command now gives some output telling you what it
is doing; I introduced this during a bug fix in the last couple of days,
and I liked it...

I'm planning code cleanup today.  

1.  check about handling of nested processes in various contexts.

2.  restore the option of having the old behavior of the INPUT command
(but obviously keep the new one!)

3.  eliminate old versions of text which cause confusion.  This includes
most code related to commutative matching.

4.  create list in this comment of changes made and lacunae in the prover
which need work.

cleaning up relics of the original attempt to implement suspended
processes.

It has been noted that it may be necessary for all infix variables
to be declared.

The problem of redundant parentheses around infix terms.

The dependency machinery has never been thoroughly tested.

For the GUI, theorem display may need to be marked so that it
can be pulled out for a theorem display window.  Also, it may
be desirable to be able to thmdisplay a theorem with parameters.

guimode() user command (a toggle to turn off some of the GUI changes)
introduced.

Idea of secure menu to associate with the suspend() command should
be considered.  A TEMPMENU for swapping is already available.
The minimal secure menu would just have exit on it...

Fixed minor bug in July 31 script handling.(q; did not work)

Introduced a fix for the possibility of commands in scripts not
using up their arguments.  The prover raises an error message at
the next line of the script when it notices that the argument list
is not null.  A special case is needed for the unit argument.  This
does mean that one cannot put space between the end of a line and
the following semicolon!

I have run this on existing files and found some errors.  This process
hasn't been completed, but all this testing will be done at the end...

The script reader should now read essentially the same things acceptable
to ML (except that it can handle returns inside strings, unlike ML).

The handling of autoscripting seems to be clearly wrong for nested
scripts? I think I have corrected it by moving information from
executefile to script.

Is there a question about scin/scout prefix variables?

forget is still not safe with segmented theory storage?

I eliminated a bunch of cmatch comments, including the now very outdated
matching function itself.

Is the unification function usable at all?  Consider updating it so
that it will work with the full capabilities of the prover (it never
handled abstractions, as I recall?).

reset needs to work when we break out of load, too.

SHELL may be obsolete?

attempted installation of guimode() for INPUT...The code compiles,
but still needs to be tested.  Because guimode is deprecated, it is
not supported by noml or scripts.  guimode() will also turn off the
. . . displays used by the GUI.  But the changes in showalltheorems
and steps are not affected.  Note that because of the omission of . . .
the GUI will DEFINITELY NOT WORK unless guimode is on.

There remains a lacuna in the redefinition facilities, having to do with
type definitions.  But it is unclear how much redefinition may be used?

what happens when INPUT is applied in reverse?  The user should be told!

There is still a line of investigation to pursue on intelligent theorem
searches.

*)

(* July 31:

I doubt that autoscripting for nested scripts is actually handled correctly.
I believe a general review of the code might be useful at this point; patches
are accumulating...

I changed the way that unknown commands are handled in scripts
(and in load files, noml).

A new version of INPUT command at the top level:  at the top level
(but not in scripts) instead of seeing an INPUT prompt and typing the
name of a theorem, one sees a Watson prompt at which one types

inputri <name of theorem>; quit();

iri abbreviates inputri.

Since one is in a shell, one can do all the things one can do with
the SHELL command, but there is so far no security against modifying
the environment (I think this can be installed?)

q abbreviates quit and e abbreviates exit.

The iri idea seems to work but requires security.  One idea, simpler
than the SHELL kind of security, is to create a new, very restricted,
command menu, only containing iri and commands which do not affect
the environment.

At this point I think that all interactive input to the prover
is carried out through the noml shell.  Abbreviation of quit and
exit makes this less verbose.  (just q; or e; will work).

*)

(* July 28:  the Feb 25 improvement of display of prefix terms turns
out not to work, and has been removed.  Some of the parentheses around
infix terms which it eliminates turn out to be needed!  The difficulty
is that the validity of eliminating parentheses around the second term
of an infix term when it is a prefix term depends on the context of the
entire term; this is hard to deal with. 

Also, exit() now allows one to cancel suspended processes (like
sat();)

I have set up errormessage to break out of scripts.  I have
created a separate nopausemessage command which handles informative
messages which are not error messages and should not "stop the show".

Note another occurrence of the infelicity of storing and retrieving
terms via their displayed form!  But this one seems essentially
unavoidable.  It may be possible to write a smarter display function
which _can_ eliminate the unnecessary parentheses around some infix
terms; I'll think about this.

*)

(* July 26:  a mere note, reflecting no change in code.  It is necessary
to figure out how to get INPUT mode to work with the GUI.  An idea
which I am considering is to get INPUT mode to invoke the noml
interface (an extension of the idea I have used to handle other
kinds of interaction with the prover in the GUI).

*)

(* July 7:

I changed the technique of handling breaks again.  The internal
details are unimportant (I used the noml shell instead of trying
to construct a new process handler); the result is that one uses
quit() instead of next().  Demo mode now works more or less as
expected.

I think the interface should be able to handle INPUT by stopping
at its prompt?

It should be possible to recover the ability to break out
of interactive loops by clever use of exceptions.

The GUI needs to be fixed to catch "guidone();" in diagnostic
mode, but otherwise everything now works.  I have not tested
INPUT mode; I expect that the interface will work OK if it
is told to catch the INPUT prompt in the same way it catches GUIDONE.


*)

(* July 6:

modifications used to support the GUI.

A closing string . . . added to all term displays so that the GUI
can extract them from the output of mosml.

Theorem listing commands now work differently.  If you issue the
command "showalltheorems" (for example)  you will get one theorem;
to get the next one type next();  You can type other commands in between
executions of next();  the rest of the theorem display will be suspended
until you finish it or execute another command that uses the same resource.

Pause function is disabled.  The demo() function now no longer does
anything; there is a command filedemo file_name which will run files
effectively in demo mode, but nested filedemos are not possible.  A
filedemo will not take input for the INPUT command from its file.

If an error occurs in a script and pause is set, the prover
will automatically break out.

Proof development with INPUT will probably require repeated submissions
of lists of theorems to be applied ending with STOPINPUT so that one
will reemerge correctly.

The input problems are fixed, except for the vexed problem of INPUT
and the limited possibilities of filedemo (which I don't understand;
I don't know why filedemo can't handle the stack of theories, which seems
to be the problem).

One ought to turn on diagnostic mode for the GUI?

Latest innovation allows stacked interrupted processes; this calls
for care in use of presuspend() and cancel() commands to start
and stop these processes.  

I need to understand why files don't seem to like suspend().  Why
are these Out of memory errors happening when I try to implement the
old demo mode?  it seems that it does not like getting file information
from a stack?

*)

(* June 29:

add dummy command to signal to GUI that commands are done.

*)

(* June 27: 

doesn't yet reflect any code changes.

statement of intent:  I want to add "screen-based"
movement commands which will allow (virtual) movement up down
left and right in the nice display of a term.  The way this is
achieved is by having the fancy display function build a data
structure that records where each subterm begins on the screen.
This will require the fancy display function to build position
lists of binaries as it goes.  The movement commands will require the
prover to search the screen structure for the position of the currently
viewed subterm?  Or perhaps a global variable could hold the cursor position
of the Parenthesis subterm, just as a global variable holds the position
of the whole screen structure.

These commands will then be useful for talking to the projected GUI.
I have no idea what they will look like to the user with the current
interface.

*)

(* June 19:  added defaultprecsame command, which sets default precedence
to be the same as that of an existing operator, completing the suite
of "relative" precedence commands *)

(* June 16 suggestion:  automatically generated scripts should include
verify statements (no change yet) *)

(* June 16: planning an upgrade to precedence setting, allowing
precedences to be set relative to precedences of existing operators,
without any reference to numbers. 

new commands

sameprec
leftprecabove
rightprecabove
leftprecbelow
rightprecbelow

Each command takes two arguments, the first being an operator
to be assigned precedence, and the second being an operator which
presumably already has precedence.  The new precedence is set to be
the same, inserted just above, or inserted just below the old
precedence, and set to group left or right as appropriate.

*)

(* June 15 note (no change):  For easy use of precedences, there should
be a device for "inserting" precedences -- give an operator a certain
precedence and raise the precedence of all operators with precedence 
higher than that by one.  An idea:  don't use numbers at all!
Define precedence as "same as ^+" (a simple assignment), "just above
^+" (an insertion) or "just below ^+" (another kind of insertion).
This should make for a much more natural approach!  (the showprecedences
command can then be used to look at the resulting order of precedence).

New "verify" command added.  Also new "showdef" command.

*)

(* June 15:  updated documentation again.  Added new commands showdef
(which displays the defining theorem, if any, of a constant or operator)
and verify (which can be used in scripts to check that theorems are
proved correctly). *)

(* June 14: fine-tuning of incremental backup.  The handling of the
LASTNAME variable by scriptinscript was changed, and backuptheory will
do nothing if LASTNAME = NAME.  Either of these changes would probably
handle most problems.

*)

(* June 12:  the theory backup situation is still not satisfactory.
For example, the theory counting never gets backed up in the omnibus
construction.  How is it going to get backed up?  Maybe explicitly?
Or should one of the commands gettheory, scriptinscript, or storeall
be automatically backing it up? *)

(* Apr. 27-8:  I regard the higher-order matching upgrades as now complete,
barring discovery of bugs.

The next issue is adding security to incremental theory saving to file
and desktop by enforcing a tree-like structure of dependency between
theories.  The simplest technique is to maintain a registry of precursor lists
of theories, and prevent a theory name from being assigned if the list
of precursor theories (SCRIPTS) is not appropriate.

A registry of theory dependencies is now maintained and checked.
I do not know whether it works.

I think that the current registry scheme is secure against at least
the most obvious kinds of abuse of mutual calls of theory files; it enforces
a sensible tree structure.

There is a new user command droptheory; droptheory s will delete theory
s and every theory which depends on it from the desktop.

A nice addition would be the ability to load a theory file with a different
name than the file name?  Same for scripts.

Needed things:

A sensible user interface.

on-line help

aliased load and script commands?

tests of proofs in the main corpus with struct2 and firstorder. (testing
that use of @! does not cause problems).

tests of the theory dependency lists; these have not been tested
extensively, and they are generally among the most complex functions
of the prover.  Redefinition of types is still not supported.

tests of the new higher-order matching facilities, but I've done
some of this.

The forsome problem with @! is still an issue of sorts.

Should @* (the @! of design) be supported?

A complete review of the source for clutter; for example, all the 
commutative matching stuff should be eliminated.

Smart multi-step matching is still a goal.

*)

(* Apr. 25:  changed strongeval to automatically evaluate p1,
p2, and constant functions at ?0; this makes strongeval inverse to bind.

Evaluation functions no longer do anything special with ?0 and expressions
with functions applied to ?0 can be rule-free.

p1 and p2 remain programmed, but this is optional.

*)

(* Apr. 24:

The treatment of formats didn't work right with the matching of
terms [?P@?1]@?x as if they were ?P@?x; the cleanup seems to be complete,
and much better than the original version (it is much more obviously
a matter of using the format match to make substitutions into the theorem
to be applied before matching with the theorem).

UNEVAL can now be implemented by the user.  But the system does not
yet know to carry out more than one function application before matching.

At least a draft of the full higher-order matching upgrade (supporting
multiple implicit UNEVALs) is now present).  It passes the obvious tests
so far.

The prover will now both abstract to get a match and evaluate to get a match.
Query:  will this cause many applications of UNEVAL to become unnecessary?

*)

(* Apr. 21:  brought higher-order matching with @! more into line
with that for @ 

This version now includes at least a draft version of all the higher
order matching upgrades that were intended.

*)

(* Apr. 19:

a change in the treatment of formats which may make higher-order
matching more powerful.  The match of formats is used to make substitutions
into the theorem to be used before it is applied.  This should make it
possible to implement BIND, for example.  The change is strictly
confined to the function USE.

Further refinements will be needed.  The match that will allow user
implementation of UNEVAL will also allow elimination of possible unexpected
behavior of the new approach to format matching.  Also, @! should be
made more like @ in higher order matching (but no need to support the
pair).

*)

(* Apr. 18:

best fix so far for problems with segmented saved theories.  backuptheory
reappears in most places (though possible redundancies should be explored).
newsegment now consults a new global reference LASTNAME for the most
recent "old" theory, and it is the responsibility of other commands
to update LASTNAME correctly.  algebra2.wat can storeall to itself again
without trouble, for funny reasons.  I still need to think about whether
all theory update commands work correctly in scripts.

Treelike theory structure should be checkable.  Also, "forget"
should be controlled.

*)

(* Apr. 17:

removed backuptheory from storeall, load, gettheory to avoid subtler
problems.  The whole segmentation deal needs to be thought through
_very_ carefully!  But gettheory needs backuptheory for the current
scripts to work -- or else backuptheory should be invoked explicitly.

Scripts don't work with the current version; try adding explicit
backuptheory, or think _very carefully_ about when this command
should be invoked -- or what commands should be allowed in scripts!

Go through and think about each instance of backuptheory that I commented
out!!!

*)

(* Mar. 6:

There were actually major difficulties which I didn't notice!
The way in which scripts call each other has to be carefully controlled
to avoid problems -- this should never be a problem in a simple linear
accumulation of scripts, but any situation where we set up for theorem
export will require considerable care.

The current version ought to work as long as theory structure is
strictly tree-like (every theory has a simple linear accumulation of
predecessors) but it is easy to goof this up; the previous state of
omnibus was not tree-like (typestuff was the culprit).

The prover needs to be able to test for certain bad conditions, but 
it also needs to be noted that the incremental backup scheme is inherently
less secure!

The prover does now successfully build and load omnibus on my home
machine.

*)

(* Mar. 3:

mod minor difficulties, the segmented desktop and save file system
now seems to work.

Invariants:  the first element of the SCRIPTS list should always be
the current theory.  the second element of the SCRIPTS list should
always be the theory to be loaded just before the current theory.
The hierarchy of "modules" is still strictly linear, though I have
some ideas how this might be changed.

The file sizes are _dramatically_ smaller.  On the other hand,
one needs .sav.wat files for all precursors of a theory to load it;
this is a new situation.  Maybe the old load command could be preserved?

It is quite likely that there will be other peculiar problems.

*)

(* Mar. 2:

A general idea is in place, but the recursion between the setup
of the save file and the functions preload and load is not right yet;
it will NOT work as now given!  Look at functions savefile, addscript,
load, preload.

Desktop functions now work with segments -- or so it seems.  They
are quite sensitive, so it is necessary to be careful!

the strategy for file saving  is to strip the desktop theory down
to the "new segment" and save that.

An idea for file loading:  put commands at the head of the file
which set the script, then pre-load the theories indicated in the
script file.

still alternative file segments.sml.

A new idea:  keep the current THEORIES data structure and develop
a mechanism whereby the "new" part of the desktop theory is extracted
and put into saved desktop structures or into theory files.

Conversely, the top level load procedure will clear everything, then
load the list of previous files used (recorded in SCRIPTS, which
thus becomes more important) with overwriting.

The only visible effect will be that applying "forget" to objects
found in precursor theories will not be effective unless the forgotten
name is reused.

Also, saving may become slower.  Loading should not be affected.

*)

(* Feb. 29:

New file "segments.sml" created for upgrade to "theories"
data structure.

Notes for segmented theory scheme:

the idea is for the file associated with each theory to store only
theorems which are new (or changed) in that theory, and to "open"
theories already present or load them from files if they are absent
when they are started up.

The "theory" data structure will be the same as it is now; there
will be a new "theories" data structure which is a partitioned list
of all theorems available in theories on the desktop.  This will
eliminate the vast reduplication in the current scheme.

The idea is to write this in such a way as to be completely invisible
to the user.  Commands like "load", "storeall", "script", "gettheory",
"backuptheory", and the theorem export commands need to be rewritten
for the new data structure.

The structure needs to include a number of blocks of theorems, each
labelled with a name and the blocks on which it immediately (?)
depends.  When theorems are proved or reproved, they need to be
updated in the current block as well as in the desktop theory.  (so
"prove" and "reprove" are also affected).  Axioms and definitions not
in the current block need to be untouchable -- no, but
reaxiomatization may cause a lot of overwriting.  Later blocks can
always overrrule earlier ones?  How is theorem export going to work?

design question:  what about all the other theory components?

The -deps2 components are large, and present a problem for the segmented
model.  Maybe we really need to do it right -- have a single theorems
list with individual theorems tagged by theory.  But does this really
help?  The cross-reference structures will still present a problem, won't
they?  Or will they be a single structure, too?  Overriding will
be handled in this structure by having theorems of the same name
in different theories?

The opposite model has _every_ structure have additional qualifications
on its entries for theory.  How about a generic approach?  Each structure
is replaced (or shadowed) by a partitioned structure with components
indexed by theory, in which only "new" entries are added.  Shadowing
is better than replacing -- we don't want this coming into play every
time a theorem is applied!

Model is that there is an additional theorem list NEW_THEOREMS
to which each theorem proved or reproved is added; when theory is saved,
this NEW_THEOREMS replaces the partition labelled by the current theory
name.  The deps2 structures might have a more complex model in which 
deps2 are constructed by consulting all the deps2 lists in currently
relevant partitions?  (otherwise segmentation wouldn't really save
anything for these).  But this really doesn't harmonize well with
reproof, for example.

a droptheory command would be handy...just for testing what the
problem is in Windows, for example!

*)

(* Feb. 25: brilliant idea of putting unary terms in a "user
parenthesis" when preparsing was a bug, not a feature; fixed this
(replaced it with the old approach of not reassociating to reveal a
prefix).  This probably means I need to think about what parentheses
need to be displayed -- there's probably a similar case in the display
functions which needs to be fixed so that redundant parentheses don't
show up.  I think that's fixed, too. *)

(* also Feb 17:  the Feb 7 and Feb 17 updates also need to be ported to
design *)

(* Feb 17:  noticed bug which causes repeated displays in "downtoleft";
not fixed yet FIXED *)

(* Feb. 7: installed facilities to suppress display of embedded theorems
in the trace feature 

New command stepsnorules() does trace without display of rules.  One
still sees parentheses hinting at where rules might be; this might not
be a bad thing?

How about security for funny breakouts?  I suppose reset() can do that.

It is theoretically possible (and unavoidable) that stepsnorules
will get caught in certain infinite loops, because it displays only
those steps where something other than an embedded theorem changes.

*)

(* Jan 7:  a question:  why do automatically generated scripts not
respond to statementdisplay? *)

(* Dec. 17:

have EVAL and BIND issue warning messages when they fail?

a toggle command "stratwarning" turns warning messages on and off.
Are warning messages needed with UNEVAL, too?

Another note: metatrat and metahead probably no longer need a level
parameter.  Check this.  (this doesn't represent a change).

*)

(* Dec. 14:  set up facilities for many (but probably not all)
user commands to catch bad substitutions (for predicate abuse) 

corrected metastrat to really enforce Dec. 10 restrictions, and
moved metastrat check to before application of autoeval in the definition
of substitution.

*)

(* Dec. 10:  new clause in declarecheck further restricts use of meta-
application; a curried meta-application in all contexts must be headed
either by a free variable or by a sufficiently iterated function to clear
all the meta-applications.  Actually, this is really only fully
enforced Dec. 14.

it proves necessary to allow permissible meta-functions to be built by
rule applications and by cases from permissible meta-functions.

It seems that this may actually work; it may be demonstrably equivalent
to enforcing "typing" of meta-functions.  Look for a proof of this.

*)

(* Dec. 6: defineopaque modified to work correctly (exclude
mata-application from text defining opaque operators).  Still draft. *)

(* Dec. 1: this is a draft version with a different approach to first-
order logic and the "meta-application" operator @!

I need to make sure that Isstratified is called when needed to post
dependencies on scin/scout theorems.

The eval function needs to check stratification when applied with "@",
in order to post scin/scout deps.

stratification needs to be put in the correct relationship with the
new @! (it will have a much less accepting attitude!)  This, by the
way, means that some of the new commutativity results will fail.

Definition commands need meta versions.  No, they don't; defined
matafunctions are excluded by Dec. 10 design decisions.  It is possible
to introduce operators on predicates by axiom -- carefully!

There's quite a lot of stuff to be done...

There need to be new EVAL, BIND, UNEVAL commands to use with first
order abstraction.  (EVALM, BINDM, UNEVALM; they are implemented.)

There do need to be checks for failure of metastrat after
assignments; I think that the only danger is assignment to a
free variable in a "metapred".  There might be a need for segregation
of variables having roles in "metapreds"?  The role of being an
n-place predicate should not be mixed up with anything else, as it were.
It may be that metastrat will catch this anyway?  The rule would be that
a letter occurring in an n-place predicate position would not be allowed
to occur in any other position.  A stronger condition is imposed in the
Dec. 10 version.

The stipulation against abuse of substitution into predicates is just
fine, but only if it raises an exception?  The BadSub exception raising
approach works for the specific case of assignment, but it is not clear
to me that it will work in all situations?  Something like segregation
is probably wanted?  But the BadSub approach may actually work!

If BadSub is to be used, the commands that might raise it will each need
to have provisions to handle it.  Which commands?

Current solution is that a substitution of a predicate of too low an order
for a predicate of high order raises an exception.  No quantification over
variables in predicate position is possible, which suggests that this is
an acceptable solution?

*)

(* Oct. 19:  extremely minor correction of higher-order matching:
does not affect correct execution of existing files. *)

(* Oct. 18:  installed SHELL command which invokes the shell
from inside an INPUT tactic (or from anywhere, I suppose...) *)

(* Oct. 6: attempt to install bailout for INPUT commands --
STOPINPUT aborts execution of all INPUT commands (in fact, of
everything) 

New built in theorem STOPINPUT has effect of converting target theorem
to a bogus value and causing all INPUT commands to do the same thing;
this has the effect of crashing the tactic interpreter and returning to
the first theorem that invoked INPUT, which is just what is wanted for
proof editing.

*)

(* Sept. 7:

All modifications in this version are purely technical from the 
standpoint of current users; they involve the behaviour of the
special operator @! , which I have not yet discussed.

I'm not happy entirely with the state of @!  I could make it entirely
safe by restricting matching to arguments ?n other than ?0 (ensuring
that all operators matching ?P in the context ?P@!... would be
stratified (but possibly inhomogeneous)) and segregating variables
representing stratified but inhomogeneous operators from other
variables as part of stratification checks.  But it is unclear to me
that there is any hazard from the present situation. The unexpected
new consequence is that at level 0 a variable can match a completely
unstratified abstraction!  Or can I prove that the current setup is
safe?

I must opt in favor of security.  I will restrict higher-order
matching involving @!  to positive-indexed bound variables (there is
no premium on matching pair and constant function arguments in this
case, anyway); this eliminates matching to unstratified abstracts.
I will also insert a check for segregation of variables matching
possibly inhomogeneous operators from other free variables into 
stratification criteria.  This should make the whole @! facility
provably secure.

I have made the changes indicated above (making @! theoretically secure)
and also inserted a stratification check into the assign command
(because it is now possible for a level 0 expression to be unstratified,
which was not possible before).  Uses of the @! command which are expected
should be completely unaffected.

segregation checks need to be run on whole theorems;
this has been implemented systematically.

Fixed glitch in autoeval which caused failure to eliminate some applications
of function terms using @!

*)

(* Sept. 2:  fixed autoeval function so that it works correctly with the
new match function.  The whole library runs except that some old proofs
on quantifier switching break; it was necessary to expand some upto
commands in the proof of ASSIGN_WP because of the changes in the definition
of matching. *)

(* Sept. 1:

For some reason, UNIV_SWITCH is broken.

This version has much stronger higher-order matching facilities than
any previous version.  It is also better designed:  the higher-order
matching uses the bind function, so upgrades to BIND will automatically
upgrade matching.

Fixed up the special case of ?0 in higher order matching; there is no
danger of invocations of "level -1" any more.

Fixed up BIND to bind intelligently with constant function parameters.
BIND now (again) does not commute with EVAL.

General problem:  extend matching to handle pairs neatly; there need
to be matches for P1@x and P2@x as well as for x?  This is what's needed
to make a new UNEVAL work nicely.

Idea:  a pairprep which converts a variable ?x occurring in a context
p1@?x to variables ?x_1,?x_2 throughout the expression before matching
(and carries out execution of p1 and p2 after matching).

The handling of constant functions motivates doing pairprep on both left
and right (not restricting to list binding).

A daring experiment works:  implement higher-order matching using the
new bind function, and get all kinds of new higher-order binding power
all at once!

installed automatic execution of applications to ?0, and fixed an
old bug in steps()

simplified higher order matching to @! to bring it into line with @;
I think this ought to work...

*)

(* August 31st:

This seems to be a version with full strength higher order matching.
Note that introduction of ?0 as default argument required modifications
to declarecheck and also a clause identifying level ~1 with level 1 in
strat (as in declarecheck).

Further upgrades projected:  improve matching and bind/eval functions
to take pairing into account.  Also, improve matching to handle type
labels?  This last might or might not fly?

When working on the pairing upgrade, think about ?m..?n; think about
whether I'm working on a pair or list model.

I should check whether matching to ?F@?0 works as expected?

Should restrictions be placed on the use of ?0?  Should ?0 take over
as nil?  (this last sounds like an excellent idea!)

I have now made BIND into a list binding function.  To preserve
commutativity of BIND and EVAL, I used new versions p1 and p2 of the
projection operators which have functional programming set to evaluate
automatically.  I have to think about what to do with UNEVAL, and also
how to extend this to higher-order matching.  Note that the behavior
of BIND now depends on the grouping (left or right) of the comma
operator.

*)

(* August 30th:

Consider possibility of using ?0 as default value?  One could use
a general strategy of always evaluating when a "bound variable" is
involved?

I have commented out the part in declarecheck where ?0 is outlawed.

I have also introduced the aptoeq function to handle preemption of
higher order matching.

Plan to rewrite higher order matching to do it with all bound
variables; this will handle one of the new cases automatically!
(using ?0 as the default value).

Note that one may want to rework bind to handle values at [?x]
differently as well as values at ?x,?y?

*)

(* August 27th:

restricted terms to the left of a deepest @! to free variables and function
terms.  For completely demonstrable soundness, one could further forbid
free variables occurring in such a context from occurring in any other
context; is there a neat trick for doing this?  Idea:  add info about
free variables to strat?  Not readily typable.  This is probably enough
as it is to support a soundness argument?

Fixed up the levels in the implementation of matching with @!;
I don't think the earlier ones were actually valid.

Get rid of the stuff with @`; this idea can work, but not the way I did it!
Also, "=" would work just as well!  Introduce a function which changes
applications to equations and apply it in the test.

*)

(* August 26th:

In demo mode one can now invoke a noml() shell by hitting s at most
(not all) returns.  Hit return after the two following messages
(turning off diagnostic and demo modes), then type commands as usual.
The script will resume after you type quit();  You will sometimes get
a message "Unknown command quit in script", which is harmless.

Of course, you can mess up what's happening in the script if you aren't
careful!  Right after the proof of a theorem is usually a safe place to
shell out.

I outlined but did not implement generalized higher order matching
in typed situations.

*)

(* August 25th (once again an official release):

This new release has two major features, one straightforward and one
experimental (and maybe even dangerous):

the UNEVAL tactic is now much smarter (this is straightforward); it
will find iterated (curried) values of multiply bracketed functions.
In the existing theory, try

s "?x+?y+?z"; ri "UNEVAL@[[[?1+?2+?3]]]"; ex();

There is a new, very special operator @! which allows the construction
of terms which will match general terms with iterated quantifiers.
For example, there was no term which would match all terms of the form
forall@[forall@[...?1...?2...]] in the previous version (whereas
forall@[?P@?1] matches all singly universally quantified terms); the term
forall@[forall@[(?P@!?1)@?2]] will match all such terms at this point.
The basic idea is that ?P@!?1 will match any term with ?1 in it (not
necessarily at the same type as ?P@!?1); in order to avoid paradoxes,
the term ?P@!?1 can occur only in a context where terms depending on
?1 in any way can be put (for example, both ?1 and [?1] have to be
substitutable in such a context).  This is true of the context
forall@[forall@[...?1...]]; because forall@[...?1...] is known by the
prover to be boolean, its type can be manipulated to allow [?1] to
replace ?1, for example.  The term
forall@[forall@[forall@[((?P@!?1)@!?2)@?3]]] will match any triple
quantification, and so forth.  (A term ((?P@!?1)@!?2) is only
permitted in a context where ?1 and ?2 could be adorned with
independently chosen numbers of brackets without affecting the
stratification of the resulting term.)  This will mostly be useful for
the construction of tactics which will act intelligently on multiply
quantified terms.  The strengthening of UNEVAL will also be useful for
this.  

In general, one can think of a term like (?P@!?1)@!?2 as being
intended to match any term which is stratified except for the fact
that ?1 and ?2 have been translated in type by fixed and possibly
different amounts.  A term of this form is allowed only in a context
where ?1 and ?2 can actually be translated in type (by adding
brackets, say) by uniform amounts (possibly different for ?1 and ?2
but the same for all occurrences of ?1 and the same for all
occurrences of ?2) without perturbing the stratification of the whole
term.  This is true, for example, of ?1 and ?2 inside
forall@[forall@[forall@[((?P@!?1)@!?2)@?3]]].

Further enhancements of higher-order matching may follow.

There is the minor additional feature of a command demoremark
which does nothing except get displayed with its string argument
in demo mode; it allows remarks to be put into demos, as its name 
suggests.

There's a comment in the function executelines concerning a possible
improvement to demo mode; it almost works as written.

*)

(*  standing list of "rough edges" of the prover (arbitrary features
which cause trouble)

Are defined objects defined via their application as functions actually
lambda terms or not?  It would be possible to define a built-in function
which would handle this automatically.

Idea about internalizing type information:  provide a built-in tactic
which will convert an infix term to a functional form, with appropriate
introduction of constant functions and values.

definitions of constants have same names as constants; this has 
inspired the prevention of application of functional programming
to theorem names.

the problem of new variables breaking stratification -- accommodated but
still there and not easily removed.  Of course, I might be able to
use ?f@!?n instead of ?f@?n and fix the problem in this experimental 
version!  (no, newest treatment of ?f@!?n does not permit this).

I might want to generalize the forms allowed as formats to anything
with an "eitherhead".  This would eliminate the need for the peculiar
solution to stratification problems with makescinvar.

Should autoeval be more aggressive:  should it do more automatic evaluations?
Probably to be avoided because it would require repair of many existing
theory files!

Should there be a way to recognize the kind of "scin" behaviour that
the theorem FORALLBOOL2 tells us that forall has?  This goes along with
the recent generalization of argument lists.

There remains the problem of scin/scout for functions with parameter
lists.

Inconvenience of extracting type information.  How about a primitive
tactic which labels the terms on each side of an infix with their
relative type?  How about the major modification of maintaining local
type info and info on type of all abstracts to remove the
stratification failures due to new variables?  Diagnostic information
on relative types would be useful when issues of stratification arise?

Loss of the prompt when demo mode is invoked inside a demo.

The = builtin theorem ought to require matching of the appropriate
side of the given equation; it might be that it ought to have a "matchtri"
analogue, but this would probably behave extremely unpredictably.

I need to analyze the various situations in which stratification
errors can show up in the course of execution and make sure that they
can't lead to incorrect proofs.  The most worrisome situation is the
one in which a variable on the left of a @! (matching an operation
which may not be a function) is introduced somewhere else as a
function; such a theorem will pass stratification tests but will crash
with a stratification failure if the operation is instantiated as a
non-function; I believe that this is harmless (because it is
impossible to generalize over such a variable) but it would be nice to
prove this formally.  If it were a problem, there is a fix:  it would 
require declaration checking to verify implicit typing of certain
variables as general operators, and probably restrict the forms of
expressions occurring on the left of a topmost @! to function terms
and free variables; maybe I should do this anyway.

still question as to whether the implicit typing of stratified
inhomogeneous operators should be enforced.

idea that operators declared scin or scout should be retyped (scin
as flat and scout so as to get smallest type to 0).  Recognize that
if one is on two of the scin/scout lists one should be on all three?

*)

(* August 25:

I think I finally have a sound definition for behavior of the @!
infix for generalized higher-order matching.

Further generalizations of matching which are possible involve direct
support for matching projections of pairs (iterated projections of
free variables would be allowed to match and matches of variables to
pairs would induce matches to projections; some care needed to avoid
regress) and stronger higher-order matching for cases of concrete type
differentials (iterate higher order matching and match to things like
(?P@?x)@0 and ?P@[?x]).

The idea is that ?P in (e.g.) ((?P@!?m)@!?n must match a "stratified
inhomogeneous" operation on ?m and ?n; one which is an operation on ?m
and ?n yielding a stratifiable expression but not necessarily one
which can be expressed as a function of ?m and ?n (the relative types
of ?m and ?n may be too high or low for this to work).  A general
operation of this kind can appear in a stratified function definition
only in special contexts: ones in which the types of its arguments can
be arbitrarily displaced with respect to the context and one another
without affecting stratification.  These are the conditions enforced
on the @! operator (along with the condition that the head of a
curried expression in @! is an opaque environment; no binding can
occur there at all).  It doesn't seem that the possibility of having
?P appear in other positions can be exploited to prove anything (after
all, it isn't clear that one can prove much of anything about
expressions ((?P@!?m)@!?n).

*)

(* August 24:

New experimental implementation of higher-order matching
seems to work, more or less.  The approach is to allow ?P@!?1
only in positions where the relative type of ?1 floats.
The implementation involves carrying out stratification twice,
with different output types assigned to @!.

The idea is that ?P@!?n matches any expression of the same "level" as
?n (involving no bound variables with higher index) whose type
"floats" in its context.  The stratification function types each term
twice now, with two different output types for the @! operator.

The term forall@[forall@[(?P@!?1)@?2]] (note that there is just one
@!) matches any double quantification.

Any reasoning with terms of the form @! will encounter restrictions;
it must preserve the floating character of the typing of all ?P@!?n
terms and also respect other logically motivated precautions.

I believe this feature is sound in concept, but an earlier version
allowed bad proofs; there may of course be bugs!

Do we still need more general forms of higher-order matching?  is
the x@!y@!...z@w pattern enough?

UNEVAL is now full-powered; it handles multiple bracket terms as
parameters and produces iterated values thereof.

I might be able to write a general bound variable switching procedure
without running into the usual blocks:  

forall @ [forall @ [bool : (?P @! ?2) @ ?1]]

is an acceptable term!  But it still might not work. (LATER:  this does
work!)

*)

(* August 23:  

fixed bug:  => and <= were supposed to be scinleft; now they really are!
In general, properties of built-in operators need to be updated by
the clear() command.

*)

(* August 20:

installed ability to declare scin infix variables with command
makescinvar <name>.  Corrected match to allow this.  Supermatch
appears to handle this correctly already.  The modifications to other
functions appear to be sufficient to allow the declaration of scout,
scinleft, or scinright infix variables as well if they are ever wanted.
Scout infix variables would need to have their relative types shifted
to a canonical form (say with one of the types 0).  Scinleft or scinright
infix variables would have the "hidden" type switched to 0.  Commands for
these cases have not been installed.  The type transformations suggested
above might be desirable for purposes of theory matching for non-variable
operators as well.

This appears to work; it solves the problem of stratification problems
in embedded theorems completely (use a scin infix variable instead of
, in the parameter list of a theorem to make it secure).  The
installation of makescinleftvar, makescinrightvar, makescoutvar is
relatively easy, but I do not as yet see applications for such
variables?

*)

(* August 20:

nothing implemented here -- just ideas.

1.  scin infix variables would be useful.  scout, scinleft, and
scinright infix variables might also be nice, but this takes more work.
I should look at the conjecture that being on more than one of these
three lists should put you on the third as well, and check that variables
on more than one list are treated correctly.  An advantage of scin
infix variables is that they could be used to build parameter lists for
tactics, eliminating all problems with stratification in embedded theorems.

2.  The problem of higher order matching inside more than one bracket
appears again.  A generalization of UNEVAL to handle curried functions
might help.  Generalized binding tactics might be useful as well.  A
true generalization of higher-order matching remains a possibility, I
suppose.  Use expressions in ?P@[?n] and (?P@?n)@0.  I can also write
generalized binding tactics (especially when scin infix variables
are available).  There's an old idea that higher-order matching should
be integrated with the type system somehow?

*)

(* August 19: notes on possible editor function.

This would be used in conjunction with makescript.

List basic functionalities wanted:

load the current autoscript into buffer

move around in editor buffer in usual ways

search-replace in editor buffer

display ranges of lines; copy ranges of lines

execute ranges of lines in prover

This would create a text-based environment in which all commands
passed to prover would be recorded automatically and it would be possible
to manipulate these commands and reissue them in a reasonable way without
relying on an external editor or the cut/paste capabilities of the
OS

*)

(* August 19:

Try the compress() command to get a vertically compressed output
format.  A dashed line separates dependencies from the text of a theorem.
expand undoes compress and both are found on the script command menu.

In demo mode, a "d" entered at any pause will exit demo mode while
continuing execution of the script (you will have to hit return once
or twice in response to messages before the renewed execution starts).

The script command inside the noml() interface is now "script"
(the same as at the ML prompt) although the alternative "truescript"
will still work.  The noml() interface now catches any exception, rather
than just I/O exceptions, and this source should compile under SML 96
without any change.

I suggest trying noml(); compress(); to set up your working environment.
To return to the ML prompt, type quit();  

makescript "test"; compress(); will set up the same environment,
recording your commands in a script test.log.wat.

Added demoremark "string" command which does nothing; its only purpose
is to be displayed in the demo function.

Since I am not planning to add commutative matching to the prover as
a standard feature, the (no cmatch) comment has been deleted from the
versiondate message.

*)

(* August 18:

more work on look and feel.  Theorems are now separated from their 
dependencies by a dashed line in the compressed theorem display.

compress and expand added to script command menu.

Also, entering "d" during a script in demo mode will take you out of
demo mode, allowing the script to finish (unlike "q", which will stop
the script).

things now seem to work.

*)

(* August 17:

minor modification to lookhyps: it displays the variable binding
situation even if there are no hypotheses.

Changes to term display:  displayed terms are indented (which
should be good for "human factors") and additional commands are provided:
the compress() command will eliminate lots of carriage returns
(compress things vertically) and the expand() command will restore
the usual situation with lots of returns.

*)

(* August 13:  

modification to preexecute and preonestep; earlier versions
did not do any execution inside embedded theorems; this version executes
the parameters of parameterized theorems.  This will allow simplification
of tactics like POP_CASE.

The effects of this change on any current theory should be nil.

Ideas from the visit of Aug. 9-12 in Moscow (not implemented yet):

an INPUTP@?tactic command which allows one to input parameters to a tactic.

a shell command which would allow one to go into a noml shell (with
limited command list) from the INPUT prompt.  One could do things like
thmdisplay, srt, targetruleinto.  DONE!!!

Can I reduce the number of returns (white lines) in prover output?  Jim
would like this. DONE

There is something funny about the use of demo inside a script; it didn't
display the command prompt. 

Idea:  there ought to be a letter one can type to cause a demo'ed file
to go back up to full speed.

The builtin theorem "=" ought to check for matches to the given equation,
not just to the theorem which justifies it.  In other words, it should
effectively define more specialized versions of theorems.

*)

(* August 2:  at this point all commands should be documented in babydocs. *)

(* July 14:  statement display now works in lookhyps as well;
this is useful in deduction theory, for example.  It is a little
weird that $|- is the default "prompt" for a hypothesis, due to the
preference for "true=T" in hypotheses (which is itself caused by the
right associativity preference).

a question:  does the reversal of free variables in supermatch
have to be applied to infix variables as well?  The obvious thing
to do is to introduce a match between bogus free variables in 
reverse in addition to the direct match between infix variables
which is needed to check declarations?

This is implemented, though it is not clear that it is really needed;
the problem probably would never arise.

A brief note about this problem might be useful.  Example is 
in terms of free variables rather than infix variables.  The
problem is that if the match direction was what one would
naturally expect, a theorem

?x+?y = ?y+?x

in a source theory would match a theorem

?x*?x = ?x*?x

in a target theory (with * translating +).  This would allow the
translation of theorems proved using commutativity of + to theorems
about *, which is not known to be commutative, which is unsound.

The modification preventing this has already been made; the modification
made here enforces the same reversal on infix variables.  It is hard to
see how this could really be a problem, though.

The stripvars function needed to be modified to recognize
bogus "free variables" generated in supermatch to enforce the reversal
of matching for infix variables.

*)

(* July 13:  automatically generated scripts now include texts of
theorems in comments after the proof.  This is a change in the
prove function.

fixed matchtri and anothermatchtri to work better

added some new abbreviations

dtl dtr ut = downtoleft, downtoright, upto

ldtl ldtr lut = litdowntoleft, litdowntoright, litupto

mtri amtri = matchtri anothermatchtri

*)

(* July 9:  removed pause after OUTPUT because of bad effects 
on interactions between emacs and the ML interpreter.

Installed messages using the OUTPUT command in deduction.wat.

Installed autoscript facility, with new commands autoscript and
makescript.  autoscript puts the current script file in a file
with the .log.wat extension.  makescript clears the current script
file and calls noml, creating a new script file when noml is exited.
The scriptinscript command automatically clears the current script
when it exits a script successfully (we presumably don't need to
duplicate a script which works).

Correcting problem with INPUT in the noml() command.  The fix is that
INPUT will no longer accept a blank input.

Final situation:  makescript is a user command; autoscript is not.
Logging only happens inside the makescript command, and it does not
happen in loads or script runs inside the makescript command (the
consequences of this when theory files are loaded are disastrous).
The makescript command cannot be nested; it will do nothing if 
scripting is on.

*)

(* July 6: fix to matchtri; also added command anothermatchtri() which
gives further possible theorems; Issuing this command just after
matchtri (or anothermatchtri) will change the theorem to the next
appropriate one in the list; issuing at other times will have bizarre
results.

This doesn't seem worth posting as an official upgrade.

*)

(* July 2:  minor modification -- "dropview" command no longer
sends an error message if the view dropped does not exist 

installed new "literal" movement commands

litupto litdowntoleft litdowntoright

which look for equality rather than a match.  Warning:  these
commands do not do level changes (they won't find [?1] in [[?2]]),
and they will find [?2]).

A new variant "matchtri" of targetruleintro/tri is now available.
This one will look for a theorem which will send the current term
to something which its argument matches.  For example, if we are
looking at "(~ ?x) & ~ ?y", matchtri "~?z" gives us the theorem
DEMb, which sends this term to "~ ?x | ?y".  This allows us to look
for theorems which will send us to terms with a certain structure,
rather than to an exact target.

matchtri's status in the cmatch version has not been decided.

A built-in theorem which implements matchtri might be of interest.
This is likely to be more unpredictable than the = builtin theorem.
It is important to note that it is dependent on the order of the theorems
in the master theorems list, which changes!

*)

(* July 1:  some bug fixes and extensive addition of error messages in
the theorem export mechanism.  The clause for free variables in supermatch
needed to be reversed ((t,s) instead of (s,t)), a rather subtle logical
point!

Supermatch now uses a new version of mergematches which itself gives
messages about match failures.

The previous version created more theorems than it needed to in exports;
it now looks at the expanded view (after supermatch is run) and does not
create a new theorem if it sees that there is a view of that theorem.
This also makes it possible to use the expanded view repeatedly; in the
previous version it created junk entries.

Theorem export remains unstable, I think.

*)

(* July 1:  change to supermatch -- a bijective match between free
variables in theorems is needed *)

(* June 30:

The cmatch version has been changed; its behaviour should be a little
less unexpected than the previous version (commfix is used in a different
way).

Fixed a problem with initialization of the basic view.

*)


(* June 29:  

Minor changes made in course of review of comments:  the script command
will now treat carriage returns in strings as spaces.  the statementdisplay()
command now sends a message as to whether statement display is on or off.

Idea is that June 29 source is a unified source which
can be modified to support all versions of the prover desired.  All
maintenance should be done on this file.

investigations of compatibility of the various sources
being used.  This one will work for SML 93 if the SML 96 conversion
functions are commented out and the line

flush_Out s = ();

is added.

For SML 96, one needs to replace Io with IO.Io in the noml function.

Plan for today is to add material supporting commutative matching in comments,
so that only one source needs to be maintained, then to do cleanup of old
comments.

cmatch stuff is now included in comments labelled cmatch

I made the changes to steps indicated in the cmatch comments,
which are needed anyway.  Also liberalized the type definition functions
to allow the converses of retraction theorems; the wb() in the stereotyped
procedure is no longer needed.

This also reflects the strengthening of commutative matching caused by
use of the function commfix.

inserted old comments from the cmatch source:

(* June 2 (added here June 28):  general cleanup of comments.  
Liberalized the retraction
test in type definitions so that the wb() is no longer needed (a retraction
theorem may safely be replaced by its converse).

This is experimental source "cmatch.sml" *)

(* June 1 (added here June 28):  modifications to get 
commutative matching to post correct
dependencies.

Put postdeps and dropdeps into steps command.

Still stuck with inappropriate posting of commutativity axioms when
commutative matching is on.  This is rather like the extra deps on
typing axioms that show up due to scin/scout.

Should I automate makescin and makescout inside the addtheorem command
in the same way that I have automated commutative laws?

*)

(* May 28 (added here June 28):  testing commutative matching

The prover now maintains a registry of commutative laws 

User command cmatch() turns commutative matching on and off.

Modifications involve the new list COMMUTATIVE, functions iscommutative0
and iscommutative, changes to addtheorem and droptheorem, and changes
to match (and use of oldmatch where needed) as well as very important
change to mergematches (match gives a nontrivial list of
different alternative matches)

Prover never uses commutative matching for control structures
in the tactic interpreter or for special movement commands

use of = in prematchtheorem needed changing to , since = is commutative 

Note that GCLEAN tactic does not work under cmatch -- maybe the
point is that it _does_ work but works very differently.

Now testing oldmatch in prematchtheorem; this appears to cause GCLEAN
to work correctly.  (version weakprematchtheorem does not use oldmatch)

The toggle needs to be provided for backward compatibility even
if commutative matching is the default! 

This remains a provisional version:  for example, it does not 
have correct theorem dependencies -- something needs to be done
to post dependencies of commutative laws when the matching 
uses them. *)


*)

(* June 28:  This has been tested with SML 96.  The only problem
in building it is that the Io x exception in noml doesn't work; 
use IO.Io instead.

It appears that SML96 is perfectly happy with the Moscow ML source--
except for the same problem with the Io exception.  What is the I/O
exception type for SML 96?

Stuff about exportML:


      exportML, heap image files, @SMLload command line parameter 

            Question: Calling the function exportML, as in 

            - SMLofNJ.exportML "image";

            creates a file called "image.mipseb-irix" that is not executable,
            while with SML/NJ 93 I would get an executable file called
            "image". I wonder if I am doing the export correctly or if there is a
            new procedure for using the exported image? 

            Answer: The file "image.mipseb-irix" is a heap image -- not an
            executable. You can load it as follows: 

            % sml @SMLload=image

            Note that you do not need to specify the ".mipseb-irix" suffix
            when specifying the image file, it will be inferred. 

*)


(* June 25: a very minor point; when one leaves the script command,
it will always turn off demo mode.  Also, turning demo off or on 
sets the verbosity as appropriate (this means that users will not want
to turn demo mode off at the top level -- but they should not have to!)

changes to script, reset and demo

This still needs to be ported.DONE

*)

(* June 16:  very slight refinement of comments in INPUT text
In the June 15 version, either { or } started a comment to the end
of the line; now it is only { which starts a comment, which will
go either to the end of the line or to a }.  A } acts like an
end of line and could be used to put more than one input on the
same line.

changes to script, reset and demo


*)

(* June 15:  upgrade to display local level in lookhyps command;
the prover tells what bound variables are locally free *)

(* June 14:

Modified prover so that input can be supplied to the INPUT command 
in scripts.

The theory stack TESTTH has to be declared early (before applybuiltin)
so that the INPUT command knows where to get its input.  It is also
initialized differently (as [std_in]; no file "dummy" is needed any
more).  The theory stack is reset to [std_in] when users break out
of scripts.

A new reset() command is now provided for users to execute whenever
they break out of a script with Control-C.  The reset() command fixes
the theory stack so that INPUT will know to read from std_in again.
reset() cannot (and should not!) be run in any script.

The DIAGNOSTIC toggle is declared early so that INPUT can behave correctly
in diagnostic and demo mode.  In diagnostic or demo mode, the user can
break out of a script by using "q" instead of hitting return after an input.

In scripts, stuff supplied to INPUT is read line by line.  Comments
with (* *) cannot be embedded in text for INPUT, but to-end-of-line
comments can be started with either kind of brace.  (this required
a modification to the stringinput function).  If something breaks in
a script with INPUT text in it, one can expect bizarre errors!

*)

(* June 10:  added backuptheory before running scripts

fixed bug in tactic interpreter; it did not correctly enter
the levels of hypotheses encountered in abstraction terms.

The change is in coercehypslistsense.

statementdisplay() now enables a special display for true=T theorems
(converse statements) with $|- This did not interact with lookhyps,
which does not use eqdisplay, contrary to my earlier beliefs.  This is
OK. 

 *)

(* June 2:  be aware that the experimental file cmatch.sml
now exists (with commutative matching) and will probably eventually
supersede this file *)

(* May 26: completed modifications of thmtextdeps

also added statement display, enabled by statementdisplay() toggle *)

(* May 25:  introduced statement command:

fun statement na ls = axiom na ls "true";  

Completely changed the implementation of theorem text dependencies.

*)

(* May 18:  

fixed bug in the 1|-|n and 2|-|n commands which did not correct level
of hypotheses containing bound variables.

*)

(* March 24:  duplicated from SML/NJ version

eliminated lots of old comments (also in this file).

no change in code:  just a remark that a search for a theorem which
will take the current term to something matching a given term would
often be useful; a built-in tactic for carrying out such searches also
might be interesting.

The current version of the prover has almost all the upgrades I care
about.

Gaps which remain:

a redefinition command appropriate for type definitions.  This can wait
for proof that redefinition will actually be used.

treatment of stratification problems caused by embedded theorems:
tactics defined by abstraction, built-in theorem type thm, automatic
scout declarations for operator theorems (avoiding extra deps posted
to SCINSCOUTDEPS).  This probably can wait until problems are actually
encountered.

the general, hard problem of scin/scout for functions or operators with lists 
of arguments.  This is hard, and requires reflection.

a theoretical question about weak vs. strong versions of opacity.
Should we be able to abstract into opaque contexts when the variables
involved are safely "typed"?  There are plusses and minusses to this;
perhaps a toggle would be the right approach.  This seems too technical;
a related idea would be revival of predicativity restrictions.

"program packages" were not implemented.  Wait until programming is in use.

Note that tri2 and trimetric are not "upgrades that I care about";
they represent experimentation in a new area.  (which will continue).

Another thing I still might do is implement parallel execution order for
the tactic language.  Do this, though it is not highest priority.

Note that targetruleintro can make intelligent use of parameterized
tactics; is there a way to make the multistep commands do this?  This
is a good question; think about it!

Implementation of standard variable binding.  Probably not needed, but
useful for educational applications.

Improved search options; this should be an area of active work.  More
versatile movement commands fall under a similar heading.  Do this!
PARTLY DONE:  See litupto and kin and matchtri above.

Did not reimplement modularity, comments, or on-line help!  On-line help
(which can subsume comments) is needed.

I need to update the documentation (command reference; also add a
section to the command reference on built-in tactics).  Do this.

add application of commutative laws (and perhaps other laws of
stereotyped form) to tri.  There is a vague idea of having an ability
to register new abstract forms which theorems can take and have the
system flag theorems of these kinds?  (so one could add idempotent laws,
for example, without modifying code).  Do this, or at least think about it.

let tri know about hypotheses!  Think about this and do it if it is easy.

rewrite logic?  refinement of success/failure? theoretical questions
about infix variables (generation of new ones, unification?)  All
things not to worry about now.

other built-in data types?  (strings, terms?)

true hierarchical organization of theories; labelling of theorems as
belonging to particular theories (and keeping them all in the same
space).  theorem search across theory boundaries (through views).
This is a practical issue and should be considered!

I need to look at the pretty-printing and see if it is really doing
what I want.  Do this.

Testing of the dependency system is needed; particularly worrying is
the possiblity that type definitions might not be handled correctly.
Do this by working on examples of export (say teaching files).

I definitely need to implement sensible binding and abstraction with
multiple variables of each type (?m..n).  Try doing it in structural,
but be open to idea of doing it hard-wired.  Do this, but first try
writing tactics for structural.wat that do it.

*)


(* March 14:  see SML/NJ version notes *)

(* Sept. 8:  it is no longer necessary (or advisable) to run setup()
when starting up; all that is needed is

load "design";
open design;

*)

(* August 13: developed unification functions; optimized changelevel
and changehlevel by telling them to do nothing when the source and
target are the same *)

(* August 12: fixed yet another bug in the module; setup didn't properly
initialize dependency scratch lists to nil.  August 10 and earlier revisions
concerned output control; Moscow ML needs to be told to flush the output
in certain functions for scripts to work acceptably *)

(* comment these out for SML 93 *)

(* SML 96 Conversion functions 

(* load "Int"; *)

(* val load = load; *)

val std_in = TextIO.stdIn;
val std_out = TextIO.stdOut;
fun output (out, msg) = TextIO.output(out,msg);
fun input (inp, n) = TextIO.inputN(inp,n);

fun makestring(value) = Int.toString(value);
fun explode (s) = (List.map str (String.explode s));
fun implode (ls) = String.concat ls;
fun max(n1,n2) = Int.max(n1,n2);

fun open_out(s) = TextIO.openOut(s);
fun close_out(s) = TextIO.closeOut(s);
fun flush_Out(s) = TextIO.flushOut(s);

fun open_in(s) = TextIO.openIn(s);
fun close_in(s) = TextIO.closeIn(s);

fun flush_Out(s) = TextIO.flushOut(s);

fun substring s = String.substring(s);

(* fun exit() = OS.Process.exit(OS.Process.success); *)
(* fun abort() = OS.Process.exit(OS.Process.failure); *)

 END SML 96 Conversion functions *)

(* used for SML 93 compatibility *)

 fun flush_Out s = (); 


(* Error message function with pause control functions *)

val ERRORPAUSE = ref false;

fun setpause() = ERRORPAUSE := true;

fun setnopause() = ERRORPAUSE := false;

exception Breakout;

val Returns = ref("\n\n");

fun compress() = Returns := "\n";

fun expand() = Returns := "\n\n";



(* due to the needs of the GUI, the error message command
raises an exception rather than pausing (and so waiting for
input that the GUI can't handle) *)

val ERRORFLAG = ref false;

fun clearerrorflag() = ERRORFLAG:=false;

fun errormessage s = (output(std_out,(!Returns)^"Watson:  "^s^(!Returns));
			flush_Out(std_out);ERRORFLAG:=true;
                        if (!ERRORPAUSE) then raise Breakout
                        else ());

(* this command is used for merely informative messages
that should not interrupt script execution *)

fun nopausemessage s = (output(std_out,(!Returns)^"Watson:  "^s^(!Returns));
			flush_Out(std_out));


(* this toggle tells the prover to use the new method of handling
INPUT at top level -- but the old method is available *)

(* It may eventually be used to turn off some other changes used by
the GUI.  In general, turning GUI mode off is deprecated,
and it is not guaranteed to restore previous behavior in all respects. *)

val GUIMODE = ref true;

fun guimode() = (GUIMODE := not(!GUIMODE);nopausemessage 
("GUI mode is "^(if (!GUIMODE) then "on" else "off")));


(* verbosity of output *)

val VERBOSITY = ref 2;

fun bequiet() = VERBOSITY := 0; 

fun thmsonly() = VERBOSITY := 1;

fun speakup() = VERBOSITY := 2;

(* version command *)

fun versiondate() = errormessage 
     "August 31, 2000 (first-order, segmented, for GUI)";

(* container classes *)

(* Watson requires two kinds of container classes, finite sets and
finite functions.  These were implemented as balanced binary trees in
Mark2.  In this design, they are implemented in a very simple way as
lists.  There doesn't seem to be any deficit in performance. *)

(* all operations attempt to maintain the invariant that any
set or function element appears no more than once *)

(* sets *)

(* a set of objects of a given type is simply a list of objects of
that type *)

(* is an object x found in a given set? *)

fun foundinset x nil = false |

	foundinset x (a::rest) = if x = a then true else foundinset x rest;

(* add x to a given set *)

fun addtoset x L = if foundinset x L then L else (x::L);

(* drop x from given set *)

fun dropfromset x nil = nil |

	dropfromset x (a::rest) = if x = a then rest 
	else (a::(dropfromset x rest));

(* union of sets *)

fun union nil L = L |

	union (a::L) M = a::(union L (dropfromset a M));

fun union2 nil = nil |

	union2 (L::M) = union L (union2 M);

fun intersection nil L = nil |

	intersection (a::L) M = if foundinset a M

		then a::(intersection L M)

		else intersection L M;

(* subset relation *)

fun subset nil L = true |

	subset (a::L) M = (foundinset a M) andalso (subset L M);

(* the subset of a list of which the predicate f is true *)

fun separate f nil = nil |

	separate f (a::L) = if (f a) then (a::(separate f L))
	else separate f L;

(* suppose one only wants to find one object for which f is true... *)

fun separate2 f nil = nil |

	separate2 f (a::L) = if (f a) then [a] else separate2 f L;


fun setminus a b = separate (fn x=>not(foundinset x b)) a;

(* sorting a set *)

fun sortsetput (s:string) nil = [s] |

	sortsetput (s:string) (a::L) = if s < a then (s::(a::L))
		else (a::(sortsetput s L));

fun sortset nil = nil |

	sortset (a::L) = sortsetput a (sortset L);

(* functions *)

(* find an object in the list associated with key s; return a one-element
list of the found object if it is found, otherwise nil *)

fun find s nil = nil |

	find s ((t,x)::rest) = if s = t then [x] else find s rest;

(* a safe version of find which gives the object found and a default
when there is no such object *)

fun safefind default s L = let val A = find s L in 
			if A = nil then default else (hd A) end;


(* is there an object with key s in L? *)

(* changed so that lists of things not of equality types can be handled *)

(* fun foundin s L = find s L <> nil; *)

fun foundin s L = length(find s L) > 0;

(* drop item with given key *)

fun drop s nil = nil |

	drop s ((t,x)::L) = if s = t then L else ((t,x)::(drop s L));

(* an optimization, perhaps; it brings the found item to the front
of the list.  this version of find is used inside the thmresult
function below. *)

fun Find s reference = let val A = find s (!reference) in
	if A = nil then nil
	else (reference:=((s,hd A)::drop s (!reference));A) end;

fun Safefind default s reference = let val A = Find s reference in
		if A = nil then default else (hd A) end;

fun Foundin s L = Find s L <> nil;

(* add item with given key; the first will not overwrite and the
second will *)

fun addto s x L = if foundin s L then L else ((s,x)::L);

fun strongadd s x L = addto s x (drop s L);

(* this is the union operation for the theory segments construction;
keys in the second file override keys found in the first. *)

fun strongunion nil L = L |

	strongunion L nil = L |

	strongunion ((s,x)::L) ((t,y)::M) = strongadd t y(
	addto s x(strongunion L M));

(* this is the difference operation for the theory segments construction *)

fun strongdiff L nil = L |
	strongdiff nil M = nil |
	strongdiff ((s,x)::L) M =
		let val FOUND = find s M in
			if FOUND = nil then ((s,x)::strongdiff L M)
			else if (hd FOUND) = x then strongdiff L M
			else ((s,x)::strongdiff L M)
		end;
	            

(* is a list of pairs a function? *)

fun isfun nil = true |

	isfun ((s,x)::L) = let val A = find s L in 
			if A = nil orelse A = [x]
				then isfun L
				else false end;

(* merge function used with match lists; it returns nil as an
error object, and packages resultant lists in a unit list *)

fun merge L M = if isfun (union L M) then [union L M] else nil;

(* sorting a function *)

fun sortfunput (s:string,x) nil = [(s,x)] |

	sortfunput (s:string,x) ((a,y)::L) = if s < a then ((s,x)::((a,y)::L))
		else ((a,y)::(sortfunput(s:string,x) L));

fun sortfun nil = nil |

	sortfun (a::L) = sortfunput a (sortfun L);


(* The primary objects manipulated by Mark2 are terms; the
manipulations allowed are algebraic.  Atomic terms in Mark2 are of
three kinds, constants (which must be declared), free and bound
variables.  Composite terms are of three kinds: terms constructed
using binary infix operators (which must be declared; though there is
a provision for variable infixes), function terms, and terms defined
by cases.  Unary operators are also supported, but they are
coded as binary operators as will be seen below.  *)

(* the separate clauses for reserved identifiers and for case
expressions are a new idea *)

(* term data type declaration *)

(* type of infix operators *)

datatype operator =

	ConOp of string |
	VarOp of string |
	ResOp of string |  (* reserved operator *)
	ParOp of string;   (* an internal device *)

datatype term = 

	(* atomic terms *)
	
	Constant of string |
	Numeral of int list |  (* Mark2 has built in arithmetic *)
	FreeVar of string |
        BoundVar of int |

	(* composite terms *)
	
	Infix of term*operator*term |
	Function of term |
	CaseExp of term*term*term |
	Parenthesis of term;  (* Parenthesis is a special construction
			used internally for various purposes *)

	

(* There are some differences between the surface form of Mark2 terms
(as displayed and understood by a user) and the "deep structure" exhibited
in the type declaration above.  There are also some notational points
not capable of being made in this format.

All atomic terms are represented by strings made of alphanumeric characters
plus the special characters "?" and "_".

The empty string does not represent a constant; Constant "" is used 
internally as an error object.

Strings made up entirely of digits stand for numerals.  They are stored
as lists of digits (in reverse order).  The built in arithmetic of Mark2 is
unlimited precision arithmetic of non-negative integers.

Strings made up of the special character "?" followed by a non-zero-initial
numeral represent bound variables.

Strings which begin with "?" and do not represent bound variables are 
used to represent free variables.

Strings which do not represent any of the above represent constants.
Unlike the three other sorts of atomic term, constants need to be declared
by the user.

We now consider terms defined using operators.  This includes the case
of unary prefix operators, which are in fact supported by Mark2, though
this is not reflected in the data type.  An infix which has been declared
may be used as a prefix operator if a declaration has been made which
assigns to that infix a default left argument; when the operator is
used as a prefix, an invisible left argument is present, equal to the
default; moreover, when a term is entered in binary form whose left
term happens to be the default left argument for its infix, the prover
will display it in unary form.

Operators are represented by nonempty strings made up entirely of special 
characters other than 
the two special characters allowed in atomic terms.

Operators of more than one character beginning with "^" are operator
variables.

All other operators are constant operators and must be declared.

A final refinement: an operator may actually end with alphanumerics:
it consists of (zero or more) special characters possibly followed by
a suffix consisting of one backquote "`" followed by zero or more
alphanumerics, with the length of the whole being nonzero.

Function terms are of the form [term]; a term enclosed in brackets is
a function term.  The appearance of bound variables is restricted to
appropriate function terms; the bound variable ?n may only appear in a
context within at least n nested brackets.

Case expression terms take the surface form ?x || ?y , ?z
This causes some peculiarities because the apparent subterm ?y , ?z
does not correspond to any actual term.  This is handled differently
in the current version of Mark2, but a related problem occurs.

*)

(* we now give code for functions which retrieve the first token of
a given kind (atomic term or operator) from a list of characters; it
has a companion function which returns the rest of the string *)

(* the tokenizer does not consult the declaration lists, but it
does recognize reserved constants and operators *)

(* the list of reserved operators *)

val RESERVED = ref([("bogus",(0,0))]);

(* RESERVED := nil; *)

fun isreserved x = foundin x (!RESERVED);


(* kinds of character *)

fun iscap x = x = "A" orelse x= "B" orelse x = "C" orelse x = "D"
	orelse x = "E" orelse x = "F" orelse x = "G" orelse x = "H"
	orelse x = "I" orelse x = "J" orelse x = "K" orelse x = "L"
	orelse x = "M" orelse x = "N" orelse x = "O" orelse x = "P"
	orelse x = "Q" orelse x = "R" orelse x = "S" orelse x = "T"
	orelse x = "U" orelse x = "V" orelse x = "W" orelse x = "X"
	orelse x = "Y" orelse x = "Z";

fun islowercase x = x = "a" orelse x= "b" orelse x = "c" orelse x = "d"
	orelse x = "e" orelse x = "f" orelse x = "g" orelse x = "h"
	orelse x = "i" orelse x = "j" orelse x = "k" orelse x = "l"
	orelse x = "m" orelse x = "n" orelse x = "o" orelse x = "p"
	orelse x = "q" orelse x = "r" orelse x = "s" orelse x = "t"
	orelse x = "u" orelse x = "v" orelse x = "w" orelse x = "x"
	orelse x = "y" orelse x = "z";

fun isspecial x = x = "!" orelse x = "@" orelse x = "#" orelse x = "$"
	orelse x = "%" orelse x = "^" orelse x = "&" orelse x = "*"
	orelse x = "=" orelse x = "+" orelse x = "-" orelse x = "<"
	orelse x = ">" orelse x = "/" orelse x = "," orelse x = ";"
	orelse x = "." orelse x = ":" orelse x = "~"
	orelse x = "|";

fun isdigit x = x = "0" orelse x = "1" orelse x = "2" orelse x = "3"
orelse x = "4" orelse x = "5" orelse x = "6" orelse x = "7"orelse x = "8" 
orelse x = "9";

(* remove whitespace *)

fun strip nil = nil |

	strip (" "::L) = strip L |
	strip ("\n"::L) = strip L |
	strip ("\t"::L) = strip L |
	strip L = L;

fun isalpha x = iscap x orelse islowercase x orelse isdigit x
	orelse x = "?" orelse x = "_";

(* get desired characters from a list of characters *)

fun getalpha nil = nil |
	getalpha (a::L) = if isalpha a then a::(getalpha L) else nil

and restalpha nil = nil |
	restalpha (a::L) = if isalpha a then restalpha L else (a::L);

fun getnumeral nil = nil |
	getnumeral (a::L) = if isdigit a then a::(getnumeral L) else nil

and restnumeral nil = nil |
	restnumeral (a::L) = if isdigit a then restnumeral L else (a::L);


fun getspecial nil = nil |

getspecial (a::L) = if isspecial a then (a::(getspecial L)) else 
	if a = "`" then (a::(getalpha L))
	else nil
and restspecial nil = nil |
	restspecial (a::L) = if isspecial a then restspecial L 
	else if a = "`" then restalpha L
	else (a::L);

(* integer character value *)

fun numvalue "0" = 0 |
	numvalue "1" = 1 |
	numvalue "2" = 2 |
	numvalue "3" = 3 |
	numvalue "4" = 4 |
	numvalue "5" = 5 |
	numvalue "6" = 6 |
	numvalue "7" = 7 |
	numvalue "8" = 8 |
	numvalue "9" = 9 |
	numvalue x = ~1;

(* fun evalnum nil = 0 |

	evalnum ("0"::L) = 0 + 10*(evalnum L) |
	evalnum ("1"::L) = 1 + 10*(evalnum L) |
	evalnum ("2"::L) = 2 + 10*(evalnum L) |
	evalnum ("3"::L) = 3 + 10*(evalnum L) |
	evalnum ("4"::L) = 4 + 10*(evalnum L) |
	evalnum ("5"::L) = 5 + 10*(evalnum L) |
	evalnum ("6"::L) = 6 + 10*(evalnum L) |
	evalnum ("7"::L) = 7 + 10*(evalnum L) |
	evalnum ("8"::L) = 8 + 10*(evalnum L) |
	evalnum ("9"::L) = 9 + 10*(evalnum L) |
	evalnum x = ~1; *)

fun evalnum nil = 0 |

	evalnum (x::L) = if isdigit x 
	then let val A = evalnum L in
	if A = ~1 then ~1 else (numvalue x) + (10*A)
	end 
	else ~1;

fun listtoint nil = 0 |

	listtoint (n::L) = n + 10*(listtoint L);

(* strips unwanted zeroes off fronts of numerals *)

fun stripzeroes nil = (0::nil) |

	stripzeroes (0::nil) = 0::nil |

	stripzeroes (0::L) = stripzeroes L |

	stripzeroes L = L;

(* strips unwanted zeroes off ends of reversed lists of digits
(our internal representation of integers) *)

fun stripzeroes2 L = rev(stripzeroes(rev L));


(* functions which extract the first atom represented in a list
of characters and return the rest of the list *)


fun prefirstatom s = let val A = getnumeral  s and B = getalpha s in

		if A <> nil andalso A = B then 
			Numeral (rev (stripzeroes(map numvalue A)))

		else 

		if B<>nil then 

			if hd B = "?" then

				let val C = getnumeral (tl B) in

				if C <> nil andalso C = tl B

				then BoundVar (evalnum (rev C)) 

				else FreeVar (implode B) end

			else Constant (implode B)

		else Constant "" end  (* conventional error value *)

and prerestfirstatom s  = let val A = getnumeral s and B = getalpha s in

		if A <> nil andalso A = B then restnumeral s

		else

		if B<>nil then restalpha s

		else s end   (* conventional error value *)

(* this function returns the first atomic term in the string s,
if any.  A locution like "stringtocon s = FreeVar s" asks whether
s is a free variable; in the case of constants, one also needs to
stipulate that s is not "" *)

fun stringtocon s = prefirstatom (strip (explode s));

fun firstatom s = prefirstatom (strip s);

fun restfirstatom s = prerestfirstatom (strip s);

(* functions for getting the first operator from a list of characters
and the rest of the list *)

fun prefirstop s = let val A = getspecial s in

			if A = nil then ConOp "" (* error value *)

			else if hd A = "^" andalso tl A <> nil

				then VarOp (implode A)

			else if isreserved (implode A)

				then ResOp (implode A)

				else ConOp (implode A)

			end;

(* this function gets the first operator from a string; see comments under
stringtocon *)

fun stringtoop s = prefirstop (strip (explode s));

fun firstop s = prefirstop (strip s);

fun restfirstop s = restspecial (strip s);

(* cleans up parentheses -- appears here because stringtoop is needed *)

fun deparenthesize1 (Parenthesis t) = t |

	deparenthesize1 t = t;

fun deparenthesize (Parenthesis t) = deparenthesize t |
	deparenthesize (Function s) = Function(deparenthesize s) |
	deparenthesize (Infix(x,ParOp s,y)) =Infix(deparenthesize x,
					stringtoop s,
					deparenthesize y) |
	deparenthesize (Infix(x,i,y)) = Infix(deparenthesize x,i,
					deparenthesize y) |
	deparenthesize (CaseExp(u,v,w)) = CaseExp(deparenthesize u,
					deparenthesize v,deparenthesize w) |
	deparenthesize t = t;


(* We now construct a family of functions culminating in the parser.
In this version, we do not allow user declared precedence, which is
found in the full implementation; most users have been content with
the APL precedence (all operators have same precedence, all operators
group to the right) which is the default in the full implementation *)

(* We begin with the declaration lists (needed by the display function
to handle prefix operators, as well as by the parser), follow with the
display functions, and conclude with the parser *)

(* the constant declaration list *)

val CONSTANTS = ref(["bogus"]);

fun isaconstant s = (stringtocon s = 
	Numeral (rev(stripzeroes(map (numvalue) (explode s)))))
	orelse foundinset s (!CONSTANTS);

(* USER COMMAND *)

fun declareconstant s = if s <> "" andalso stringtocon s = Constant s

	then if foundinset s (!CONSTANTS)

		then errormessage ("Constant "^s^" already declared")

		else CONSTANTS:=addtoset s (!CONSTANTS)

	else errormessage ("Ill-formed constant "^s^" cannot be declared");

(* operator declarations *)

(* operators require integer "left type" and "right type" parameters for
the stratification function *)


val OPERATORS = ref([("bogus",(1,2))]);

fun isoperator s = if stringtoop s = VarOp s then true

	else if stringtoop s = ResOp s then true

	else if s <> "" andalso stringtoop s = ConOp s then

		if foundin s (!OPERATORS) then true

		else false

	else false;


val defaultop = (0,0);

fun opof s = if (stringtoop s) = ResOp s then safefind defaultop s (!RESERVED)
		else safefind defaultop s (!OPERATORS);

fun lefttype s = (fn (a,b) => a) (opof s);
fun righttype s = (fn (a,b) => b) (opof s);

(* It is permissible to declare variable operators in order 
to record their type information *)

(* USER COMMAND *)

fun declaretypedinfix m n s = if stringtoop s = ResOp s

	then errormessage ("Reserved operator "^s^" cannot be redeclared")

	else if stringtoop s = VarOp s 

	then if foundin s (!OPERATORS) 

		then errormessage 
	("Variable operator "^s^" has already been typed")

		else OPERATORS:=
		addto s (m,n)(!OPERATORS)

	else if s <> "" andalso stringtoop s = ConOp s

		then  if foundin s (!OPERATORS)

		then errormessage ("Operator "^s^" has already been declared")

		else OPERATORS:=
		addto s (m,n) (!OPERATORS)

	else errormessage ("Ill-formed operator "^s^" cannot be declared");

(* Declaration of reserved operators:  not a user command! *)

fun reserveop m n s = if s <> "" andalso 
	stringtoop s = ConOp s andalso (not (isoperator s))

	then RESERVED:=addto s (m,n) (!RESERVED)

	else errormessage ("Improper operator reservation of "^s); 

(* reserveop 0 0 "||";

reserveop 0 0 ","; *)

(* declares the usual "flat" operators with only trivial type information *)

(* USER COMMAND *)

fun declareinfix s = declaretypedinfix 0 0 s;


(* lists of operators with special properties needed by the
stratification functions of the prover *)

val OPAQUE = ref["bogus"];
val SCOUT = ref[("bogus","bogus")];
val SCINLEFT = ref[("bogus","bogus")];
val SCINRIGHT = ref[("bogus","bogus")];

(* opaque operators are "opaque" to abstraction; one cannot define
a function in a way which essentially involves an opaque operator
(an opaque operator could appear in the name of a constant) *)

(* distinct from defined opaque "constant" operators (not used in 
any current theory, though they could be) are opaque variable operators;
an operator variable with declared type matches only operators of that
same type, while an opaque operator matches any operator, and for that
reason must observe the same restrictions on abstraction as an opaque
declared operator *)

fun isopaque s = s = "@!" orelse foundinset s (!OPAQUE);

fun istypedoperator s = (foundin s (!RESERVED) orelse foundin s (!OPERATORS))
	andalso not (isopaque s);

(* declare opaque operator *)

fun declareopaque s = if stringtoop s = ResOp s 

	then errormessage ("Reserved operator "^s^" cannot be made opaque")

	else if stringtoop s = VarOp s 

	then if foundin s (!OPERATORS) 

		then errormessage 
	("Reserved or variable operator "^s^" has already been typed")

		else (OPERATORS:=
		addto s (0,0)(!OPERATORS);OPAQUE:=addtoset s (!OPAQUE))

	else if s <> "" andalso stringtoop s = ConOp s

		then  if foundin s (!OPERATORS)

		then errormessage ("Operator "^s^" has already been declared")

		else (OPERATORS:=
		addto s (0,0) (!OPERATORS);OPAQUE:=addtoset s (!OPAQUE))

	else errormessage ("Ill-formed operator "^s^" cannot be declared");
 

(* scout = strongly Cantorian output; scinleft = strongly Cantorian input
(left argument) and scinright = strongly Cantorian input (right argument) 
strongly Cantorian = (in practice) belonging to some data type *)

val SCINSCOUT = ref ["bogus"];  (* list used in posting axiom 
				dependencies induced by scin/scout functions *)

fun scoutof s = safefind "" s (!SCOUT);

fun scinleftof s = safefind "" s (!SCINLEFT);

fun scinrightof s = safefind "" s (!SCINRIGHT);

fun isscout s = let val A = foundin s (!SCOUT) in
	(if A then SCINSCOUT:=addtoset (scoutof s) (!SCINSCOUT) else ();A) end;

fun isscinleft s = let val A = foundin s (!SCINLEFT) in
	(if A then SCINSCOUT:=addtoset (scinleftof s) (!SCINSCOUT) 
	else ();A) end;

fun isscinright s = let val A = foundin s (!SCINRIGHT) in
	(if A then SCINSCOUT:=addtoset (scinrightof s) (!SCINSCOUT) 
	else ();A) end;

(* assignment of scin/scout properties to theorems needs to
be witnessed by existence of theorems of appropriate forms and
will be handled later *)

(* prefix display declarations -- needed for display as well as
parser *)

(* variable prefix operators are needed! *)

(* the default left argument of an operator will be an atomic constant *)

val PREFIX = ref([("bogus","bogus")]);

(* PREFIX := nil; *)

fun prefixof s = safefind "" s (!PREFIX);

fun hasprefix s = foundin s (!PREFIX);

(* command to assign a default left argument to an operator;
this version only permits such an assignment to be made once *)

(* USER COMMAND *)

fun declareprefix s t = if hasprefix s then 

	errormessage ("Cannot reassign default left argument of "^s)

	else if (stringtoop s = ResOp s orelse (stringtoop s
	= ConOp s andalso isoperator s)) andalso
		isaconstant t

	then PREFIX := addto s t (!PREFIX)

	else errormessage ("Invalid prefix "^t^" proposed for operator "^s);

(* NOT a user command -- this command creates strict prefix operators,
which are those operators which have a prefix on the list equal to "" *)

(* it is necessary to be able to declare strict prefix operator
variables so that one can build structural tactics which will work
on prefix terms *)

fun isstrictprefix s = hasprefix s andalso prefixof s = "";

fun declarestrictprefix s = if (stringtoop s = ResOp s orelse 
	stringtoop s = VarOp s orelse (stringtoop s
	= ConOp s andalso isoperator s)) then PREFIX := addto s "" (!PREFIX)
	else errormessage 
	("Undeclared operator "^s^" cannot be declared strict prefix");

(* declarations of strictly unary operators *)

fun declaretypedunary n s = (declaretypedinfix 0 n s; declarestrictprefix s);

fun declareunary s = declaretypedunary 0 s;

fun declareunaryopaque s = (declareopaque s; declarestrictprefix s);

(* default type handling:  this allows the suppression of type labels
on variables which are understood to usually have a given type; the
type label infix : appears as a prefix operator in this case *)

val VARTYPES = ref [("bogus",Constant "")];

(* VARTYPES := nil; *)

fun hasdefaulttype v = foundin v (!VARTYPES);

fun defaulttypeof v = safefind (Constant "") v (!VARTYPES);

fun hasdtprefix ":" (FreeVar v) = hasdefaulttype v |

	hasdtprefix s t = false;

fun dtprefixof ":" (FreeVar v) = defaulttypeof v |

	dtprefixof s t = Constant "";

fun haseitherprefix s t = hasprefix s orelse hasdtprefix s t;

fun eitherprefixof s t = if hasprefix s then stringtocon (prefixof s)

			else dtprefixof s t;

(* USER COMMAND *)

fun notypeinfo v = if foundin v (!VARTYPES)

	then VARTYPES:=drop v (!VARTYPES)

	else errormessage ("No default type for "^v^" found to drop");

(* function for assigning types is found below; it requires
declaration checking *)

(* I might want to add scin/scout information *)

fun showdec s = if stringtocon s = Constant s 
		then if isaconstant s
		then errormessage (s^" is a declared constant")
		else errormessage ("Undeclared constant "^s)
		else if stringtocon s = 
		Numeral (rev (stripzeroes(map numvalue (explode s))))

		then errormessage "Numerals are predeclared"

		else if (stringtoop s = ResOp s)
			then if isopaque s 
			then errormessage ("Opaque reserved operator "^s)
			else if isoperator s
			then errormessage 
			("Reserved operator "^s^" left type:  "
			^(makestring (lefttype s))^" right type: "
				^(makestring(righttype s)^
				" left arg (if any): "^(prefixof s)))
			else errormessage ("Undeclared reserved operator?!")
		else if (stringtoop s = ConOp s)
			then if isopaque s 
			then errormessage ("Opaque declared operator "^s)
			else if isoperator s
			then errormessage ("Declared operator "^s^
				" left type: "
			^(makestring (lefttype s))^" right type: "
				^(makestring(righttype s))^
				(if hasprefix s then 
				if prefixof s = "" then " Prefix operator only"
				else " Default left argument:  "^(prefixof s)
				else " Infix argument only"))
		
			else errormessage ("Undeclared operator")
		
		else if stringtoop s = VarOp s andalso foundin s (!OPERATORS)
		then errormessage ("Typed variable operator "^s^" left type: "
		^(makestring (lefttype s))^" right type: "^
		(makestring(righttype s))^
		(if hasprefix s then " (strict prefix)" else ""))

		else if stringtoop s = VarOp s andalso isopaque s
		then errormessage ("Opaque operator variable "^s^
		(if hasprefix s then " (strict prefix)" else ""))

		else if stringtoop s = VarOp s then errormessage
			("Undeclared operator variable "^s)

		else errormessage "No applicable declaration";


(* simple display function *)

fun opdisplay (ConOp s) = s |

	opdisplay (VarOp s) = s |

	opdisplay (ResOp s) = s |

	opdisplay (ParOp s) = "{"^s^"}";

(* the master precedence list *)

val PRECEDENCES = ref ([("bogus",0)]);

(* PRECEDENCES:=nil; *)

(* default precedence *)

val DEFAULTPREC = ref 0;

(* user command to set precedence of an operator *)

fun setprecedence s n = if n<0 then setprecedence s 0 
			else PRECEDENCES := strongadd s n (!PRECEDENCES);

(* user command to set default precedence *)

fun setdefaultprec n = if n < 0 then setdefaultprec 0 else
			DEFAULTPREC := n;

(* user command to reset precedences to standard *)

fun clearprecs () = (PRECEDENCES := nil; DEFAULTPREC := 0);

fun precedenceof s = safefind (!DEFAULTPREC) s (!PRECEDENCES);

(* sophisticated precedence commands *)

fun preraiseprecs n nil = nil |
preraiseprecs n ((s,m)::L) = (s,if m>=n then m+2 else m)::(preraiseprecs n L);

fun raiseprecs n = PRECEDENCES := preraiseprecs n (!PRECEDENCES);

(* USER COMMANDS (5) *)

(* these commands allow precedences to be set relative to an
existing precedence -- either the same, just above, or just below
(making insertions in the latter two cases) and with left or
right grouping as indicated *)

fun sameprec s t = setprecedence s (precedenceof t);

fun defaultprecsame s = setdefaultprec (precedenceof s);

fun leftprecabove s t = (raiseprecs ((precedenceof t)+2);
                           setprecedence s ((precedenceof t)+1+
                                           ((precedenceof t) mod 2)));

fun rightprecabove s t = (raiseprecs ((precedenceof t)+2);
                           setprecedence s ((precedenceof t)+2-
                                           ((precedenceof t) mod 2)));

fun leftprecbelow s t = (raiseprecs ((precedenceof t));
                           setprecedence s ((precedenceof t)-1+
                                           ((precedenceof t) mod 2)));

fun rightprecbelow s t = (raiseprecs ((precedenceof t));
                           setprecedence s ((precedenceof t)-2+
                                           ((precedenceof t) mod 2)));


(* NORULES supports a mode in which embedded theorems are not
displayed (when it is true) *)

val NORULES = ref false;

(* in the old version, =>> and <<= were rule infixes as well, but they
are not in this version (they are operators linking a pair of theorems) *)

fun ruleinfix s = s = "=>" orelse s = "<=";

fun stickiness (Infix(x,s,y)) = if (!NORULES) andalso

	ruleinfix (opdisplay s) then stickiness y else

	precedenceof (opdisplay s) |

	stickiness (CaseExp(u,v,w)) = precedenceof "||" |

	stickiness x = 0;

(* this refers to surface form *)

fun isinfixterm (Infix(x,s,y)) = if (!NORULES) andalso
	ruleinfix (opdisplay s) then isinfixterm y else true |

	isinfixterm (CaseExp(u,v,w)) = true |

	isinfixterm x = false;

fun isprefixterm (Infix(x,s,y)) = (x = eitherprefixof (opdisplay s) y) |

	isprefixterm x = false;

(* parentest x s b tells us whether term x needs to be parenthesized
when it is term b (left term has b=0, right term has b=1) in an infix
term with infix s *)

(* there is a difficulty with parentheses around prefix terms to the
right of an infix; such parentheses are sometimes eliminable, but this
depends on context in a way which is hard to implement. *)

fun parentest x s b = ((not (!NORULES)) 
	orelse (not (ruleinfix (opdisplay s)))) 
	andalso (isinfixterm x andalso ((stickiness x <
	precedenceof (opdisplay s)) orelse
	(stickiness x = precedenceof (opdisplay s) andalso 
	((stickiness x) mod 2 = b))));

(* pp for "possible parenthesis" *)

fun pp x s b p = if parentest x s b then p else ""; 

(* function for converting preparsed terms to correct form *)

fun reassociate1 (Infix(x,s,Infix(y,t,z))) =

	if ((precedenceof (opdisplay s) > precedenceof (opdisplay t))
	orelse (precedenceof (opdisplay s) = precedenceof (opdisplay t)
	andalso ((precedenceof (opdisplay s)) mod 2) = 1))
	andalso y <> eitherprefixof (opdisplay t) z

	then Infix(reassociate1(Infix(x,s,y)),t,z)

	else (Infix(x,s,Infix(y,t,z))) |

	reassociate1 t = t;

fun reassociate (Parenthesis t) = Parenthesis (reassociate t) |

	reassociate (Function t) = Function (reassociate t) |

	reassociate (Infix(x,s,y)) = 
		reassociate1 (Infix(reassociate x,s,reassociate y)) |

	reassociate t = t;

(* baredisplay should now handle user-defined precedence correctly *)

fun baredisplay (Constant s) = s |

	baredisplay (Numeral n) = implode(rev (map makestring n)) |

	baredisplay (FreeVar s) = s |

	baredisplay (BoundVar s) = "?"^(makestring s) |

	baredisplay (Infix(t,i,u)) = let val T = baredisplay t in

		(* the baredisplay function does not use 
		default type information; this avoids trouble
		for load and save commands *)

		if T = prefixof (opdisplay i)

			then (opdisplay i)^" "^(pp u i 1 "(")^
			(baredisplay u)^(pp u i 1 ")")

			else (pp t i 0 "(")^T^(pp t i 0 ")")^" "
			^(opdisplay i)^" "
			^(pp u i 1 "(")
			^(baredisplay u)^(pp u i 1 ")") end |

	baredisplay (Function t) = "["^(baredisplay t)^"]" |

	(* display of case expressions "cheats"; it relies on the
	surface form of case expressions as complex infix expressions *)

	(* this works because the display functions are independent
	of declarations *)

	baredisplay (CaseExp(t,u,v)) = baredisplay 
		(Infix(t,ResOp("||"),Infix(u,ResOp(","),v))) |

	(* the case for Parenthesis handles highlighting the current subterm *)

	baredisplay (Parenthesis t) = "{"^(baredisplay t)^"}";

val CURSOR = ref 0;

fun bumpcursor s = (CURSOR:=(!CURSOR)+(length(explode s));s);

val MARGIN = ref 50;

fun setline n = MARGIN:=n;

fun spaces 0 = "   " |

	spaces n = (spaces (n-1))^"   ";

fun predashes 0 = "" |
	predashes 1 = " " |
	predashes 2 = "  " |
        predashes 3 = "   " | 
	predashes n = if n<0 then "" else (predashes (n-1))^"-";

fun dashes() = predashes (!MARGIN);

fun Newline() = (CURSOR:=0;"\n");

fun maybebreak d = if (!CURSOR) >= (!MARGIN)

		then (Newline()^bumpcursor(spaces d))

		else ""; 


fun predisplay d (Constant s) = 
	(bumpcursor s) |

	predisplay d (Numeral n) = (bumpcursor
		(implode(rev (map makestring n)))) |

	predisplay d (FreeVar s) =(bumpcursor s) |

	predisplay d (BoundVar s) = 
	(bumpcursor ("?"^(makestring s))) |

	predisplay d (Infix(t,i,u)) = 

		if (!NORULES) andalso ruleinfix (opdisplay i)

			then predisplay d u

		else let val T = baredisplay t in

		if T = baredisplay(eitherprefixof (opdisplay i) u)

			then 

			(bumpcursor (opdisplay i))
			^" "
			^(bumpcursor (pp u i 1 "("))
			^(predisplay (if parentest u i 1 then d+1 else d) u)
			^(bumpcursor (pp u i 1 ")"))

			else (bumpcursor (pp t i 0 "("))
			^(predisplay (if parentest t i 0 then d+1 else d) t)
			^(bumpcursor (pp t i 0 ")"))
			^(bumpcursor " ")
			^(maybebreak d)
			^(bumpcursor(opdisplay i))
			^(bumpcursor " ")
			^(bumpcursor (pp u i 1 "("))
			^(predisplay (if parentest t i 0 then d+1 else d) u)
			^(bumpcursor (pp u i 1 ")")) end |

	predisplay d (Function t) = (bumpcursor "[")^
				(predisplay (d+1) t)^(bumpcursor "]") |

	(* display of case expressions "cheats"; it relies on the
	surface form of case expressions as complex infix expressions *)

	(* this works because the display functions are independent
	of declarations *)

	predisplay d (CaseExp(t,u,v)) = predisplay d
		(Infix(t,ResOp("||"),Infix(u,ResOp(","),v))) |

	(* the case for Parenthesis handles highlighting the current subterm *)

	predisplay d (Parenthesis t) = (bumpcursor "{")
				^(predisplay (d+1) t)^(bumpcursor "}");


fun display t = (CURSOR:=0;(spaces 0)^(predisplay 0 t));

(* the parser *)

(* the parser engine works, like the tokenizer, with a list of characters *)

(* functions for extracting projections from pairs *)

fun p1(x,y) = x;

fun p2(x,y) = y;

(* the only change involved in user-defined precedence is recording
of user-supplied parentheses *)

fun getfirstterm L =

	if (strip L) = nil then (Constant "", nil)
	else let val A = firstatom L and B = strip(restfirstatom L) in
	if A <> Constant ""
		then (* first term is atomic *)
		(A,B)
	else let val C = firstop L and D = strip(restfirstop L) in
	if C <> ConOp ""
		then (* first term has a prefix operator *)
		let val E = getterm D in
		if haseitherprefix (opdisplay C) (p1 E) then
			if p1 E = Constant "" then (Constant "",nil)
			else ((* Parenthesis *)(
				Infix(eitherprefixof(opdisplay C)(p1 E),
				C,p1 E)),p2 E)
			
		else (Infix(Constant "",C,p1 E),p2 E) end
	else if hd (strip L) = "["
		then (* function term *)
		let val G = getterm (tl(strip L)) in
		if p1 G = Constant "" orelse p2 G = nil orelse
			hd(p2 G) <> "]"
			then (Constant "", nil)
		else (Function(p1 G),strip(tl(p2 G)))
		end
	else if hd (strip L) = "("
		then (* parenthesis term *)
		let val G = getterm (tl(strip L)) in
		if p1 G = Constant "" orelse p2 G = nil 
			orelse hd(p2 G) <> ")"
			then (Constant "", nil)
		else (Parenthesis (p1 G),strip(tl(p2 G)))
		end
	else (Constant "",nil)
	end
	end

and getterm L = let val (A,B) = getfirstterm L in
if A = Constant "" 
	then (Constant "",nil)
else if B = nil orelse hd B = "]" orelse hd B = ")"
	then (A,B)
else let val C = firstop B and D = strip(restfirstop B) in
	if C = ConOp "" then (Constant "",nil)
	else let val E = getterm D in
		if p1 E = Constant "" then (Constant "",nil)
		else (Infix(A,C,p1 E),p2 E)
		end
	end
end;


(* the parser reads case expressions as a particular kind of infix
expression; the casefix function rectifies this situation and rejects
expressions of the form ?x || ?y where ?y is not a pair. *)

fun casefix (Infix(x, ResOp "||",Infix(y,ResOp",",z))) =

		CaseExp(casefix x,casefix y,casefix z) |

	casefix (Infix(x,ResOp"||",y)) = 
	(errormessage "Ill-formed case expression"; Constant "") |

	casefix (Function t) = Function (casefix t) |

	casefix (Infix (x,s,y)) = Infix(casefix x,s,casefix y) |

	casefix t = t;

fun parse s = let val A = getterm(explode s) in if p2 A = nil then 
	casefix(deparenthesize(reassociate(p1 A)))
	else Constant "" end;

(* the theorem-embedding infixes which signal intentions to rewrite *)

(* reserveop 0 0 "=>";

reserveop 0 0 "<="; *)

(* they are actually declared in the setup command at the end *)


(* operators of built-in arithmetic *)

(* the declarations are actually made later in the setup command *)

(* reserveop 0 0 "+!"; reserveop 0 0 "-!"; reserveop 0 0 "*!"; reserveop 0 0 "/!";
reserveop 0 0 "%!"; reserveop 0 0 "<!"; reserveop 0 0 ">!"; 
reserveop 0 0 "=!"; *)

fun arithop s = s = "+!" orelse s = "-!" orelse s = "*!" orelse s = "/!"
orelse s = "%!" orelse s = "<!" orelse s = ">!" orelse s = "=!";

(* the rulefree function certifies a term as free of "execution
behaviour" *)

(* execution behaviour refers to presence of embedded theorems,
operations of the built-in arithmetic, or case expressions whose
hypotheses are truth values or equations with first term true. *)

(* declarations for functional programming *)

val PROGRAMS = ref ([("bogus","bogus")]);

(* command setprogram to bind a program to a constant or operator 
is found below *)

(* USER COMMAND *)

(* user program to remove any tactic bound to a function or operator *)

fun deprogram s = PROGRAMS := drop s (!PROGRAMS);

fun hasprogram s = foundin s (!PROGRAMS);

fun programof s = safefind "" s (!PROGRAMS);

(* moved here from near changehlevel below because of needs of 

enhanced higher-order matching  *)

fun changelevel source target (BoundVar s) = 
	if s <= source andalso s <= target then BoundVar s
	else if s <= source andalso s > target then Constant ""
	else BoundVar (target + (s - source)) |
	changelevel source target (Function t) =

		let val TRY = changelevel source target t in
		if TRY = Constant "" then Constant "" else Function TRY end |
	changelevel source target (Infix(x,i,y)) =

		let val TRY1 = changelevel source target x
		and TRY2 = changelevel source target y in
		if (TRY1 = Constant "" andalso ((not(hasprefix (opdisplay i)))
			orelse prefixof (opdisplay i) <> ""))
		orelse TRY2 = Constant ""
		then Constant "" else Infix(TRY1,i,TRY2)  end |
	changelevel source target (CaseExp(u,v,w)) =

		let val TRY1 = changelevel source target u
		and TRY2 = changelevel source target v
		and TRY3 = changelevel source target w in

		if TRY1 = Constant "" orelse TRY2 = Constant "" 
			orelse TRY3 = Constant ""
		then Constant ""
		else (CaseExp(TRY1,TRY2,TRY3))
		end |
	changelevel source target (Parenthesis u) =

		let val TRY = changelevel source target u in

		if TRY = Constant "" then Constant "" else Parenthesis TRY 
		end |

	changelevel source target t = t;


fun rulefree (Infix(Numeral m,ResOp s,Numeral n)) = not(arithop s) |

	rulefree (Infix(x,ResOp s, y)) = (not(ruleinfix s))

	andalso rulefree x andalso rulefree y |

	rulefree (CaseExp(Infix(Constant"true",ResOp"=",x),y,z)) = false |

	rulefree (CaseExp (u,v,w)) = u <> Constant "true" andalso
	u <> Constant "false" andalso rulefree u andalso rulefree v
	andalso rulefree w |

	rulefree (Function t) = rulefree t |

	rulefree (Infix(x,i,y)) = rulefree x andalso rulefree y |

	rulefree t = true;

(* list of "locally free" bound variables on which a term
depends -- obviously this needs the level as a parameter *)

fun boundvarlist level (BoundVar s) = if s=0 then nil else [s] |

	boundvarlist level (Infix(u,i,v)) = union (boundvarlist level u) 
		(boundvarlist level v) |

	boundvarlist level (Function t) = dropfromset (level + 1) 
		(boundvarlist (level+1) t) |

	boundvarlist level (CaseExp(u,v,w)) = union
		(boundvarlist level u) (union
		(boundvarlist level v)(boundvarlist level w)) |

	boundvarlist level t = nil;

(* the "stratification" function for "predicate" abstraction:
roughly, no bound variables to occur free in applied position *)

(* it's actually rather more elegantly described now; the constraint
described above is obtained without any direct reference to bound
variables per se *)

fun metahead level n (Function t) = metahead (level+1) (n-1) t |

	metahead level n (Infix(x,ResOp"@!",y)) = metastrat level y
		andalso metahead level (n+1) x |

	metahead level n (FreeVar x) = true |

	metahead level n (Infix(x,ResOp"=>",y)) =

		metahead level n y |

	metahead level n (Infix(x,ResOp"<=",y)) =

		metahead level n y |

	metahead level n (Parenthesis t) = metahead level n t |

	metahead level n (CaseExp(u,v,w)) =

		metahead level n v andalso metahead level n w |

	metahead level n t = (n<=0 andalso metastrat level t)

and	metastrat level (Infix (x,ResOp"@!",y)) = 

	metahead level 1 x andalso metastrat level y |

	metastrat level (Infix(x,i,y)) = 
	metastrat level x andalso metastrat level y |

	metastrat level (Function t) = metastrat (level+1) t |

	metastrat level (CaseExp(t,u,v)) = metastrat level t 
		andalso metastrat level u andalso metastrat level v |

	metastrat level (Parenthesis t) = metastrat level t |

	metastrat level t = true;


(* the master declaration checking function; it checks constants,
operators, and bound variables for meaningfulness *)

(* declarecheck sends error messages (if the quiet parameter is false), 
but only for the first error it
encounters *)

(* design decision:  we do not check for meaningless m|-|n, because
such things appear to be harmless (and even potentially useful) *)

fun declarecheck quiet (level:int) (Constant s) = 
		if isaconstant s then true 
	else

	((if quiet then () else 
	errormessage ("Undeclared constant "^s^" found"));false) |

	declarecheck quiet level (Numeral n) = true |

	declarecheck quiet level (FreeVar s) = true |

	declarecheck quiet level (BoundVar s) = if s<=level 
		then true else ((if quiet then () else errormessage 
	("Meaningless bound variable ?"^(makestring s)^" found"));false) |

	declarecheck quiet level (Function t) = metastrat level (Function t)
		andalso
		declarecheck quiet ((level:int)+1) t |

	declarecheck quiet level (CaseExp(u,v,w)) = 
		(declarecheck  quiet level u) 
		andalso
		(declarecheck quiet level v) andalso 
		(declarecheck quiet level w) |

	declarecheck quiet level (Infix(x,ResOp"@!",y)) = 

		declarecheck quiet level x andalso declarecheck quiet level y
		andalso metahead level 1 x | 

	declarecheck quiet level (Infix(u,ResOp s,v)) =

		if isstrictprefix s
		then if u = Constant "" then declarecheck quiet level v
		else ((if quiet then () else errormessage 
		("Exclusive prefix operator "^s^" used as infix"));false)
		else (declarecheck quiet level u) 
		andalso
		(declarecheck quiet level v) |

	declarecheck quiet level (Infix(u,VarOp s,v)) = 


		if stringtoop s <> VarOp s 
		then ((if quiet then () 
		else errormessage ("Ill-formed infix variable "^s));false)
		else if isstrictprefix s 
		then if u = Constant "" then declarecheck quiet level v
		else ((if quiet then () else errormessage 
		("Exclusive prefix operator "^s^" used as infix"));false)
		else (declarecheck  quiet level u) 
		andalso
		(declarecheck quiet level v) |

	declarecheck quiet level (Infix(u,ConOp s,v)) = 
		if isstrictprefix s  
		then if u = Constant "" then 
		(declarecheck quiet level v)

		andalso if isoperator s then true 
		else ((if quiet then () 
		else errormessage ("Undeclared operator "^s^" found"));false)

		else ((if quiet then () else errormessage 
		("Exclusive prefix operator "^s^" used as infix"));false)

		else (declarecheck  quiet level u) 
		andalso
		(declarecheck quiet level v)

		andalso if isoperator s then true 
		else ((if quiet then () 
		else errormessage ("Undeclared operator "^s^" found"));false) |

	declarecheck quiet level (Parenthesis u) = 

		((if quiet then () else errormessage ("Braces found"));false);

(* stratification checking *)

(* reserveop 0 0 ":"; *)  (* the type label (retraction) infix *)

(* the actual declaration is deferred to setup *)

(* the stratification function takes as its parameter a local
type and generates a list of lists of type assignments to bound variables,
which will be empty if there is no consistent type assignment; otherwise,
the first of these lists will be the types fixed for bound variables
in the given context, while subsequent lists record known "relative"
types which may be shifted by a constant amount *)

(* utilities which operate on lists of type assignments *)

fun shifttype n nil = nil |

	shifttype (n:int) ((p,q)::L) = ((p,q+n)::shifttype n L);

(* finds a candidate for the displacement between two type
assignments -- does not check for consistency! *)

(* returns nil if there is no point of contact between the lists *)

fun typediff nil L = nil |

	typediff ((p,q:int)::L) M = let val A = find p M in
		if A = nil then typediff L M  else [q -(hd A)] end;

(* shiftmerge, given two type assignment lists, returns the list of
the two if they have no point of contact, returns nil if they are
inconsistent, and returns the merged list otherwise (shifting the
second list by the amount reported by typediff) *)

(* the first two clauses allow for considerable simplification; "floating"
lists with zero or one entry do not supply any information, but may
not merge using the third clause *)

fun shiftmerge L nil = [L] |

	shiftmerge L (x::nil) = [L] |

	shiftmerge L M = if typediff L M = nil then [L, M]
	else merge L (shifttype (hd (typediff L M)) M); 

(* crushtypes simplifies a list of type assignment lists, merging any
lists which have a point of contact and preserving the special role
of the head of the list (whose types must be fixed) *)

fun crushtypes nil = nil |

	crushtypes (L::nil) = (L::nil) |

	crushtypes (L::(M::rest)) = let val A = crushtypes (M::rest)
		in if A = nil then nil else let val (N::rest2) = A in
		if shiftmerge L N = nil then nil
		else if shiftmerge L N = [L,N] 
		then ((crushtypes (L::rest2))@[N])
		else crushtypes ((shiftmerge L N)@rest2) end end;

(* merges two type lists *)

fun mergetypes nil L = nil |

		mergetypes M nil = nil |

		mergetypes (L::rest1) (M::rest2) = 

			if merge L M = nil then nil

			else crushtypes((merge L M)@rest1@rest2);

(* checkappend is used in strat for "floating" a type list; we check that the
list we are "floating" isn't nil before we prepend [nil] to it *)

fun checkappend L M = if M = nil then nil else L@M;


(* the main stratification function *)

(* another stratification function will be needed by the
definition function -- it will type free variables rather
than bound variables *)

val CHECKTYPE = ref 0;

fun strat level localtype (Constant s) = [nil] |

	strat level localtype (FreeVar s) = [nil] |

	strat level localtype (Numeral s) = [nil] |

	strat level localtype (BoundVar s) = if s = 0 then [nil] else 
		[[(s,localtype)]] |

	strat level localtype (Function s) = map (drop (level+1))
		(mergetypes
			(strat (level+1) (localtype-1) s)
			[[(level+1,localtype-1)]]) |

	strat level localtype (CaseExp(t,u,v)) =

		mergetypes((checkappend[nil](strat level localtype t)))
		(mergetypes(strat level localtype u)
			(strat level localtype v)) |

	strat level localtype (Infix(t,ResOp":",u)) =

		mergetypes (strat level (localtype+1) t) 
		(checkappend [nil] (strat level localtype u)) |

	strat level localtype (Infix(Constant f,ResOp "@",t)) =
		crushtypes(checkappend
		(if level = 0 
			orelse isscout f orelse isscinright f 
			then [nil] else [])
		(strat level localtype t)) |

	strat level localtype (Infix(t,i,u)) =

		if istypedoperator (opdisplay i)

		then
		crushtypes(checkappend
		(if level = 0 orelse isscout (opdisplay i) then [nil] else [])
		(mergetypes

		(checkappend(if level = 0 
			orelse isscinleft (opdisplay i) then [nil] else [])
		(strat level (lefttype(opdisplay i)+localtype) t))

		(checkappend(if level = 0 orelse
			isscinright (opdisplay i) then [nil] else [])
		(strat level (righttype(opdisplay i)+localtype) u))))

		else (* case of opaque or undeclared variable operators *)

		if boundvarlist level (Infix(t,i,u)) = nil
		andalso strat level 0 t <> nil
		andalso strat level 0 u <> nil
		then [nil] else nil;

fun isstratified level t = strat level 0 t <> nil;

(* USER COMMAND *)

(* delayed to here because it uses declaration and stratification
checking *)

fun defaulttypeinfo v t = if stringtocon v = FreeVar v andalso
	declarecheck false 0 (parse t) (* andalso isstratified 0 (parse t) *)

	then VARTYPES := strongadd v (parse t) (!VARTYPES)

	else errormessage 
("Declaration or syntax error in assigning type "^t^" to variable "^v);

(* the prover environment comes into view! *)

(* the prover environment consists of the following elements:

	name of environment (a string)

	"format" of environment (a term, used to indicate parameters
		of a parameterized theorem/tactic)

	left side of equation being proved (a term)

	right side of equation being proved (a term)

	current position in term (a list of booleans, true = right,
		false = left, the step into a function term is
		either right or left indifferently)

	current level and "hypothesis level" (two integers)

	list of local hypotheses (a list of "theorems" derived
		from hypotheses of case expressions -- a triple
		consisting of two terms to be equated and an
		integer coding the "sense" (positive, negative,
		or inactive) of the hypothesis)

	dependencies of current environment -- only the traditional
	kind will be considered; the new definition and theorem-text
	dependencies will be maintained separately

The theorem data structure is almost the same, except that it does
not have position-dependent components *)

(* a workhorse function -- apply a function to a term at a
position *)

fun applyat f nil t = f t |

	applyat f (a::L) (Constant s) = 
		(errormessage "Subterm error";Constant s) | 
	applyat f (a::L) (FreeVar s) = 
		(errormessage "Subterm error";FreeVar s) | 
	applyat f (a::L) (BoundVar s) = 
		(errormessage "Subterm error";BoundVar s) | 
	applyat f (a::L) (Numeral s) = 
		(errormessage "Subterm error";Numeral s) | 

	applyat f (a::L) (Function t) = Function (applyat f L t) |

	applyat f (false::L) (Infix(u,i,v)) =
		if u = Constant ""
		then (errormessage "Subterm error";(Infix(u,i,v)))
		else (Infix(applyat f L u,i,v)) |
	applyat f (true::L) (Infix(u,i,v)) =
		(Infix(u,i,applyat f L v)) |

	applyat f (false::L) (CaseExp(u,v,w)) =
		CaseExp(applyat f L u,v,w) |

	applyat f (true::(false::L)) (CaseExp(u,v,w)) =
		CaseExp(u,applyat f L v,w) |
	applyat f (true::(true::L)) (CaseExp(u,v,w)) =
		CaseExp(u,v,applyat f L w) |

	(* the Parenthesis case below helps prevent the 
	prover from issuing an error message when just looking
	at the virtual subterm *)

	applyat f (true::nil) (CaseExp(u,v,w)) =

		((let val A = f (Infix(v,ResOp",",w)) in
		if A = (Infix(v,ResOp",",w)) orelse
		A = Parenthesis((Infix(v,ResOp",",w))) then ()
		else errormessage "Virtual subterm of case expression" end);
		(CaseExp(u,v,w)));


(* the prover environment data type *)
(* this is a structure with nine fields as indicated above *)

fun ename (na,fo,lt,rt,po,lev,hlev,hyps,deps) = na;
fun formatof (na,fo,lt,rt,po,lev,hlev,hyps,deps) = fo;
fun leftside (na,fo,lt,rt,po,lev,hlev,hyps,deps) = lt;
fun rightside (na,fo,lt,rt,po,lev,hlev,hyps,deps) = rt;
fun position (na,fo,lt,rt,po,lev,hlev,hyps,deps) = po;
fun level (na,fo,lt,rt,po,lev,hlev,hyps,deps) = lev;
fun hlevel (na,fo,lt,rt,po,lev,hlev,hyps,deps) = hlev;
fun hypslist (na,fo,lt,rt,po,lev,hlev,hyps,deps) = hyps;
fun deps (na,fo,lt,rt,po,lev,hlev,hyps,deps) = deps;

(* functions which change environment fields to given values *)

fun changeename na2 (na,fo,lt,rt,po,lev,hlev,hyps,deps) = 
	(na2,fo,lt,rt,po,lev,hlev,hyps,deps);
fun changeformatof fo2 (na,fo,lt,rt,po,lev,hlev,hyps,deps) =
	(na,fo2,lt,rt,po,lev,hlev,hyps,deps);
fun changeleftside lt2 (na,fo,lt,rt,po,lev,hlev,hyps,deps) =
	(na,fo,lt2,rt,po,lev,hlev,hyps,deps);
fun changerightside rt2 (na,fo,lt,rt,po,lev,hlev,hyps,deps) =
	(na,fo,lt,rt2,po,lev,hlev,hyps,deps);
fun changeposition po2 (na,fo,lt,rt,po,lev,hlev,hyps,deps) =
	(na,fo,lt,rt,po2,lev,hlev,hyps,deps);
fun changeelevel lev2 (na,fo,lt,rt,po,lev,hlev,hyps,deps) =
	(na,fo,lt,rt,po,lev2,hlev,hyps,deps);
fun changeehlevel hlev2 (na,fo,lt,rt,po,lev,hlev,hyps,deps) =
	(na,fo,lt,rt,po,lev,hlev2,hyps,deps);
fun changehypslist hyps2 (na,fo,lt,rt,po,lev,hlev,hyps,deps)=
	(na,fo,lt,rt,po,lev,hlev,hyps2,deps);
fun changedeps deps2 (na,fo,lt,rt,po,lev,hlev,hyps,deps)=
	(na,fo,lt,rt,po,lev,hlev,hyps,deps2);

(* functions which apply given functions to environment fields *)

fun changeename2 f (na,fo,lt,rt,po,lev,hlev,hyps,deps) = 
	(f na,fo,lt,rt,po,lev,hlev,hyps,deps);
fun changeformatof2 f (na,fo,lt,rt,po,lev,hlev,hyps,deps) =
	(na,f fo,lt,rt,po,lev,hlev,hyps,deps);
fun changeleftside2 f (na,fo,lt,rt,po,lev,hlev,hyps,deps) =
	(na,fo,f lt,rt,po,lev,hlev,hyps,deps);
fun changerightside2 f (na,fo,lt,rt,po,lev,hlev,hyps,deps) =
	(na,fo,lt,f rt,po,lev,hlev,hyps,deps);
fun changeposition2 f (na,fo,lt,rt,po,lev,hlev,hyps,deps) =
	(na,fo,lt,rt,f po,lev,hlev,hyps,deps);
fun changelevel2 f (na,fo,lt,rt,po,lev,hlev,hyps,deps) =
	(na,fo,lt,rt,po,f lev,hlev,hyps,deps);
fun changehlevel2 f (na,fo,lt,rt,po,lev,hlev,hyps,deps) =
	(na,fo,lt,rt,po,lev,f hlev,hyps,deps);
fun changehypslist2 f (na,fo,lt,rt,po,lev,hlev,hyps,deps)=
	(na,fo,lt,rt,po,lev,hlev,f hyps,deps);
fun changedeps2 f (na,fo,lt,rt,po,lev,hlev,hyps,deps)=
	(na,fo,lt,rt,po,lev,hlev,hyps,f deps);

(* the current prover environment *)

val ENV = ref("",Constant "", Constant "", Constant "",
	[true],0,0,[(Constant"",Constant"",[true],0,0)],["bogus"]);

(* apply a function to the environment *)

fun envmod f = ENV:=f (!ENV);

(* reference for temporarily posting new dependencies *)

val NEWDEPS = ref ["bogus"];

(* dependency posting function *)

fun postdeps() = (envmod(changedeps2 (union(!NEWDEPS)))
	;NEWDEPS:=nil);

fun dropdeps() = NEWDEPS:=nil;

(* term viewing functions *)

(* these are actually identity functions with side effects *)

val PROMPT = ref true;

fun termprompts() = PROMPT := not (!PROMPT);

fun showterm prompt t = (if (!VERBOSITY) = 2 then 
(output(std_out,
(if (!PROMPT) then ("\n"^prompt^":") else "")
^"\n\n"^(display t)^(if (!GUIMODE) then ((!Returns)^". . .") else "")
^(!Returns));
flush_Out(std_out)) else ();t);

fun exec f = envmod (changerightside2 (applyat f
	(position(!ENV))));

(* USER COMMAND *)

(* look at current subterm *)

fun lookhere() = exec (showterm "Local term display");

(* variables controlling the look display *)

val LOCAL_DISPLAY = ref true;

val GLOBAL_DISPLAY = ref true;

(* USER COMMAND *)

(* look at current subterm and at top of right side of equation *)

(* insert a "parenthesis" temporarily to highlight current subterm *)

fun look() = (exec Parenthesis;
	envmod(changerightside2 (if (!GLOBAL_DISPLAY) 
	then (showterm "Global term display") else (fn x => x))); 
	exec deparenthesize1;
	lookhere());

(* USER COMMANDS (3) *)

(* control the look display *)

fun localdisplayoff() = (LOCAL_DISPLAY:=false;GLOBAL_DISPLAY:=true;look());

fun globaldisplayoff()= (LOCAL_DISPLAY:=true;GLOBAL_DISPLAY:=false;look());

fun bothdisplays()= (LOCAL_DISPLAY:=true;GLOBAL_DISPLAY:=true;look());

(* USER COMMAND *)

(* look at the left side of the equation under construction *)

fun lookback() = envmod(changeleftside2 (showterm "Initial term display"));

(* term starting functions appear below after the environment
saving commands, which have to appear after the declaration of
the theorem list *)


val SWAPTERM = ref (Constant "");

(* USER COMMAND *)

(* interchange the left and right sides of the equation under
construction *)

fun workback() =  (SWAPTERM:=leftside(!ENV);
	envmod(changeleftside (rightside(!ENV)));
	envmod(changerightside (!SWAPTERM));
	envmod(changeposition nil);
	envmod(changeelevel 0); envmod(changeehlevel 0);
	envmod(changehypslist nil);look());

(* functions acting on positions that implement the
term navigation commands *)