mirror of
https://github.com/GaloisInc/cryptol.git
synced 2024-09-11 22:17:18 +03:00
Incorporating Sean Weaver's fixes to programming cryptol - ticket #80
This commit is contained in:
parent
9346db2d0c
commit
3ebc8bffcd
@ -5,7 +5,7 @@ BOOK = Cryptol.pdf
|
||||
all: markdown book
|
||||
|
||||
Version2Table.pdf: Version2Table.md
|
||||
pandoc -f markdown+tex_math_dollars $^ -o $@
|
||||
pandoc -f markdown+tex_math_dollars -V geometry:"margin=0.25in" $^ -o $@
|
||||
|
||||
.PHONY: markdown
|
||||
markdown: ${MARKDOWN}
|
||||
|
Binary file not shown.
@ -2273,7 +2273,7 @@ This time all we need to make sure is that the result is not {\tt
|
||||
True}.\indZero\indTrue\indAny If we pass {\tt all} an empty
|
||||
sequence, then we will always get {\tt False}:
|
||||
\begin{Verbatim}
|
||||
Cryptol> any eqTen [] where { eqTen x = x == 10; }
|
||||
Cryptol> any eqTen [] where eqTen x = x == 10
|
||||
False
|
||||
\end{Verbatim}
|
||||
Again, this is the correct response since there are no elements in an
|
||||
@ -2742,7 +2742,8 @@ types-as-sets interpretation, two types in Cryptol are synonymous if
|
||||
their values happen to be equal.
|
||||
|
||||
For example, consider the following declarations:
|
||||
\begin{code}
|
||||
%% not "code" to avoid conflicting with previous Word8
|
||||
\begin{Verbatim}
|
||||
type Word8 = [8]
|
||||
type Word8' = [8]
|
||||
type B = Word8
|
||||
@ -2755,7 +2756,7 @@ For example, consider the following declarations:
|
||||
|
||||
bar: Word8' -> Bit
|
||||
bar x = foo x
|
||||
\end{code}
|
||||
\end{Verbatim}
|
||||
Within this type context, while six \emph{names} are declared, only
|
||||
\emph{two} types are declared (\texttt{[8]} and the pair \texttt{([8],
|
||||
[8])}. Likewise, the function types of \texttt{foo} and \texttt{bar}
|
||||
@ -2983,7 +2984,7 @@ of the use of backtick:
|
||||
The bounds in a finite sequence literal (such as {\tt [1 .. 10]}) in
|
||||
Cryptol are type-level values because the length of a sequence is part
|
||||
of its type. Only type-level values can appear in a finite sequence
|
||||
definition. You cannot write {\t [a .. b]} where either {\tt a} or
|
||||
definition. You cannot write {\tt [a .. b]} where either {\tt a} or
|
||||
{\tt b} are arguments to a function. On the other hand, an infinite
|
||||
sequence's type is fixed ({\tt [inf]a}), so the initial value in an
|
||||
infinite sequence can be a runtime variable or a type variable, but
|
||||
|
@ -204,7 +204,7 @@ Properties (theorems in version 1)
|
||||
|
||||
In version 1, _theorems_ are special syntax attached to function declarations.
|
||||
In version 2, the `property` keyword can be added to any function that returns
|
||||
a Bit. All of the arguments to a propertyare implicitly universally quantified.
|
||||
a Bit. All of the arguments to a property are implicitly universally quantified.
|
||||
So version 1's
|
||||
|
||||
sqDiffThm : ([8], [8]) -> Bit;
|
||||
@ -258,7 +258,7 @@ looks closer to most specs when it's in "big endian" mode. This is why version
|
||||
The translation between endianness can not be easily mechanized, though, so
|
||||
`:modernize` doesn't try to.
|
||||
|
||||
As a result, our suggested translation path from version1 to version2 is either
|
||||
As a result, our suggested translation path from version 1 to version 2 is either
|
||||
to completely rewrite the code based on looking at the original spec (which is
|
||||
likely to produce surprisingly cleaner code), or if that isn't feasible to
|
||||
first translate the version 1 code to "big endian" mode (use `:set +B`), then
|
||||
|
Binary file not shown.
Binary file not shown.
Loading…
Reference in New Issue
Block a user