[m-dev.] shims

[Mark Brown]

On Tue, Sep 16, 2014 at 3:58 PM, Peter Wang <novalazy at gmail.com> wrote:
> On Tue, 16 Sep 2014 13:09:09 +1000, Mark Brown <mark at mercurylang.org> wrote:
>> On Tue, Sep 16, 2014 at 12:05 PM, Peter Wang <novalazy at gmail.com> wrote:
>> > On Mon, 15 Sep 2014 16:23:07 +1000, Mark Brown <mark at mercurylang.org> wrote:
>> >> On Mon, Sep 15, 2014 at 3:46 PM, Peter Wang <novalazy at gmail.com> wrote:
>> >> >
>> >> > Is it fair to think of each if-then branch declaring something like an
>> >> > anonymous nested sub-module, with forwarding of predicates and types
>> >> > from the parent module to the sub-module?
>> >>
>> >> Exactly. That was the motivation for the syntax, too.
>> >
>> > Hmm, it should be possible to qualify names within a branch,
>> > but if "branch sub-modules" are unnamed then it's a bit hard to do.
>>
>> Just qualify them with the containing module. (Or is there some
>> situation in which that wouldn't work?)
>
> I think this is misleading:
>
>     :- module m.
>     :- pred p.
>     :- if [ ... ]
>         p :- m.q.
>         :- pred m.q.
>         m.q.
>     ...
>     :- end_if.
>
>     r :- m.q. % error?

Yes, it's an error, since m.q is not visible outside the branch it is
defined in.

>
> The module qualification suggests that q exists at the level of the
> containing module m, rather than a sub-module of m.

I see what you mean. The visibility rules no longer correspond
directly to the module qualification rules. I don't have a major
objection to naming the branches, if you want to propose a syntax. The
names wouldn't be useful for much, though, since these sub-modules are
only able to be accessed through the forwarding predicates and types.

Cheers,
Mark.