[m-dev.] a question of terminology
Paul Bone
paul at bone.id.au
Sat May 16 10:52:05 AEST 2015
On Sat, May 16, 2015 at 02:14:00AM +0200, Zoltan Somogyi wrote:
> Predicate and variable names in the existing code refer to interfaces in
> both senses as "interface" or "int", which is often confusing. I have been
> changing the code that talks about the file kind of interface to use "ifile"
> instead of "int" and "noifile" to talk about things that don't do int .int* files,
> but that is cumbersome. I have been thinking that it would be better
> to switch away from the "interface" terminology for the other notion,
> the notion of section kind. I am thinking of several possibilities, including
> using "exported" or "exp" as an internal name in the compiler for the
> interface section and "private" or "priv" or "pvt" for the implementation
> section, or using "header/hdr" and "nonheader/nhdr" by analogy with C,
> using "body" for nhdr by analogy to Ada, or "vis" and "invis", referring to
> the external visibility of the section's contents, or maybe even mixing
> metaphors a bit, with "vis" for the interface and "pvt" for the
> implementation. External vs internal work as full words, but "int" as
> an abbreviation of "internal" collides with "int" as an abbreviation of
> "interface".
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.
> 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).
--
Paul Bone
More information about the developers
mailing list