[m-dev.] Update library pragma C code

[Peter Schachte]

On Mon, 3 Aug 1998, Thomas Charles CONWAY wrote:

> Peter Schachte, you write:
> > The reason I mention this now is that I was thinking that the current
> > may_call_mercury/will_not_call_mercury labeling is really a bit too limited,
> > and while you're monkeying with this stuff anyway would be a good time to
> > generalize it a bit more.  I think it would be better if that sort of info
> > were given as a list of "tags", so that the set of possible tags could be
> > expanded with the evolution of Mercury.  I'd like to propose the addition of
> > may_trail/will_not_trail as the first extension.
> 
> In uncommitted changes ... I've added functionality to allow a list of
> attributes to be attached to c code pragmas. Eg:
> 	pragma c_code(foo(...), [will_not_call_mercury, threadsafe], "...").

Wouldn't thread_safe be more consistent with Mercury naming standards?

> It would be a relatively minor change to add other flags
> (eg may_need_trailing) or whatever. Of course, getting the compiler to
> make use of that would be a bigger task.

Indeed it would.  My concern was that the infrastructure allow such flags to
be added. 

Is this a backward-compatible change?  Ie, when this change is committed,
will it still be possible to write

	pragma c_code(foo(...), will_not_call_mercury, "...")?

One other comment:  I think it may be better for the default to be the
assumption that code does not call Mercury, and to assume that C code does
no trailing.  My reasoning for this is that most foreign code does not trail
and does not call mercury, and does not use other funny facilities of the
foreign interface that should perhaps be declared.  It should be easy to
document in the section of the reference manual on calling Mercury from C,
and in the section on trailing, that if these facilities are used, a special
flag must be included in the pragma c_code declaration for the function that
uses that facility.  It would be much clumsier, IMHO, to document in the
section on calling C code from Mercury that users should include the flag
will_not_call_mercury *unless* the function calls mercury, will_not_trail
*unless* it does trailing, will_not_muck_something_else_up unless it uses
the muck_something_else_up facility, etc, particularly when users may not
know anything about those features.

thread_safety may be an exception to this argument, if, as I suspect, users
don't need to use any particular mercury facility in order not to be thread
safe, and much user code (that uses any global state) will be thread_unsafe. 
Is this the case, Tom?  If so, I think presumption of thread_unsafeness may
make sense. Then again, we presume innocence of impurity. 

If we presume use of every possible feature and guilt of every possible
flaw, users will start putting all these flags in all their foreign code by
habit (or by cut-and-paste), and are probably no more likely to get them
right than if they only document the used features and actual flaws. 


-Peter Schachte               | Life is what happens to you when you're
mailto:pets at cs.mu.OZ.AU       | making other plans.
http://www.cs.mu.oz.au/~pets/ |     -- Betty Talmadge 
PGP: finger pets at 128.250.37.3 |