[m-dev.] a question of terminology

[Zoltan Somogyi]

On Sat, 16 May 2015 10:52:05 +1000, Paul Bone <paul at bone.id.au> wrote:
> I feel that visible and invisible are good choices.  To me they say more
> about what it *means* for something to be in the interface or implementation
> section of a module.  That is, from the perspective of the compiler, "is X
> visible to Y?" is usually the question we want to answer (a declarative
> perspective), "is X in Z's interface?" is just how we answer the question
> (an operational perspective).
> 
> I made an attempt (but didn't have enough spare time in one large chunk) to
> refactor the import status code based on one of your incomplete patches.
> Having looked at this code and now thinking about new terminology it seems
> there are multiple classes (more than one may be true).
> 
>     + A declaration is visible to all other modules.
>     + A declaration is visible to sub-modules
>     + A declaration is visible to only this module
>     + A declaration is visible via opt-importing
>     + A definition "  "       "   "        " (etc)
> 
> Visibility lets as talk about what code can see what other code.

That is actually a point *againt* using this terminology in the context
of parts of modules, since there are only two sections in .m, .int* and
.*opt files, not all the ones you listed. Those gradations of visibility
are imposed on parts of the parse tree very late; most code that deals
with the parse tree does not start with knowing about them. The parts
of the compiler I am modifying do not *want* to talk about what code
can see what other code, because they do not yet have the information
needed to answer that question (though some of the more complex
of those parts have the job of figuring it out).

> > Note that several of these choices also conflict with other uses of
> > those terms, e.g. "private interfaces" are .int3 files, "headers" can refer
> > to kinds of foreign code inclusions, and "body" can refer to type definitions (referring to the parts of type definitions that don't survive when you
> > make the type definition abstract), though these collisions should cause
> > a lot less confusion that the two distinct senses of "interface".
> 
> I would also avoid the term "external" because that has another meaning in
> Mercury: that the definition of a locally defined predicate is external
> (hand written in C).

Which is why I started the above list of conflicts with "e.g.", signaling
that it is not a *complete* list of such conflicts.

I just thought of another alternative: referring to .int, .int2 .int3 and .int0
files internally as .hdr, .hdr2, .hdr3 and .hdr0, in predicate names
and variable names. That may be less disruptive than any of the other
schemes in my previous mail. Opinions?

Zoltan.