and beginners (who can learn from it).
\end{abstract}
-\section{Introduction\ednote{Zack: attualmente sembra che posto ne abbiamo: se
-la situazione non muta un 10 righe su \helm{} possiamo metterle, non tanto per
-la conferenza quanto per i posteri}}
+\section{Introduction}
The \ws{} approach at software development seems to be a working solution for
getting rid of a wide range of incompatibilities between communicating
software applications. W3C's efforts in standardizing related technologies
The standard solution \ednote{zack: buhm! :-P} is providing a further level of
stable services (called \emph{brokers}) that behave as common gateway/address
for client applications to access a wide variety of services and abstract over
- them.
-
- \oldpart Since the \emph{Declaration of Linz}, the MONET Consortium \cite{MONET},
- following the guidelines \ednote{guidelines non e' molto appropriato, dato che
- il concetto di broker non e' definito da W3C e co} of the \wss{}/brokers
- approach, is working on the development of a framework aimed at providing a
- set of software tools for the advertisement and discovering of mathematical
- \wss{}.
- \begin{newpart}Since the \emph{Declaration of Linz}, the MONET Consortium
+ them.
+
+ Since the \emph{Declaration of Linz}, the MONET Consortium
\cite{MONET}, is working on the development of a framework, based on the
- \wss{}/brokers approac, aimed at providing a set of software tools for the
- advertisement and the discovery of mathematical \wss{}.\end{newpart}
+ \wss{}/brokers approach, aimed at providing a set of software tools for the
+ advertisement and the discovery of mathematical \wss{}.
%CSC This framework turns out to be strongly based on both \wss{} and brokers.
Several groups have already developed \wss{} providing both computational and
In this paper we present an architecture, namely \hbugs{}, implementing a
\emph{suggestion engine} for the proof assistant developed on behalf of the
- \helm{} project. We provide several \wss{} (called \emph{tutors}) able to
+ \helm{}\footnote{Hypertextual Electronic Library of Mathematics,
+ \url{http://helm.cs.unibo.it}} project
+ \cite{helm}. We provide several \wss{} (called \emph{tutors}) able to
suggest possible ways to proceed in a proof. The tutors are orchestrated
- by a broker (a \ws{} itself) that is able to distribute a proof
+ by a broker (a \ws{} itself) that is able to dispatch a proof
status from a client (the proof-assistant) to the tutors;
each tutor try to make progress in the proof and, in case
of success, notify the client that shows an \emph{hint} to the user.
\Omegapp{} proof-planner \cite{Omega}. The main architectural difference
between \hbugs{} and \OmegaAnts{} are that the latter is based on a
black-board architecture and it is not implemented using \wss{} and
- brokers. Other differences will be detailed in Sect. \ref{conclusions}.
+ brokers. Other differences will be detailed in Sect. \ref{conclusions}
+ \ednote{CSC: che si fa di sta frase?}.
In Sect. \ref{architecture} we present the architecture of \hbugs{}.
Further implementation details are given in Sect. \ref{implementation}.
additional requirements exist on the proof status, but there should be an
agreement on its format between clients and tutors. An hint is a
representation\ednote{CSC: non c'\'e un sinonimo pi\'u carino? Zack: l'unico
- decente sembra essere nuovamente "suggestion"}
+ decente sembra essere nuovamente "suggestion". CSC: chiamalo sinonimo!}
of a step that can be performed in order to proceed in an
incomplete proof. Usually it represents a reference to a tactic available
on some proof assistant along with an instantiation for its formal
parameters. More structured hints can also be used: an hint can be
as complex as a whole proof-plan.
- \myincludegraphics{interfaces}{t}{8cm}{\hbugs{} \wss{} interfaces}{\hbugs{}
+ \myincludegraphics{interfaces}{t}{10cm}{\hbugs{} \wss{} interfaces}{\hbugs{}
\wss{} interfaces}
Using W3C's terminology \cite{ws-glossary}, clients act both as \ws{}
- provider and requester, see \ednote{Zack: va bene "see"?, "cfr" credo sia
+ providers and requesters, see \ednote{Zack: va bene "see"?, "cfr" credo sia
solo italiano ...} Fig. \ref{interfaces}.
They act as providers for the broker (to receive hints)
- and as requesters (to submit new status) \ednote{Zack: non manca il "for"
- anche per i requesters?}. Clients
+ and as requesters (to submit new status). Clients
additionally use broker service to know which tutors are available and to
subscribe to one or more of them.
new status are sent to the broker as soon as the proof change (e.g. when the
user applies a tactic or when a new proof is started) and hints are shown to
the user be the means of some effect in the user interface (e.g. popping a
- dialog box or enlightening a tactic button).
+ dialog box or enlightening a tactic button).\ednote{CSC: questo \'e un
+ possibile posto dove mettere una mini-sessione interattiva. L'appendice
+ un altro.}
\hbugs{} clients act as MONET clients and ask brokers to provide access to a
set of services (the tutors). \hbugs{} has no actors corresponding to
MONET's Broker Locating Service (since the client is supposed to know the
URI of at least one broker). The \hbugs{} client and tutors contact the
Getter (a MONET Mathematical Object Manager) to locate and retrieve
- mathematical items in the HELM library. The proof status that are exchanged
+ mathematical items in the \helm{} library.
+ The proof status that are exchanged
by the \hbugs{} actors, instead, are built on the fly and are neither
stored nor are given an unique identifier (URI) to be managed by the
Getter.
With respect to client, a broker act as \ws{} provider, receiving the
proof status and forwarding it to one or more tutors.
It also acts as a \ws{} requester sending
- hints to client as soon as they are available from the tutors.
+ hints to the client as soon as they are available from the tutors.
With respect to tutors, the \ws{} provider role is accomplished by receiving
- hints as soon as they are produced; as a requester one is accomplished
- by requesting computations (\emph{musings} in \hbugs{} terminology) on
+ hints as soon as they are produced; as a requester, it is accomplished
+ by asking for computations (\emph{musings} in \hbugs{} terminology) on
status received by clients and by stopping already late but still
ongoing \musings{}
- \ednote{CSC: Sta frase va comunque riscritta perch\'e non si capisce una
- mazza. Zack: io intanto ho aggiunto una figura, vorrei pero' un tuo commento
- sulla utilita'/quantita' delle figure ...}
+ \ednote{Zack: io intanto ho aggiunto una figura, vorrei pero' un tuo
+ commento sulla utilita'/quantita' delle figure ... CSC: vanno benissimo}
Additionally brokers keep track of available tutors and clients
subscriptions.
Tutors are software component able to consume proof status producing hints.
\hbugs{} doesn't specify by which means hints should be produced: tutors can
use any means necessary (heuristics, external theorem prover or CAS, ...).
- The only requirement is that exists an agreement on the formats of proof
- status and hints.
+ The only requirement is that there exists an agreement on the formats of
+ proof status and hints.
Tutors act both as \ws{} providers and requesters for the broker. As
providers, they wait for commands requesting to start a new \musing{} on
In our implementation of the \hbugs{} architecture we used the proof
assistant of the \helm{} project (codename ``gTopLevel'') as an \hbugs{}
client. Thus we have implemented serialization/deserialization capabilities
- fot its internal status. In order to be able to describe \wss{} that
+ for its internal status. In order to be able to describe \wss{} that
exchange status in WSDL using the XML Schema type system, we have chosen an
XML format as the target format for the serialization.
\item[thesis]: the thesis of the ongoing proof
\item[proof]: the current incomplete proof tree. It can contain
\emph{metavariables} (holes) that stands for the parts of the proof
- that are still to be completed. Each metavariables appearing in the
+ that are still to be completed. Each metavariable appearing in the
tree references one element of the metavariables environment
(\emph{metasenv}).
\item[metasenv]: the metavariables environment is a list of
of alternative suggestions (a list of hints).
For tactics that don't require any particular argument (like tactics that
- apply type constructors or try to automatically conclude equality goals)
- only the tactic name is represented in the hint. For tactics that need terms
- as arguments (for example the \emph{Apply} tactic) the hint includes a
- textual representation of them, using the same representation used by the
- interactive proof assistant when querying user for terms. In order to be
- trasmitted between \wss, hints are serialized in XML.
-
- Actually it is also possible for a tutor to return more hints at once,
+ apply type constructors or decision procedures)
+ only the tactic name is represented in the hint. For tactics that need
+ terms as arguments (for example the \texttt{Apply} tactic that apply a
+ given lemma) the hint includes a textual representation of them, using the
+ same representation used by the interactive proof assistant when querying
+ user for terms. In order to be trasmitted between \wss{}, hints are
+ serialized in XML.
+
+ It is also possible for a tutor to return more hints at once,
grouping them in a particular XML element.
This feature turns out to be particulary useful for the
- \emph{searchPatternApply} tutor (Sect. \ref{tutors}) that
- query a term database and return to the client a list of all terms that
+ \emph{searchPatternApply} tutor (see Sect. \ref{tutors}) that
+ query a lemma database and return to the client a list of all lemmas that
could be used to complete the proof. This particular hint is encoded as a
- list of Apply hints, each of them having one of the results as term
+ list of \texttt{Apply} hints, each of them having one of the results as term
argument.
We would like to stress that the \hbugs{} architecture has no dependency
on either the hint or the status representation: the only message parts
that are fixed are those representing the administrative messages
- (the envelops in the \wss terminology). In particular, the broker can
+ (the envelops in the \wss{} terminology). In particular, the broker can
manage at the same time several sessions working on different status/hints
formats. Of couse, there must be an agreement between the clients
and the tutors on the format of the data exchanged.
- In our implementation the client does not trust the tutors' hints:
+ In our implementation the client does not trust the tutors hints:
being encoded as references to available tactics imply
that an \hbugs{} client, on receipt of an hint, simply try to reply the work
done by a tutor on the local copy of the proof. The application of the hint
can even fail to type check and the client copy of the proof can be left
undamaged after spotting the error. Note, however, that it is still
- possible to implement a complex tutor that looks for a possible proof and
+ possible to implement a complex tutor that looks for a proof doing
+ backtracking and
send back to the client an hint whose argument is a witness (a trace) of
the proof found: the client applies the hint reconstructing (and checking
the correctness of) the proof from the witness, without having to
still possible for the client to type-check the proof-object and reject
wrong hints. The systems that are not based on proof-objects
(as PVS, NuPRL, etc.), instead, have to trust the new proof-status. In this
- case the \hbugs{} architecture needs to be extended with clients-tutors
- autentication.
+ case the \hbugs{} architecture needs at least to be extended with
+ clients-tutors autentication.
\paragraph{Registries}
Being central in the \hbugs{} architecture, the broker is also responsible
- of accounting operations both for clients and tutors. These operations are
+ of housekeeping operations both for clients and tutors. These operations are
implemented using three different data structures called \emph{registries}:
clients registry, tutors registry and \musings{} registry.
\texttt{List\_tutors} method to get a list of available tutors.
Eventually\ednote{CSC: Vuoi veramente dire eventually qui? Zack: si, prima o
poi lo faranno ...} the
- client can subscribe to one or more of these using broker's \emph{Subscribe}
- method. Clients can also unregister from brokers using
+ client can subscribe to one or more of these using broker's
+ \texttt{Subscribe} method. Clients can also unregister from brokers using
\texttt{Unregister\_client} method.
The broker keeps track of both registered clients and clients' subscriptions
in the clients registry.
In order to be advertised to clients during the subscription phase, tutors
- should register to the broker using broker's \texttt{Register\_tutor}
- method. This method is really similar to the \texttt{Register\_client}
- one: tutors are required to send an unique identify and a base URI for
- their \ws{}.
+ should register to the broker using the broker's \texttt{Register\_tutor}
+ method. This method is really similar to \texttt{Register\_client}:
+ tutors are required to send an unique identify and a base URI for their
+ \ws{}.
Additionally tutors are required to send an human readable description of
their capabilities; this information could be used by client's user to
decide which tutors he needs to subscribe to. Like clients, tutors can
unregister from brokers using \texttt{Unregister\_broker} method.
- Track of available tutors is kept in the tutors
- registry.\ednote{Non si mette mai un paragrafo lungo meno di una linea!}
-
Each time the client status change, the status is sent to the
broker using its \emph{Status} method. Using both clients registry (to
lookup client's subscription) and tutors registry (to check if some tutors
della possibilit\'a di avere un vero brocker che multiplexi le richieste
del tutor localizzando i servizi, etc.}
- The forwarding operation is performed using tutors' \texttt{Start\_musing}
- method, that is a request to start a new computation (\emph{\musing{}}) on a
- given status. The return value for \texttt{Start\_musing} method is a
+ The forwarding operation is performed using the \texttt{Start\_musing}
+ method of the tutors, that is a request to start a new computation
+ (\emph{\musing{}}) on a given status. The return value of
+ \texttt{Start\_musing} is a
\musing{} identifier that is saved in the \musings{} registry along with
- the identifier of the client that triggered the starting of the \musing{}.
+ the identifier of the client that triggered the \musing{}.
- As soon as a \musing{} is completed, the owning tutor informs the broker
+ As soon as a tutor completes an \musing{}, it informs the broker
using its \texttt{Musing\_completed} method; the broker can now remove the
\musing{} entry from the \musings{} registry and, depending on its outcome,
inform the client. In case of success one of the \texttt{Musing\_completed}
ovviamente ...} is able to know, at each time,
which \musings{} are in execution on which tutor. This peculiarity is
exploited by the broker on invocation of Status method. Receiving a new
- status from the client imply indeed that the previous status no longer
+ status from the client implies indeed that the previous status no longer
exists and all \musings{} working on it should be stopped: additionally to
the already described behaviour (i.e. starting new \musings{} on the
- received status), the tutor takes also care of stopping ongoing computation
- invoking \texttt{Stop\_musing} tutors' method.
+ received status), the tutor\ednote{CSC: Ma sei veramente veramente sicuro?}
+ takes also care of stopping ongoing computation invoking
+ \texttt{Stop\_musing} tutors' method.
\paragraph{\wss{}}
As already discussed, all \hbugs{} actors act as \wss{} offering one or more
entirely developed in the Objective Caml language, we have chosen to
develop also \hbugs{} in that language in order to maximize code reuse. To
develop \wss{} in Objective Caml we have developed an auxiliary generic
- library (\emph{O'HTTP}) that can be used to write HTTP 1.1 web servers and
- abstract over GET/POST parsing. This library supports different kinds of web
+ library (\emph{O'HTTP}) that can be used to write HTTP 1.1 Web servers and
+ abstract over GET/POST parsing. This library supports different kinds of Web
servers architecture, including multi-process and multi-threaded ones.}.
\paragraph{Tutors}
tutor code given the tactic name. Concretely, we have written a
tactic-based tutor template and a script that parses an XML file with
the specification of the tutor and generates the tutor's code.
- The XML file holds the tutor's port, the code to invoke the tactic,
+ The XML file describes the tutor's port, the code to invoke the tactic,
the hint that is sent back upon successfull application and a
human readable explanation of the tactic implemented by the tutor.
constructor to $n,m$ and a proof of $n \le m$.}.
Since disjunction, conjunction, existential quantification and
Leibniz equality are particular cases of inductive propositions,
- all the other tutors of this class are restrictions of the
- the Constructor tactic: Left and Right suggest to prove a disjunction
+ all the other tutors of this class are instantiations of the
+ the Constructor tactic. Left and Right suggest to prove a disjunction
by proving its left/right member; Split reduces the proof of a
conjunction to the two proof of its members; Exists suggests to
prove an existential quantification by providing a
can easily pre-load the required theorems.
As an example of computationally expensive task, we have implemented
- a tutor for the \emph{Ring} tactic. The tutor is able to prove an equality
- over a ring by reducing both members to a common normal form. The reduction,
- which may require some time in complex cases,
+ a tutor for the \emph{Ring} tactic \cite{ring_bouting}.
+ The tutor is able to prove an equality over a ring by reducing both members
+ to a common normal form. The reduction, which may require some time in
+ complex cases,
is based on the usual commutative, associative and neutral element properties
of a ring. The tactic is implemented using a reflexive technique, which
means that the reduction trace is not stored in the proof-object itself:
such as proof-planners, CAS or theorem-provers.
To test the productivity impact of intelligent tutors, we have implemented
- a tutor that is interfaced with the HELM
+ a tutor that is interfaced with the \helm{}
Search-Engine\footnote{\url{http://mowgli.cs.unibo.it/library.html}} and that
is able to look for every theorem in the distributed library that can
be applied to proceed in the proof. Even if the tutor deductive power
\label{conclusions}
In this paper we described a suggestion engine architecture for
proof-assistants: the client (a proof-assistant) sends the current proof
- status to several distributed \wss (called tutors) that try to progress
+ status to several distributed \wss{} (called tutors) that try to progress
in the proof and, in case of success, send back an appropriate hint
(a proof-plan) to the user. The user, that in the meantime was able to
reason and progress in the proof, is notified with the hints and can decide
to apply or ignore them. A broker is provided to decouple the clients and
the tutors and to allow the client to locate and invoke the available remote
services. The whole architecture is an instance of the MONET architecture
- for Mathematical \wss.
+ for Mathematical \wss{}.
- A running prototype has been implemented as part of the HELM project \cite{}
+ A running prototype has been implemented as part of the
+ \helm{} project \cite{}
and we already provide several tutors. Some of them are simple tutors that
- try to apply one or more tactics of the HELM Proof-Engine, which is also
+ try to apply one or more tactics of the \helm{} Proof-Engine, which is also
our client. We also have a much more complex tutor that is interfaced
- with the HELM Search-Engine and looks for lemmas that can be directly applied.
+ with the \helm{} Search-Engine and looks for lemmas that can be directly
+ applied.
We have many plan for further developing both the \hbugs{} architecture and
- our prototype implementing them. Interesting results could be obtained
+ our prototype. Interesting results could be obtained
augmenting the informative content of each suggestion. We can for example
modify the broker so that also negative results are sent back to the client.
Those negative suggestions could be reflected in the user interface by
Even if not strictly part of the \hbugs{} architecture, the graphical user
interface (GUI) of our prototype needs a lot of improvement if we would like
- it to be usable by novices. In particular, the user is too easily distracted
- by the tutor's hints that are ``pushed'' to her.
+ it to be really usable by novices. In particular, the user is too easily
+ distracted by the tutor's hints that are ``pushed'' to her.
- Our \wss still lack a real integration in the MONET architecture,
+ Our \wss{} still lack a real integration in the MONET architecture,
since we do not provide the different ontologies to describe our problems,
solutions, queries and services. In the short term, completing this task
could provide a significative feedback to the MONET consortium and would
- enlarge the current set of available MONET actors on the web. In the long
+ enlarge the current set of available MONET actors on the Web. In the long
term, new more intelligent tutors could be developed on top of already
- existent MONET \wss.
+ existent MONET \wss{}.
To conclude, \hbugs{} is a nice experiment meant to understand whether the
- current \wss technology is mature enough to have a concrete and useful impact
- on the daily work of users of proof-assistants. So far, only the tutor that
- is interfaced with the HELM Search-Engine has effectively increased the
- productivity of experts users. The usefullness of the tutors developed for
+ current \wss{} technology is mature enough to have a concrete and useful
+ impact on the daily work of users of proof-assistants. So far, only the tutor
+ that is interfaced with the \helm{} Search-Engine has effectively increased
+ the productivity of experts users. The usefullness of the tutors developed for
beginners, instead, need further assessment.
\begin{thebibliography}{01}
projects / helm.git / commitdiff