|
225
|
1 |
\documentclass{article}
|
|
|
2 |
\usepackage{a4wide,ot1patch}
|
|
|
3 |
\usepackage[latin1]{inputenc}
|
|
|
4 |
\usepackage{multicol}
|
|
|
5 |
\usepackage{charter}
|
|
|
6 |
\usepackage{amsmath,amssymb,amsthm}
|
|
|
7 |
\usepackage{fancyheadings}
|
|
|
8 |
|
|
|
9 |
\addtolength{\oddsidemargin}{-6mm}
|
|
|
10 |
\addtolength{\evensidemargin}{-6mm}
|
|
|
11 |
\addtolength{\textwidth}{11mm}
|
|
|
12 |
\addtolength{\columnsep}{3mm}
|
|
|
13 |
\addtolength{\textheight}{8mm}
|
|
|
14 |
\addtolength{\topmargin}{-7.5mm}
|
|
|
15 |
|
|
|
16 |
\pagestyle{fancyplain}
|
|
|
17 |
\lhead[\fancyplain{}{A}]{\fancyplain{}{}}
|
|
|
18 |
\rhead[\fancyplain{}{C}]{\fancyplain{}{}}
|
|
|
19 |
\renewcommand{\headrulewidth}{0pt}
|
|
|
20 |
|
|
|
21 |
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
22 |
\begin{document}
|
|
|
23 |
|
|
|
24 |
|
|
|
25 |
\begin{center}
|
|
|
26 |
\begin{tabular}{c}
|
|
|
27 |
\\[-5mm]
|
|
|
28 |
\LARGE\bf Certified Parsing\\[-10mm]
|
|
229
|
29 |
\mbox{}
|
|
225
|
30 |
\end{tabular}
|
|
|
31 |
\end{center}
|
|
|
32 |
\thispagestyle{empty}
|
|
228
|
33 |
\mbox{}\\[-5mm]
|
|
225
|
34 |
|
|
|
35 |
\begin{multicols}{2}
|
|
228
|
36 |
\section*{Background}
|
|
225
|
37 |
\noindent
|
|
|
38 |
Parsing is the act of transforming plain text into some
|
|
229
|
39 |
structure that can be analysed by computers for further processing.
|
|
225
|
40 |
One might think that parsing has been studied to death and after
|
|
229
|
41 |
\emph{yacc} and \emph{lex} no new results can be obtained in this area.
|
|
225
|
42 |
However recent results and novel approaches make it increasingly clear,
|
|
|
43 |
that this is not true anymore.
|
|
|
44 |
|
|
229
|
45 |
We propose to approach the subject of parsing from a certification point
|
|
|
46 |
of view. Parsers are increasingly part of certified compilers, like \mbox{\emph{CompCert}},
|
|
|
47 |
which are guaranteed to be correct and bug-free. Such certified compilers are
|
|
228
|
48 |
crucial in areas where software just cannot fail. However, so far the
|
|
225
|
49 |
parsers of these compilers have been left out of the certification.
|
|
|
50 |
This is because parsing algorithms are often adhoc and their semantics
|
|
229
|
51 |
is not clearly specified. Unfortunately, this means parsers can harbour
|
|
|
52 |
errors that potentially invalidate the whole certification and correctness
|
|
225
|
53 |
of the compiler. In this project, we like to change that.
|
|
|
54 |
|
|
|
55 |
Only in the last few years, theorem provers have become good enough
|
|
|
56 |
for establishing the correctness of some standard lexing and
|
|
|
57 |
parsing algorithms. For this, the algorithms need to be formulated
|
|
|
58 |
in way so that it is easy to reason about them. In earlier work
|
|
229
|
59 |
about lexing and regular languages, the authors showed that this
|
|
227
|
60 |
precludes well-known algorithms working over graphs. However regular
|
|
229
|
61 |
languages can be formulated and reasoned about entirely in terms
|
|
225
|
62 |
regular expressions, which can be easily represented in theorem
|
|
229
|
63 |
provers. This work uses the device of derivatives of regular
|
|
227
|
64 |
expressions. We like to extend this device to parsers and grammars.
|
|
225
|
65 |
The aim is to come up with elegant and useful parsing algorithms
|
|
229
|
66 |
whose correctness and the absence of bugs can be certified in a
|
|
228
|
67 |
theorem prover.
|
|
|
68 |
|
|
229
|
69 |
\section*{Proposed Work}
|
|
|
70 |
|
|
|
71 |
One new development in formal grammar is the Parsing Expression Grammar (PEG) which is proposed as an refinement of standard Context Free Grammar. The idea is to introduce negative, conjunctive operators as well as production priorities, so that ambiguity abound in CFG can be eliminated. Another benefit of PEG is that it admits a very efficient linear parsing algorithm.
|
|
|
72 |
|
|
|
73 |
|
|
225
|
74 |
\mbox{}\\[15cm]
|
|
|
75 |
|
|
229
|
76 |
\noindent
|
|
|
77 |
|
|
|
78 |
|
|
225
|
79 |
|
|
|
80 |
%\small
|
|
229
|
81 |
%\bibliography{../../bib/all}
|
|
225
|
82 |
%\bibliographystyle{abbrv}
|
|
|
83 |
\end{multicols}
|
|
|
84 |
|
|
|
85 |
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
86 |
% \noindent {\bf Objectives:} The overall goals of the project are as follows:
|
|
|
87 |
% \begin{itemize}
|
|
|
88 |
% \item To solve the POPLmark challenge.
|
|
|
89 |
|
|
|
90 |
% \item To complete and greatly improve the existing implementation of the
|
|
|
91 |
% nominal datatype package.
|
|
|
92 |
% \item To explore the strengths of this package by proving the
|
|
|
93 |
% safety of SML.
|
|
|
94 |
% \item To provide a basis for extracting programs from safety proofs.
|
|
|
95 |
|
|
229
|
96 |
% \item To make the nominal datatype package usable for teaching
|
|
225
|
97 |
% students about the lambda-calculus and the theory of programming
|
|
|
98 |
% languages. \smallskip
|
|
|
99 |
% \end{itemize}
|
|
|
100 |
|
|
|
101 |
|
|
|
102 |
|
|
|
103 |
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
104 |
\end{document}
|
|
|
105 |
|
|
229
|
106 |
%%% Local Variables:
|
|
225
|
107 |
%%% mode: latex
|
|
|
108 |
%%% TeX-master: t
|
|
|
109 |
%%% TeX-command-default: "PdfLaTeX"
|
|
|
110 |
%%% TeX-view-style: (("." "kpdf %s.pdf"))
|
|
229
|
111 |
%%% End:
|