[m-rev.] for review: context macro thingies

Julien Fischer juliensf at csse.unimelb.edu.au
Wed Apr 2 13:27:13 AEDT 2008


On Tue, 1 Apr 2008, Peter Wang wrote:

> XXX think of a better name

Implementation-defined literals.

> XXX are further changes to prog_rep.cons_id_rep required?

Shouldn't they all be expanded out in the debugger?

> Estimated hours taken: 15
> Branches: main
>
> Add support for "compiler-defined literals" $file, $line, $module, $pred,
> $grade which are replaced constants by the compiler.
>
> library/lexer.m:
> 	Add a new type of token.
>
> 	Read "$foo" as a `compiler_defined' token instead of two name tokens.
>
> library/term.m:
> library/term_io.m:
> 	Add a new type of constant, `compiler_defined'.
>
> library/parser.m:
> 	Handle `compiler_defined' tokens from the lexer.
>
> compiler/check_hlds.m:
> compiler/compiler_defined_literals.m:
> compiler/mercury_compile.m:
> 	Add a new pass to replace compiler-defined literals in program clauses.
>
> 	Call the new pass.

You also need to update the compiler-design document in compiler/notes.
(Also, a NEWS file entry is needed.)

> compiler/prog_data.m:
> 	Add a new option to `cons_id', namely `compiler_defined_const'.
>
> compiler/typecheck.m:
> 	Tell the typechecker the types of the supported compiler-defined
> 	literals.
>
> compiler/prog_io_util.m:
> 	Make `convert_bound_inst' fail if compiler-defined literals appear in
> 	inst definitions so that an error will be issued.

...

> Index: doc/reference_manual.texi
> ===================================================================
> RCS file: /home/mercury/mercury1/repository/mercury/doc/reference_manual.texi,v
> retrieving revision 1.424
> diff -u -r1.424 reference_manual.texi
> --- doc/reference_manual.texi	27 Feb 2008 09:46:07 -0000	1.424
> +++ doc/reference_manual.texi	1 Apr 2008 02:37:37 -0000
> @@ -294,6 +294,10 @@
> and then another sequence of decimal digits (the exponent).
> The fraction part or the exponent (but not both) may be omitted.
>
> + at item compiler_defined_literal
> +A compiler-defined literal consists of a dollar sign (@code{$}) followed
> +by an unquoted name.
> +
> @item open_ct
> A left parenthesis, @samp{(}, that is not preceded by whitespace.
>
> @@ -1322,7 +1326,8 @@
> @subsection Data-functors
>
> A data-functor is an integer, a float, a string, a character literal
> -(any single-character name), a name, or a compound data-term.
> +(any single-character name), a name, a compiler-defined literal,
> +or a compound data-term.
> A compound data-term is a compound term which does not match
> the form of a special data-term (@pxref{Data-terms}),
> and whose arguments are data-terms.
> @@ -1330,6 +1335,28 @@
> must name a function, predicate, or data constructor declared
> in the program or in the interface of an imported module.

...

> +A compiler-defined literal is one of the following, which can only appear
> +within program clauses. Compiler-defined literals will be replaced by
> +constants reflecting the context in which they appear.

I suggest:

Compiler-defined literals are symbolic names whose value represents
a property of the compilation environment that cannot be determined
until compile-time.
The implementation replaces these symbolic names with actual constants
during compilation.
A compiler-defined literal can only appear within a rule body.
The following compiler-defined literals must be supported by all Mercury
implementations:

> +
> + at table @asis
> + at item @samp{$file}
> +a string that gives the name of the file that contains the module currently

Delete "currently".

> +being compiled. If the name of the file cannot be determined then it is
> +replaced by an arbitrary string.
> +
> + at item @samp{$line}
> +the line number (integer) of the goal in which the literal appears
> +or -1 if it cannot be determined.
> +
> + at item @samp{$module}
> +a string representation of the name of the module.

Is the module name fully, partially, not qualified?

> +
> + at item @samp{$pred}
> +a string containing the fully-qualified predicate or function name and arity.
> +
> + at end table


Move the mmc-specific ones to here.  (see below).

> +
> @node Record syntax
> @subsection Record syntax
>
> @@ -9648,6 +9675,7 @@
>                                 the implementation are supported at compile
>                                 time.
> * Trailing::                    Undoing side-effects on backtracking.
> +* Compiler-defined literals::   More literals expanded by the compiler.
>
> @end menu
> @c XXX The `reserved tag' pragma is not documented because it is intended to
> @@ -10688,6 +10716,18 @@
> @c but it might be needed if you're doing certain low-level things
> @c such as implementing your own exception handling.
>
> + at node Compiler-defined literals
> + at section Compiler-defined literals
> +
> +The Melbourne Mercury compiler additionally implements the following
> +compiler-defined literal:
> +
> + at table @asis
> + at item @samp{$grade}
> +the grade (string) in which the module is compiled.
> +

