[m-rev.] for review: fix some problems with module qualification
Fergus Henderson
fjh at cs.mu.OZ.AU
Thu Feb 20 18:19:36 AEDT 2003
On 20-Feb-2003, David Overton <dmo at cs.mu.OZ.AU> wrote:
>
> Some changes related to module qualification.
>
> These changes fix problems for the HAL library that were introduced by
> the change to not module-qualify symbols when writing out interface
> files.
Which change are you talking about?
Could you point me to the log message?
It would be helpful if for each of these changes you could explain
why the right place to fix the problem is in the Mercury compiler
rather than in the HAL implementation.
> compiler/prog_io_util.m:
> When parsing an inst, if it has the module-qualifier `builtin'
> try to parse it as a builtin inst.
Hmm. In other words, allow things like "func(in, out) `builtin.is` det"?
The builtin insts such as the higher-order inst "func(in, out) is det"
use special syntax. They are not defined in the builtin module, they
are defined by the language. So I'm not really convinced that it makes
sense to allow the use of module-qualifiers on those.
I wouldn't mind doing this for the insts that don't have special syntax,
such as "free" and "ground", but for those which do, such as
"bound(...)" and higher-order insts, I think allowing module qualifiers
would just complicate Mercury's syntax. Furthermore, it opens a can of
worms -- if you allow "func(in, out) `builtin.is` det",
shouldn't you also allow "builtin.func(in, out) is builtin.det"?
What about clauses for foo/1 defined as "builtin.':-'(foo(X), ...)."?
> compiler/mercury_to_mercury.m:
> When writing out inst declarations, if the inst on the
> left-hand-side of the declaration could be interpreted as a
> builtin inst when unqualified, then make sure it is output
> module-qualified so that it can be read back in correctly
> without generating an "attempt to redefine builtin inst" error.
Is that an error or a warning?
The comment in the code below says it is a warning.
> In `maybe_unqualify_sym_name', do not unqualify names containing
> `__'. This ensures that such names are output to the interface
> files module-qualified and can then be read back in correctly
> without interpreting the `__' as a module qualifier.
I think a better approach would be to change the Mercury compiler to
report an error "mixing different module qualifiers" if any symbol
contains "__", and to change the HAL implementation to avoid generating
such symbols.
The compiler's name mangling algorithms assume that no symbol contains "__".
With your proposed change, it may *appear* to work, but I'm pretty sure the
compiler will do the wrong thing if you define two functions (or types,
typeclasses, etc.) named "foo.bar__baz" and "foo.bar.baz".
Also I think the demangler will not demangle such symbols correctly.
> Index: compiler/mercury_to_mercury.m
> @@ -435,7 +436,15 @@
> mercury_output_item(UnqualifiedItemNames,
> inst_defn(VarSet, Name0, Args, InstDefn, _Cond),
> Context) -->
> - { maybe_unqualify_sym_name(UnqualifiedItemNames, Name0, Name) },
> + { maybe_unqualify_sym_name(UnqualifiedItemNames, Name0, Name1) },
> + % If the unqualified name is a builtin inst, then output the qualified
> + % name. This prevents the compiler giving a warning about redefining
> + % builtin insts when an interface file is read back in.
> + { builtin_inst_name(Name1, Args) ->
> + Name = Name0
> + ;
> + Name = Name1
> + },
The call to maybe_unqualify_sym_name/3 should be in the body of the
if-then-else.
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post: mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------
More information about the reviews
mailing list