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.
tests/accumulator/*.m:
tests/analysis_*/*.m:
tests/benchmarks*/*.m:
tests/debugger*/*.{m,exp,inp}:
tests/declarative_debugger*/*.{m,exp,inp}:
tests/dppd*/*.m:
tests/exceptions*/*.m:
tests/general*/*.m:
tests/grade_subdirs*/*.m:
tests/hard_coded*/*.m:
Make these tests use four-space indentation, and ensure that
each module is imported on its own line. (I intend to use the latter
to figure out which subdirectories' tests can be executed in parallel.)
These changes usually move code to different lines. For the debugger tests,
specify the new line numbers in .inp files and expect them in .exp files.
Add the predicates io.write_line and io.print_line to the standard library.
These are versions of io.write and io.print respectively, that in addition to
printing their argument also print a final newline. While this is no different
to calling io.{write,print} and then calling io.nl, it is a little more concise
which can be convenient in some circumstances.
library/io.m:
Add the above predicates.
compiler/error_util.m:
Avoid ambiguity with the write_line/3 predicate defined
in this module.
NEWS:
Announce the new predicates.
tests/hard_coded/write.m:
Use up-to-date syntax in this module.
Call write_line in a few spots.
Branches: main
Further library consistency improvements.
library.term.m:
Change the argument ordering of the predicate create_var/3.
(This breaks backwards compatibility but that should be okay
as most code uses the varset module rather than calling this
directly.)
Fix the layout in a spot.
library/string.m:
library/type_desc.m:
Change predicates and functions that use a "_det" suffix in
their name to use a "det_" prefix as in the rest of the library
modules. Deprecate the suffix versions.
library/varset.m:
Delete a reference to the graph module.
NEWS:
Announce the above changes.
library/construct.m:
library/varset.m:
library/term_to_xml.m:
compiler/passes_aux.m:
tests/hard_coded/construct_test.m:
tests/hard_coded/deep_copy.m:
tests/hard_coded/write.m:
tests/hard_coded/write_binary.m:
tests/hard_coded/write_reg1.m:
Conform to the above changes.
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.
Estimated hours taken: 18
Branches: main
Move the univ, maybe, pair and unit types from std_util into their own
modules. std_util still contains the general purpose higher-order programming
constructs.
library/std_util.m:
Move univ, maybe, pair and unit (plus any other related types
and procedures) into their own modules.
library/maybe.m:
New module. This contains the maybe and maybe_error types and
the associated procedures.
library/pair.m:
New module. This contains the pair type and associated procedures.
library/unit.m:
New module. This contains the types unit/0 and unit/1.
library/univ.m:
New module. This contains the univ type and associated procedures.
library/library.m:
Add the new modules.
library/private_builtin.m:
Update the declaration of the type_ctor_info struct for univ.
runtime/mercury.h:
Update the declaration for the type_ctor_info struct for univ.
runtime/mercury_mcpp.h:
runtime/mercury_hlc_types.h:
Update the definition of MR_Univ.
runtime/mercury_init.h:
Fix a comment: ML_type_name is now exported from type_desc.m.
compiler/mlds_to_il.m:
Update the the name of the module that defines univs (which are
handled specially by the il code generator.)
library/*.m:
compiler/*.m:
browser/*.m:
mdbcomp/*.m:
profiler/*.m:
deep_profiler/*.m:
Conform to the above changes. Import the new modules where they
are needed; don't import std_util where it isn't needed.
Fix formatting in lots of modules. Delete duplicate module
imports.
tests/*:
Update the test suite to confrom to the above changes.
Estimated hours taken: 0.1
Branches: main
Remove deprecated syntax from some test cases.
(This was done on the release branch some time ago.)
tests/*/*.m:
Replace deprecated syntax.
Estimated hours taken: 30
Implement builtin tuple types, similar to those in Haskell.
Tuples are constructed and deconstructed using
the syntax X = {Arg1, Arg2, ...}.
Tuples have type `{Arg1, Arg2, ...}'.
Unary tuples (X = {Arg}) do work, unlike in Haskell. The rationale
for this is that it is useful to be able to construct unary tuples
to be passed to a polymorphic predicate which uses std_util__deconstruct
to deal with a tuple of any arity. Since this is probably the only
use for unary tuples, it's not really worth the effort of treating
them as no_tag types, so we don't.
The type-infos for tuples have the same structure as for higher-order
types. There is a single type_ctor_info for tuples, and the arity
is placed before the argument type_infos.
library/parser.m:
Change the way '{}/N' terms are parsed, so that the parsed
representation is consistent with the way other functors
are represented (previously the arguments were left as
unparsed ','/2 terms). This avoids special case code
in prog_io__parse_qualified_term, term__term_to_type
and term__type_to_term.
compiler/prog_io_dcg.m:
compiler/prog_io_util.m:
Handle the new structure of '{}/N' terms when parsing DCG escapes
by converting the argument list back into a single ','/2 term.
compiler/module_qual.m:
Treat tuples as a builtin type.
compiler/typecheck.m:
Typecheck tuple constructors.
compiler/mode_util.m:
Propagate types into tuple bound insts.
compiler/type_util.m:
Add type_is_tuple/2 and type_id_is_tuple/1 to identify tuple types.
Add tuples to the list of types which are not atomic types.
Handle tuple types in `type_constructors' and
`get_cons_id_arg_types' and `switch_type_num_functors'.
compiler/tabling.m:
Handle tabling of tuples.
compiler/term_util.m:
Handle tuples in the code to compute functor norms.
compiler/magic_util.m:
compiler/rl.m:
compiler/rl_key.m:
Handle tuple types in the Aditi back end.
compiler/mercury_to_mercury.m:
library/io.m:
library/term_io.m:
Handle output of '{}/N' terms.
compiler/higher_order.m:
compiler/simplify.m:
Don't specialize complicated unifications of tuple
types into calls to a specific unification procedure --
even if the procedure were implemented, it probably
wouldn't be that much more efficient.
compiler/unify_proc.m:
Generate unification procedures for complicated unifications
of tuples (other than in-in unifications). These are generated
lazily as required.
compiler/make_hlds.m:
Export add_special_pred for use by unify_proc.m.
compiler/polymorphism.m:
Export polymorphism__process_pred for use by unify_proc.m.
compiler/bytecode_gen.m:
compiler/code_util.m:
compiler/ml_code_util.m:
Handle unify procedure names and tags for tuple types.
compiler/mlds_to_c.m:
Output tuple types as MR_Tuple.
compiler/ml_unify_gen.m:
Compute the field types for tuples.
compiler/polymorphism.m:
compiler/pseudo_type_info.m:
Treat tuple type_infos in a similar way to higher-order type_infos.
compiler/hlds_data.m:
Document how cons_ids for tuple types are represented.
compiler/switch_gen.m:
compiler/table_gen.m:
Add tuple types to switches on type_util__builtin_type.
compiler/llds_out.m:
util/mdemangle.c:
profiler/demangle.m:
Transform items named "{}" to "f_tuple" when mangling symbols.
library/builtin.m:
Define the type_ctor_info used for tuples.
library/private_builtin.m:
Add `builtin_unify_tuple/2' and `builtin_compare_tuple/3',
both of which abort. All comparisons and in-in unifications
of tuples are performed by the generic unification functions
in runtime/mercury_ho_call.c and runtime/mercury.c.
library/std_util.m:
Implement the various RTTI functions for tuples.
Encode tuple `TypeCtorDesc's in a similar way to that
used for higher-order types. This has the consequence that the limit
on the arity of higher-order types is now MAX_VIRTUAL_REG,
rather than 2*MAX_VIRTUAL_REG.
Avoid calling MR_GC_free for the type-info vector returned
from ML_expand() for tuples because unlike the vectors
for du types, it is not copied.
runtime/mercury_type_info.h:
Add macros for extracting fields from tuple type-infos.
These just call the macros for extracting fields from higher-order
type-infos.
Add a macro MR_type_ctor_rep_is_variable_arity(), which
returns TRUE for tuples and higher-order types.
The distinction between higher-order and first-order types
is now misnamed -- the distinction is really between fixed arity
types and builtin variable arity types. I'm not sure whether
it's worth renaming everything.
runtime/mercury.h:
runtime/mercury.c:
Define unification and comparison of tuples in
high-level code grades.
runtime/mercury_deep_copy_body.h:
runtime/mercury_make_type_info_body.h:
runtime/mercury_tabling.c:
runtime/mercury_unify_compare_body.h:
Handle tuple types in code which traverses data using RTTI.
tests/hard_coded/construct.{m,exp}:
tests/hard_coded/expand.{m,exp}:
Test RTTI functions from std_util.m applied to tuples.
tests/hard_coded/tuple_test.{m,exp}:
Test unification, comparison, term_to_type etc. applied to tuples.
tests/hard_coded/deep_copy.{m,exp}:
Test deep copy of tuples.
tests/hard_coded/typeclasses/tuple_instance.{m,exp}:
Test instance declarations for tuples.
tests/tabling/expand_tuple.{m,exp}:
Test tabling of tuples.
tests/hard_coded/write.m:
Add some module qualifications for code which uses
`{}/1' constructors which are not tuples.
tests/invalid/errors2.{m,err_exp,err_exp2}:
Test handling of tuples in type errors messages.
NEWS:
doc/reference_manual.texi:
w3/news/newsdb.inc:
Document tuples.
doc/transition_guide.texi:
Document the change to the parsing of '{}/N' terms.
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.
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: 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.