I don't think it is worth having this in a separate section down here.
Move it up with the others - the paragraph saying it is a Melbourne
Mercury compiler extension is sufficient.

s/Melbourne Mercury compiler/Melbourne Mercury implementation.



> Index: tests/hard_coded/compiler_literal.m
> ===================================================================
> RCS file: tests/hard_coded/compiler_literal.m
> diff -N tests/hard_coded/compiler_literal.m
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ tests/hard_coded/compiler_literal.m	1 Apr 2008 02:37:37 -0000
> @@ -0,0 +1,91 @@
> +%-----------------------------------------------------------------------------%
> +
> +:- module compiler_literal.
> +:- interface.
> +
> +:- import_module io.
> +
> +:- pred main(io::di, io::uo) is det.
> +
> +%-----------------------------------------------------------------------------%
> +%-----------------------------------------------------------------------------%
> +
> +:- implementation.
> +
> +:- import_module compiler_literal.sub.
> +:- import_module string.
> +
> +main(!IO) :-
> +    io.write_string($file, !IO),
> +    io.nl(!IO),
> +    io.write_int($line, !IO),
> +    io.nl(!IO),
> +    io.write_string($module, !IO),
> +    io.nl(!IO),
> +    io.write_string($pred, !IO),
> +    io.nl(!IO),
> +    io.write_string(a_function, !IO),
> +    io.nl(!IO),
> +
> +    fun_with_lines(!IO),
> +    fun_with_lines_2(!IO),
> +
> +    % We don't actually write out the grade string so as not to make the
> +    % expected output grade-dependent.
> +    ( string.length($grade) = 0 ->
> +        io.write_string("huh?\n", !IO)
> +    ;
> +        io.write_string("have $grade\n", !IO)
> +    ),
> +
> +    in_submodule(!IO).
> +
> +:- func a_function = string.
> +
> +a_function = $pred.
> +
> +:- pred fun_with_lines(io::di, io::uo) is det.
> +
> +fun_with_lines(!IO) :-
> +    X = $line,
> +    Y = $line,
> +    ( X = Y ->
> +        io.write_string("fun_with_lines: equal\n", !IO)
> +    ;
> +        io.write_string("fun_with_lines: unequal\n", !IO)
> +    ).
> +
> +:- pred fun_with_lines_2(io::di, io::uo) is det.
> +
> +fun_with_lines_2(!IO) :-
> +    % The user probably expects the two occurrences of $line to be replaced
> +    % by two different numbers, but that doesn't happen.
> +    (
> +        $line =
> +        $line
> +    ->
> +        io.write_string("fun_with_lines_2: equal\n", !IO)
> +    ;
> +        io.write_string("fun_with_lines_2: unequal\n", !IO)
> +    ).
> +
> +%-----------------------------------------------------------------------------%
> +%-----------------------------------------------------------------------------%
> +
> +:- module sub.
> +:- interface.
> +
> +:- pred in_submodule(io::di, io::uo) is det.
> +
> +:- implementation.
> +
> +in_submodule(!IO) :-
> +    io.write_string($module, !IO),
> +    io.nl(!IO),
> +    io.write_string($pred, !IO),
> +    io.nl(!IO).
> +
> +:- end_module sub.
> +
> +%-----------------------------------------------------------------------------%
> +% vi:ft=mercury:ts=8:sts=4:sw=4:et


I suggest you also include a test that checks the interaction with #line
directives.

Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the reviews mailing list