[m-dev.] a question of terminology

[Zoltan Somogyi]

I have just started to work again on my diff for replacing item lists
with more structured representations, of the source code, of .int* files,
and .*opt files.

This involves working with code that deals with two distinct kinds of
interfaces. One notion of interfaces has to do with the kind of file being
represented: .int* as  opposed to .m or .*opt. The other notion has to do
with the visibility of items outside their defining module, i.e. whether an
item is in a section that starts with ":- interface" or in one that starts with
":- implementation". The two are related, but not identical, since a .int
file can (and often does) have an implementation section. Call the two
notions "file kind" and "section kind".

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".

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".

Does anyone have any other suggestions, or opinions on the relative
or absolute desirability of any of these choices? 

Zoltan.