diff options
Diffstat (limited to 'aied2017/patterns.tex')
| -rw-r--r-- | aied2017/patterns.tex | 36 |
1 files changed, 18 insertions, 18 deletions
diff --git a/aied2017/patterns.tex b/aied2017/patterns.tex index 11909bf..e1aa767 100644 --- a/aied2017/patterns.tex +++ b/aied2017/patterns.tex @@ -13,8 +13,8 @@ sister(X,Y):- % X is Y’s sister when: Figure~\ref{fig:sister} shows the program’s AST with two patterns. The pattern drawn with blue dotted arrows encodes the fact that the first argument to the \code{sister} predicate also appears in the call to \code{female}. In other words, this pattern states that \code{X} must be female to be a sister. We write this pattern as the s-expression \begin{Verbatim}[fontfamily=sf] -(clause (head (compound (functor \code{sister}) (args var))) - (compound (functor \code{female}) (args var))) +(clause (head (compound (functor ‘\code{sister}’) (args var))) + (compound (functor ‘\code{female}’) (args var))) \end{Verbatim} \begin{figure}[htbp] @@ -70,26 +70,26 @@ Figure~\ref{fig:sister} shows the program’s AST with two patterns. The pattern Every pattern used in this paper has the same basic structure, and describes paths from a \textsf{clause} node to one or two leaf nodes containing variables or values. All patterns in Figs.~\ref{fig:sister} and~\ref{fig:sum} are induced from such node pairs. For each leaf we also include some local context, for example the predicate name (e.g. \texttt{parent}). -We regard these patterns as the smallest units of meaning in Prolog programs: each pattern encodes some interaction between two parts of the program. Including more than two leaf nodes in a pattern could make it difficult to pinpoint the exact error when generating hints. Since a pattern contains at most two \textsf{var} nodes, we require they both refer to the same variable, since relating two nodes corresponding to different variables would not tell us much about the program. This allows us to omit variable names from patterns. +We regard these patterns as the smallest units of meaning in Prolog programs: each pattern encodes some interaction between two parts of the program. Including more than two leaf nodes in a pattern could make it difficult to pinpoint the exact error when generating hints. Each pattern contains at most two \textsf{var} nodes, so we require they both refer to the same variable -- relating two nodes with different variables would not tell us much about the program. This allows us to omit variable names from patterns. -We handle syntactic variations in programs by omitting certain nodes from patterns. For example, by not including \textsf{and} nodes, the above pattern can match a clause regardless of the presence (or order) of other goals in its body (any arrangement of \textsf{and} nodes in the AST). Order \emph{is} important for the nodes specified in the pattern; this is explained below. +We handle syntactic variations in programs by omitting certain nodes from patterns. For example, by not including \textsf{and} nodes, the above pattern can match a clause regardless of the presence (or order) of other goals in its body (i.e., with any arrangement of \textsf{and} nodes in the AST). Order \emph{is} important for the nodes specified in the pattern; this is explained below. The second pattern in Fig.~\ref{fig:sister}, drawn with solid red arrows, encodes the fact that the two calls to \code{parent} share the first argument. In other words, \code{X}~and~\code{Y} must have the same parent~\code{P}. \begin{Verbatim}[fontfamily=sf] -(clause (compound (functor \code{parent}) (args var)) - (compound (functor \code{parent}) (args var))) +(clause (compound (functor ‘\code{parent}’) (args var)) + (compound (functor ‘\code{parent}’) (args var))) \end{Verbatim} Patterns describe relations between nodes in a program’s AST. Specifically, the pattern ($a$ $b$ $c$) means that the nodes $b$ and $c$ are descended from $a$, and that $b$ precedes $c$ in a depth-first tree walk. In general, an AST matches the pattern (\textsf{name} $p_1$ … $p_k$) if it contains a node $n$ labeled \textsf{name}; the subtree rooted at $n$ must also contain, in depth-first order, distinct nodes $n_1$ to $n_k$ matching subpatterns $p_1$ to $p_k$. The above pattern, for example, matches only the last of the following programs (the first program is missing one call to \code{parent}, and the second has different variables in positions encoded by the pattern): \begin{Verbatim} -\textit{\red{% nonmatching}} \textit{\red{% nonmatching}} \textit{\green{% matching}} -sister(X,Y):- sister(X,Y):- sister(X,Y):- - female(X), female(X), parent(A,X), - parent(P,X), parent(A,X), female(X), - X \textbackslash{}= Y. parent(B,Y), parent(A,Y), - X \textbackslash{}= Y. X \textbackslash{}= Y. +\textit{\red{% nonmatching}} \textit{\red{% nonmatching}} \textit{\green{% matching}} +sister(X,Y):- sister(X,Y):- sister(X,Y):- + female(X), female(X), parent(A,X), + parent(P,X), parent(A,X), female(X), + X \textbackslash{}= Y. parent(B,Y), parent(A,Y), + X \textbackslash{}= Y. X \textbackslash{}= Y. \end{Verbatim} A relation between any two objects in a program is insufficient to reason about the program’s behavior on the whole. In the tutoring context, however, there are patterns that strongly indicate the presence of certain bugs. Take for example the following incorrect program to sum a list: @@ -101,7 +101,7 @@ sum([H|T],Sum):- % \textit{recursive case:} Sum is Sum + H. % add first element (\textit{bug:} reused variable) \end{Verbatim} -This error is fairly common with Prolog novices: the variable \code{Sum} is used to represent both the sum of the whole list (line 2), and the sum of only the tail elements (line 3). The last line fails since Prolog cannot unify \code{Sum} with a (usually) different value of \code{Sum\,+\,H}. The program’s AST is displayed in Fig.~\ref{fig:sum}. +This error is fairly common with Prolog novices: the variable \code{Sum} is used to represent both the sum of the whole list (line 2), and the sum of only the tail elements (line 3). The last line fails since Prolog cannot unify \code{Sum} with a (generally) different value of \code{Sum\,+\,H}. The program’s AST is displayed in Fig.~\ref{fig:sum}. \begin{figure}[htbp] \centering @@ -161,24 +161,24 @@ for tree={ \label{fig:sum} \end{figure} -Several patterns capture this mistake. Solid red arrows in Fig.~\ref{fig:sum} show one example -- \code{Sum} returned by the predicate should not be the same as the \code{Sum} from the recursive call: +Various patterns capture this mistake. Solid red arrows in Fig.~\ref{fig:sum} show one example -- \code{Sum} returned by the predicate should not be the same as the \code{Sum} from the recursive call: \begin{Verbatim}[fontfamily=sf] -(clause (head (compound (functor \code{sum}) (args (args var)))) - (compound (functor \code{sum}) (args (args (var))))) +(clause (head (compound (functor ‘\code{sum}’) (args (args var)))) + (compound (functor ‘\code{sum}’) (args (args var)))) \end{Verbatim} \noindent The second pattern, drawn with dashed orange arrows in the figure, indicates the likely error in the arithmetic expression: \begin{Verbatim}[fontfamily=sf] -(clause (binop var \code{is} (binop var \code{+}))) +(clause (binop var ‘\code{is}’ (binop var ‘\code{+}’))) \end{Verbatim} The leftmost pattern in Fig.~\ref{fig:sum}, drawn with dotted blue arrows, describes the correct relation between the two constants in the base-case rule: \begin{Verbatim}[fontfamily=sf] -(clause (head (compound (functor \code{sum}) (args \code{[]} (args \code{0}))))) +(clause (head (compound (functor ‘\code{sum}’) (args \code{[]} (args \code{0}))))) \end{Verbatim} \noindent |