The above predicates currently escape all of the C0 control characters (+
Delete). This change modifies them to escape all of the characters in the
Unicode category `Other,control' using backslash escapes when they exist and
octal escapes otherwise.
library/term_io.m:
Do not treat C1 control characters as Mercury source characters.
Re-order the list of Mercury punctuation characters by codepoint
order; it is difficult to check for completion otherwise.
Put a list of special characters escapes in order.
runtime/mercury_ml_expand_body.h:
library/rtti_implementation.m:
Update the implementations of functor/4 to escape all control
characters when returning the functor of a character.
library/deconstruct.m:
Specify that functor/4 should escape all control characters in
the value returned for characters and strings. (XXX TODO: it
currently doesn't implement the new behaviour for strings; I'll
add that separately.)
library/io.m:
library/stream.string_writer.m:
Similar to the above but for io.write etc.
tests/hard_coded/write.{m,exp}:
tests/hard_coded/deconstruct_arg.{m,exp,exp2}:
Extend these tests to cover the block of C1 control characters
and the boundaries around it.
Fix two problems with deconstruct.functor/4 and characters.
1. Control characters were not being octal escaped as they are by
io.write etc.
2. The higher bytes of multibyte characters were being discarded.
Note that as part of the above fix deconstruct.functor/4 will now abort if
called with a surrogate code point.
Fix problem with io.write (and related predicates) where characters were
being octal escaped even though a more specific escape character existed
(e.g. \r or \a).
runtime/mercury_ml_expand_body.h:
Make the above fixes.
library/rtti_implementation.m:
Conform to the above.
Fix the escaping of single quote characters.
library/term_io.m:
Add missing character escapes to the predicate
mercury_escape_special_char/2. The omission of these
was the cause of the above problem with character escapes
and io.write.
tests/hard_coded/deconstruct_arg.{m,exp,exp2}:
Modify this test to use io.write rather than io.print since
the former will insert character escapes.
Do more thorough testing of characters.
tests/hard_coded/write.{m,exp}:
Add more tests for escape characters.
Add tests for infinite float values.
tests/hard_coded/write.m:
tests/hard_coded/write.exp*:
As above.
Also, update the expected outputs for the non-C grades for the chnage in
commit 253378f.
Do this by insisting that terms whose top level(s) look like lambda
expressions should be parsed as lambda expressions, and return error
messages if that parsing attempt fails.
I did this is in several commits to modules in the parse_tree.m package
that translated terms to the parse tree, i.e. to goal_exprs. This diff
does the same thing for lambda expressions.
NEWS:
Document this change, as well as other, similar changes in the recent past.
compiler/superhomogeneous.m:
When translating a var-functor unification, which has the form
X = f(Y1, ..., Yn), to the HLDS, we parse the right hand side term,
looking for Mercury constructs such as lambda expressions and
field accesses. We used to do this by checking if the RHS was
a well-formed version of the construct we were looking for,
and falling back to parsing it as an ordinary term. That meant that
terms that the programmer *intended* to be lambda expressions,
but which contained a syntax error, were not diagnosed during the
construction of the HLDS, but during a later pass. Virtually always,
that later pass was typechecking. Since in such cases, the typechecker
is given terms whose function symbols were *intended* to be the "keywords"
of Mercury constructs (to the extent that Mercury *has* keywords),
not the names of data constructors or predicates, those error messages
were almost always confusing, and at best an *indirect* indication
of the actual problem with the code.
This diff changes things so that when the top function symbol on
the RHS of a unification is a Mercury "keyword" used only in lambda
expressions, we commit to parsing it as such. If the parsing fails,
we now generate an error message that describes the problem *directly*.
To make the task of generating good error messages easier, and to make it
possible to generate *consistent* error messages for the same error
in different contexts, unify the four separate pieces of code that
*used* to parse different kinds of lambda expressions. These four
pieces of code used to parse
- predicates defined using DCG notation;
- predicates defined using non-DCG notation;
- functions that used the default function mode and determinism; and
- functions that did not use the default function mode and determinism.
The unified code allows a function lambda expression to omit the
default argument modes *independently* of whether it omits the default
determinism, and vice versa. The old code did not do that: if you didn't
explicitly specify one, you couldn't explicitly specify the other either,
probably because it would have required two more pieces of code.
The language reference manual says, in section 8.1:
As with ‘:- func’ declarations, if the modes and determinism
of the function are omitted in a higher-order function term, then
the modes default to ‘in’ for the arguments, ‘out’ for
the function result, and the determinism defaults to ‘det’.
This text is vague on whether the modes and determinism are *allowed*
to be omitted independently. The old behavior was a strict reading
of this text. The new behavior follows the most liberal possible reading,
and thus allows all the behaviors that the old one did, and more.
Integrate the test for big integers that are too big to be represented
with the conversion of all ordinary functors into cons_ids, both to
simplify the code, and to speed it up. In the process, improve the
error message for too-big integers.
compiler/add_clause.m:
Don't try to generate warnings for singleton variables in a clause
if the clause had syntax errors. Part of the parser's recovery from
those syntax errors (e.g. when they occur in lambda expressions' clause
heads) may have included not translating parts of the original term
into the parsed clause body, so any such warnings could be misleading.
Such warnings could also be correct, but I expect most programmers
would prefer to miss some correct singleton warnings while the
syntax errors are present in their code, and get them only once
they have fixed those syntax errors, than to have to wade through
misleading errors messages for the initial syntax error to get to
the real ones.
compiler/field_access.m:
Clarify the text of an error message.
Delete a predicate that superhomogeneous.m no longer needs.
compiler/mercury_compile_front_end.m:
Don't proceed past typechecking if the parser found syntax errors,
since any errors we find later, e.g. as part of mode checking,
are quite likely to be avalanche errors caused by those syntax errors.
The reason why this wasn't a problem in the past is that when
the program contained malformed uses of builtin constructs such as
lambda expressions and field accesses, the parser used to simply
transform the terms containing the malformed constructs into the arguments
of call goals and unifications, and it was the typechecker that discovered
that these function symbols did not match any declared type.
The "type errors" generated for such problems told the compiler
not to run later compiler passes to prevent avalanche errors.
We now report syntax errors earlier, during the construction of the HLDS,
and it is entirely possible that the parser's recovery from those errors
leaves *no* type errors to be reported. This is why we need to make
the presence of syntax errors in a predicate block the invocation
of later passes.
compiler/typecheck.m:
Return whether the predicates we typechecked had syntax errors,
to make the change in mercury_compile_front_end.m possible.
compiler/state_var.m:
If a lambda expression has two or more arguments of the form !X,
we now print an error message for each, with each message naming the bad
state variable and giving the context of the argument. We used to
print only a single message saying that *some* argument misused
state variables this way. Similarly, we now print the correct context
for !X appearing as a function result, whether in a lambda expression
or at the top level of a clause.
The actual printing of those error messages takes place elsewhere,
but change the utility predicates exported by state_var.m to make
the change possible.
Change the error message we generate for !X appearing as a function
result, to avoid suggesting a possible repair that is virtually never
the right repair.
compiler/mode_util.m:
Delete a predicate that was used only by superhomogeneous.m; an updated
version of that predicate is now in superhomogeneous.m itself.
compiler/module_qual.m:
compiler/module_qual.qualify_items.m:
Instead of exporting predicates to module qualify the whole list of
argument modes of a lambda expression, export predicates that module
qualify only one such mode, since that is what superhomogeneous.m
now wants.
compiler/hlds_clauses.m:
Add access predicates for fields of the clauses_info type that previously
did not have them, including the one that records the presence of syntax
errors.
Put related fields of the clauses_info together.
Group both the declarations and the definitions of the access predicates
together, and put them in the same order as the fields themselves.
compiler/add_class.m:
compiler/add_pred.m:
compiler/add_pragma_type_spec.m:
compiler/higher_order.m:
compiler/hlds_pred.m:
compiler/unify_proc.m:
Conform to the changes above.
tests/invalid/lambda_syntax_error.err_exp:
Print one error message for each of the four malformed lambda expressions
in this test case, instead of the 13 avalanche messages we used to get
from the typechecker, which tried to interpret the malformed lambda
expression heads as calls, unifications etc.
The motivation for this diff was a set of similar set of avalanche error
messages for a real-life syntax error in a lambda expression in a change
I worked on a while ago.
tests/benchmarks/deriv.{m,exp}:
This test case used to use "^" as a data constructor (to represent
raising X to the Nth power). Since the parser now insists on treating it
as a field access operator, replace "^" with "power". (This test has
the excuse of predating the addition of field access syntax to Mercury
by several years.)
tests/dppd/grammar_impl.m:
This test case used to define a type which contained "is" as a data
constructor. After this diff, this is no longer allowed (as part of
"is detism", it looks to the parser like the top constructor in a
lambda expression head, and therefore as the top constructor of
the lambda expression as a whole if it has no body), so add the type
name as a prefix to this data constructor. To future-proof the test case,
do the same with the several other data constructors that also duplicate
the names of Mercury keywords.
tests/hard_coded/pprint_test2.{m,exp}:
tests/hard_coded/write.{m,exp}:
tests/hard_coded/write_binary.{m,exp}:
These test cases used to define a type which contained ":-" as a data
constructor. After this diff, this is no longer allowed, so replace them
with "?-". (The tests check how io.m formats terms whose data constructor
is an operator, so the replacement needs to be an operator, and Mercury
syntax does not use "?-"; library/ops.m lists it as an operator only
because it is an operator in Prolog.)
Update write_binary.m to conform to our current style guide, and to avoid
using the recently-deprecated io.make_temp.
tests/invalid/invalid_int.err_exp:
Expect the updated text of the error message for a too-big
integer constant.
tests/invalid/record_syntax_error.err_exp:
Expect the updated text of the error message for a malformed field name.
tests/invalid/state_vars_test3.err_exp:
Expect the updated text of the error message for a !X appearing
as the result of a lambda function.
tests/invalid/state_vars_test4.err_exp:
Expect the error message for a !X lambda argument, but (since we now
stop after typechecking in the presence of such syntax errors),
don't expect the avalanche error messages we used to print from the
mode checker.
Branches: main
Make io.write and the two pretty-printers in the standard library handle
version arrays in a similar way to normal arrays.
library/pprint.m:
library/pretty_printer.m:
library/stream.string_writer.m:
As above.
library/version_array.m:
Add a function for converting a version_array to a pretty_printer.doc
value.
tests/hard_coded/pretty_printing.{m,exp}:
tests/hard_coded/test_pretty_printer_defaults.{m,exp}:
tests/hard_coded/write.{m,exp}:
Include printing version_arrays in these tests.
runtime/mercury_float.c:
Fix a bug in MR_sprintf_float where it would convert 1.8e-10
into "1.80000000000000e-1" instead of "1.8e-10".
The problem was that it was stripping the zeros off the end of the string
produced by sprintf without considering the case where the output
was in scientific notation.
The fix is to remove the `#' from the sprintf format string and then to
append ".0" to the string if there is no "." or "e".
tests/general/float_roundtrip.m:
tests/general/float_roundtrip.exp:
Add regression test.
tests/hard_coded/deep_copy.exp:
tests/hard_coded/expand.exp:
tests/hard_coded/float_reg.exp:
tests/hard_coded/write.exp:
tests/hard_coded/write_binary.exp:
tests/hard_coded/write_reg1.exp:
tests/hard_coded/write_xml.exp:
Update the expected output of these tests as trailing zeros are now
also removed from the base part of scientific notation float strings.
Estimated hours taken: 0.1
This set of changes was posted a while ago by Zoltan
but not committed.
tests/debugger/interpreter.exp:
tests/hard_coded/construct.exp:
tests/hard_coded/deep_copy_bug.exp:
tests/hard_coded/expand.exp:
tests/hard_coded/write.exp:
tests/hard_coded/write_reg1.exp:
Update the expected outcomes to reflect the changes
to vars and varsets.
tests/debugger/interpreter.exp2 will need to be updated later.
Estimated hours taken: 0.75
Fix a bug reported by Tom Conway where term_io__write_term, io__write
and io__write_binary were not properly quoting graphic tokens.
library/term_io.m:
library/io.m:
Change term_io__write_term and io__write to quote graphic
tokens where necessary, so that the output will parse correctly
when followed by ".\n".
tests/hard_coded/write.m:
tests/hard_coded/write.exp:
Add a new test to test the changes to io__write,
and update the expected output for one of the existing tests.
std_util:type_name/1.
compiler/base_type_info.m:
compiler/polymorphism.m:
library/mercury_builtin.m:
Add module names to base_type_infos.
library/io.m:
library/term.m:
Check module names as well as type names for special cases.
Add module qualifiers to terms that represent types
(That is, when converting type_infos to terms).
library/std_util.m:
Add type_ctor_module_name/1, add an argument to
type_ctor_name_and_arity for the module name.
Add module qualifiers to the name returned by type_name.
runtime/type_info.h:
Define the offset fo type module names, add
MR_TYPECTOR_GET_HOT_MODULE_NAME and
MR_BASE_TYPEINFO_GET_TYPE_MODULE_NAME
tests/hard_coded/higher_order_type_manip.exp:
tests/hard_coded/write.exp:
tests/hard_coded/write_reg1.exp:
Update test case expected output with module qualifiers where needed.
Estimated hours taken: 6
The main purpose of this change is to rename array.m as bt_array.m, and
uniq_array.m as array.m. The interfaces of those two modules have grown
slightly so that they match a little more closely. Details are in the
file NEWS.
The implementation of bt_array (formerly array) has been changed to use
a slightly more efficient implementation.
NEWS:
Interface changes documented.
library/array.m:
library/bt_array.m:
Changes mentioned above and detailed in the NEWS file.
library/uniq_array.m:
Bereft of life and resting in peace.
library/io.m:
library/library.m:
library/std_util.m:
library/term.m:
compiler/base_type_layout.m:
runtime/deep_copy.c:
runtime/type_info.h:
Minor changes to fix the special case of base_type_layout
operations for arrays rather than uniq_arrays.
tests/hard_coded/write.exp:
tests/hard_coded/write.m:
Test writing of arrays.
tests/general/array_test.exp:
tests/general/array_test.m:
Test some array/bt_array operations.
Estimated hours taken: 0.5
tests/hard_coded/write.exp:
tests/hard_coded/write_reg1.exp:
Change the expected output for writing out values of type `var'.
Previously, due to a bug (compare_type_info didn't expand
equivalence types), values of type `var' were incorrectly
output in quotes (as if they were atoms) rather than outputting
them as ints.
Estimated hours taken: 1
Update the test cases to reflect recent changes to io__write.
test/hard_coded/construct.m:
test/hard_coded/expand.m:
Use `io__print' rather than `io__write' for univs,
so that it doesn't output the `univ(... : type)' wrappers.
tests/hard_coded/deep_copy_bug.exp:
tests/hard_coded/construct.exp:
tests/hard_coded/expand.exp:
tests/hard_coded/write.exp:
tests/hard_coded/write_reg1.exp:
Change the expected output to use proper list notation
rather than prefix `.', and to properly quote strings and atoms,
but also to improperly quote equivalences types.
tests/hard_coded/Mmake:
Add a comment explaining that deep_copy_bug.exp, write.exp, and
write_reg1.exp are wrong, due to a bug in io__write.
Estimated hours taken: 30
Add io__write/3 and io__write/4, which writes anything to the current,
or specified, output stream.
(At fjh's request, these test cases have not yet been enabled).
tests/hard_coded/write.m:
tests/hard_coded/write.exp:
Test for io__write, exercises all data types and representations.
