[m-dev.] naming policy for functions in trace/*.c

[Mark Anthony BROWN]

Fergus Henderson writes:
> 
> Hi,
> 
> What's our naming policy for functions in trace/*.c?
> If the answer is that we don't have one, what should it be?
> 
> If I remember correctly, when we initially created the `trace' directory
> and the libmer_trace library, I think I suggested that we should use a
> different prefix than `MR_', because `MR' stood for `Mercury Runtime' and
> was supposed to be used for things that went in the libmer_rt.
> I think Zoltan suggested that we use `MR_trace' as the prefix for
> the stuff in the new library.  But that seems to have been inconsistently
> applied:

[table deleted]

Yes, this is my recollection too.  There is a few reasons why
it has been inconsistently applied (none of them particularly good):

i)   when moved, the functions often keep their original name
ii)  when names start getting long, it is too tempting to
     break the rules
iii) once i) and ii) have happened, it is just as consistent
     to stick with plain old "MR_" as the prefix.

> So, any suggestions?
> 

Use "MR_" as the prefix for functions/macros that are part of the
core of the runtime system (ie those things in runtime/)

Use "MR_*_" as the prefix for functions/macros/preds that are
associated with the runtime, but not part of the core.  The "*"
should be a single word or acronym; an hierarchical scheme
(like MR_trace_, MR_trace_external_, MR_trace_decl_, MR_trace_decl_blah_, ...)
would get too unwieldy, IMHO.  I don't recommend "MT_*" as the
prefix, since this could be confused with something to do with threads.

Use "ML_" as the prefix for things that are exported to C from
the library.

So to summarise, we would have:

	MR_*			Runtime
	MR_trace_*		Basic tracing stuff, plus the internal
				debugger
	MR_browse_*		Term browser
	MR_DD_*			Declarative debugging stuff
	MR_ext_*		External debugger

and so on.

An alternative might be "MR_" for the runtime, "ML_" for the library,
"MDB_" for the basic debugging stuff, and "MDB_*_" for the various
components of the debugging environment (eg MDB_internal_, MDB_external_,
MDB_decl_, MDB_browse_, etc).

Come to think of it, I prefer this second alternative.  Any other
comments?

Cheers,
Mark
-- 
Mark Brown  (dougl at cs.mu.oz.au)       )O+   |  For Microsoft to win,
MEngSc student,                             |  the customer must lose
Dept of Computer Science, Melbourne Uni     |          -- Eric S. Raymond
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------