List enumeration arguments are parsed as expressions and
then converted to types afterward. Previously parenthesis
productions were dropped; e.g. "[1..(2+2)*(3+3)]" was
parsed as "[1..2+2*3+3]" before resolving infix precedence.
This is now fixed.
Fixes#379.
This command has three options: 'auto', 'none', and 'always'. They're
fairly self explanatory. 'auto' is the default, and detects that the
terminal output is not equal to `dumb`, and that `stdout` is a
terminal handle.
The choice of option has no impact on whether the title sequence is
sent to the ANSI terminal. That is always detected automatically and
independently of this option.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
In some environments, setting the terminal title does not work, like
Emacs. This results in very ugly output when using Cryptol as a REPL
inside emacs with cryptol-mode, because Emacs merely repeats the
escape sequences back to you, completely ruining the main REPL.
This patch only sets the terminal if the `stdout` handle is detected
to support ANSI escape sequences. This is an adequate check for
setting the title. Note the exact semantics are to check that the
output is a terminal, and that `TERM` is not set to `dumb`, which is
what Emacs sets it to. In the future, `shouldSetREPLTitle` may be
expanded to include other cases if that isn't enough.
Note a subtle point about this: the function to check this case is
very specifically named, because while we may not be able to support
certain terminal codes, we *can* support ANSI escape sequences in
places like Emacs, reliably.
Thus, this patch does not have any changes to the color output: that
should be handled by a follow up patch (that allows either autodetect,
or explicit enable/disable, on the command line). Then, Emacs will be
able to explicitly request color support for the REPL when invoked,
while the REPL code itself will reliably abstain from setting the
title in such environments automatically. There shouldn't ever be a
need to export some '--set-ansi-terminal-title' flag with this logic.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
parses involving (&&) and (||) relative to the comparison operators,
or between (&&) and (^). These operators are scheduled to change
fixity levels. See issue #241.
There are two major changes in this patch. The first is that sequence maps
now have special representations for point updates, of the sort produced by
the 'update' and 'updateEnd' primtives. These updates are stored in a
finite map, rather than as a functional-update thunk using lambdas; this
reduces memory usage and improves time efficecy of sequences defined by
sequences of updates.
The second change is that the caching policy for sequences is changed
to retain all previously-calculated values. This is a change from the
previous LRU policy, which retained only a small finite number of previous
values. Benchmarking showed that unbounded memoization was better for
performance in essentially all cases over both an LRU and an adaptive
caching strategy. The potential downside is that we may retain values
longer than necessary. If this becomes a problem, we may need to revisit
this decision.
vectors at indices starting from the beginning/end of the vector,
respectively.
Included in this patch are implementations of these primitives
for the concrete evaluator. Symbolic primitives are TODO.
The newtype doesn't introduce two distinct names, but just one that is re-used
at the type and expression level. This is OK, as the two namespaces are
distinct, thus there is no ambiguity.
Fixes#369
There are separate benchmarks for the Extras.cry module and the combined
Prelude + Extras module because the performance characteristics are nonlinear.
Changes include spelling, grammar, punctuation,
typesetting, and code formatting. A few factual errors
have been fixed, and some Cryptol REPL output has been
updated as well.
This greatly increases mutator productivity, and thus provides
significant speedups on some examples. The tradeoff with
larger nurseries is the potential for long GC pause times.
This is probably acceptable tradeoff for a tool like Cryptol,
despite the potential for unresponsiveness at the REPL.
The new evaluator allows us to have more direct control over
evaluation order, and makes it straightforward to implement tracing
primitives. There are two new primitives 'trace' and 'traceVal' in the
Cryptol prelude that produce tracing output when evaluated.
Fixes#68