minor changes
This commit is contained in:
parent
f8a213624d
commit
f0def3cb4c
|
@ -4,7 +4,7 @@
|
||||||
% loading 'url' here ensures that URLs are broken into several lines
|
% loading 'url' here ensures that URLs are broken into several lines
|
||||||
% in the bibliography (see natbib documentation).
|
% in the bibliography (see natbib documentation).
|
||||||
|
|
||||||
\bibliographystyle{plainnaturl}
|
\bibliographystyle{plainnat}
|
||||||
\citestyle{authoryear}
|
\citestyle{authoryear}
|
||||||
% [Gabriel] I have a strong preference for author-year citation style,
|
% [Gabriel] I have a strong preference for author-year citation style,
|
||||||
% with all authors listed (\citet*, \citep*)
|
% with all authors listed (\citet*, \citep*)
|
||||||
|
|
33
workshop.tex
33
workshop.tex
|
@ -205,8 +205,8 @@ There are two difficulties with the code we had to write:
|
||||||
values are \emph{named} far from where they are \emph{expressed} in
|
values are \emph{named} far from where they are \emph{expressed} in
|
||||||
the program; notice for example how \lstinline{u'} binds the witness
|
the program; notice for example how \lstinline{u'} binds the witness
|
||||||
of \lstinline{hastype u v}, but is placed farther away in the
|
of \lstinline{hastype u v}, but is placed farther away in the
|
||||||
program. This problem gets worse when inferring the types of more
|
program. This problem gets worse when writing inference code for
|
||||||
complex constructs.
|
more complex constructs.
|
||||||
|
|
||||||
When we explain this code, we say that the \lstinline{Infer.ty}
|
When we explain this code, we say that the \lstinline{Infer.ty}
|
||||||
result of \lstinline{exist} or the \lstinline{(F.term * F.ty) list}
|
result of \lstinline{exist} or the \lstinline{(F.term * F.ty) list}
|
||||||
|
@ -297,20 +297,20 @@ any functor \lstinline{'a t}, the type\\ %
|
||||||
\lstinline{type 'a m = 'r. ('a -> 'r t) -> 'r t} has a monadic
|
\lstinline{type 'a m = 'r. ('a -> 'r t) -> 'r t} has a monadic
|
||||||
structure. This lets us write \lstinline{exist} and our
|
structure. This lets us write \lstinline{exist} and our
|
||||||
\lstinline{traverse} above in monadic style, and then rely on our
|
\lstinline{traverse} above in monadic style, and then rely on our
|
||||||
usual monadic programming hbits. Unfortunately, we found this too hard
|
usual monadic programming habits. Unfortunately, we found this too hard
|
||||||
to use in practice for the following reasons:
|
to use in practice for the following reasons:
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
|
|
||||||
\item \lstinline{exist} is a naturally \emph{scoped} construction:
|
\item \lstinline{exist} is a naturally \emph{scoped} construction:
|
||||||
besides generating a free variables, it builds a raw constraint term
|
besides generating a free variables, it builds a raw constraint term
|
||||||
of the form \lstinline{CExist(x,rc)}, where the inference variable
|
of the form \lstinline{CExist(x,rc)}, where the inference variable
|
||||||
is only bound in the constraint sub-term \lstinline{rc}.
|
scopes over the constraint sub-term \lstinline{rc}.
|
||||||
|
|
||||||
A \lstinline{co_cps} computation builds a single ever-growing scope
|
A \lstinline{co_cps} computation builds a single ever-growing scope
|
||||||
(by composing continuations in scope of all quantifiers effect
|
(by composing continuations in scope of all quantifiers effect
|
||||||
performed so var). The scope is only ``closed'' when the computation
|
performed so var). The scope is only ``closed'' when the computation
|
||||||
is ``run'' by invoking it with the identity continuation -- we can
|
is ``run'' by invoking it with the identity continuation -- we can
|
||||||
define a closing combinator to encapsulate this transformation.
|
define a \lstinline{close} combinator doing this.
|
||||||
|
|
||||||
Note that lifting all existential constraints to a toplevel, global
|
Note that lifting all existential constraints to a toplevel, global
|
||||||
scope would be incorrect, due to the interplay with polymorphism /
|
scope would be incorrect, due to the interplay with polymorphism /
|
||||||
|
@ -388,7 +388,10 @@ which introduce arguments of type \lstinline{'a} to build a constraint
|
||||||
in a delimited scope returning a \lstinline{'r co}. Only terms of this
|
in a delimited scope returning a \lstinline{'r co}. Only terms of this
|
||||||
type are written in continuation-passing style. They are used through
|
type are written in continuation-passing style. They are used through
|
||||||
\lstinline{let@}, that opens a quantifier which naturally scopes until
|
\lstinline{let@}, that opens a quantifier which naturally scopes until
|
||||||
the end of the lexical block.
|
the end of the lexical block. The binder syntax is a reference to
|
||||||
|
OCaml's infix application operator \lstinline{(@@)}: %
|
||||||
|
\lstinline{(let@ p = a in b)} is equivalent to %
|
||||||
|
\lstinline{(b @@ fun p -> a)}.
|
||||||
|
|
||||||
Our ``tuple'' case becomes as follows:
|
Our ``tuple'' case becomes as follows:
|
||||||
\begin{lstlisting}
|
\begin{lstlisting}
|
||||||
|
@ -417,15 +420,15 @@ expression at the logical place in the code (\lstinline{ty} and
|
||||||
\lstinline{us'} for example). Being in the applicative, a modal input
|
\lstinline{us'} for example). Being in the applicative, a modal input
|
||||||
variable \lstinline{x} cannot be used as-is to build the witness, it
|
variable \lstinline{x} cannot be used as-is to build the witness, it
|
||||||
has to be ``unpacked'' in the final%
|
has to be ``unpacked'' in the final%
|
||||||
\lstinline{let+ .. and+ .. in <witness>} block by the construction
|
\lstinline{let+ .. and+ .. in <witness>} block by the odd construction
|
||||||
(at first surprising) \lstinline{and+ x = x}.
|
\lstinline{and+ x = x}.
|
||||||
|
%
|
||||||
Unpacking is slightly surprising, and the redudancy is frustrating
|
This unpacking construction is surprising, and the redudancy is
|
||||||
(one could think of a proper modal-typing rule in the compiler that
|
frustrating (one could think of a proper modal-typing rule in the
|
||||||
would implicitly unpack modal inputs); but note that the unpacking place
|
compiler that would implicitly unpack modal inputs); but note that the
|
||||||
corresponds to the place, in the previous style, where the variable
|
unpacking place corresponds to the place, in the previous style, where
|
||||||
would have been first named. Unpacking is a fair price to pay to
|
the variable would have been first named. Unpacking is a fair price to
|
||||||
recover readable code.
|
pay to recover readable code.
|
||||||
|
|
||||||
\bibliography{biblio}
|
\bibliography{biblio}
|
||||||
\end{document}
|
\end{document}
|
||||||
|
|
Loading…
Reference in New Issue