Right on! And this reminds me of recent conversations regarding models, abstractions, and meaning. Sometimes, in math and in programming, meaning is in the syntax. For interoperability then the API's need to be only about syntax. Meaning is inside the payload, not the protocol.

This deserves on-line refs, but I don't have them handy right now.
 

I think I just ran down my own bunt as it skipped foul over the first-base line.

There's something about having API's be only about syntax that doesn't work. I don't see how there is any assurance of interoperability if API's are entirely syntactic. What am I missing?
 

You're absolutely right; I totally agree that syntax by itself isn't enough for contracts. So I think the semantics are crucial, but in API's, as with ordinary language, the semantics are loaded onto the words and symbols and syntax. The work of establishing meaning needs to be addressed.

Several years ago I got taken to the blackboard by a software architect for suggesting we do some system interface work in ISL (the interface language for ILU). The criticism was that ISL only provided syntax. I didn't have a good response, we never did deal with the semantics inherent in software interfaces, and we didn't make any progress.

[META COMMENT: experimenting w/ blog as medium to develop coherent thoughts.]
 

Oh my. Was I that forever-to-remain-anonymous software architect? [Meta-Comment: I suspect that a Wiki-like structure is going to be more useful for developing coherent thought, or perhaps none of the above.]

I agree that semantics are crucial and that the work of establishing meaning needs to be addressed. I would not be surprised, however, to arive at a place where we must disavow much content for the first sentence of this paragraph. So, neo-post-modern-reconstructionist software architecture, here we come.

I have in mind an example to work on. It starts as the following "precise" (but not-necessarily valid) statement in Java:

interface com.orcmid.cs.pa.Num
{
/* That is, defined in package com.orcmid.cs.pa
*/

com.orcmid.cs.pa.Num next();

com.orcmid.cs.pa.Num pred();

Boolean is0();
} // Num

Because I can't do much with typography and markup here, this use of Blogger comments is not going to work and we must find another venue. Notice there are several matters to ponder already:

1. What is the behavior that is part of the interface agreement, in terms of what an implementation must provide?

2. What is the abstraction in terms of which this is conveyed/explained? What do I/we mean by that?

3. How this behavior is exploited in accomplishing some other purpose by using it in/under the implementation of something we care about -- an application, if you will?

4. What is the (set of) tacit knowledge that applies here, who says, and how can you tell?

5. Where do we start and where do we end with this?
 

The "Boolean" in the interface declaration, above, should be spelled "boolean".

One thing to allow for is the fact that there can be mistakes in an expression of something.

Then there can be revisions and updating.  Assume, for now, that this is in pre-ALPHA state.

There is tacit inheritance in the use of this interface and that will have to be dealt with as well.  It is one of the places where the tacit shall be made explicit.

Finally, there is no question that this interface definition is platform specific.  It belongs to a specific framework and while it is abstracted from specific computer hardware, there is no question there is a tacit platform assumption.  It is the Java platform and all that entails.

I am just putting down some notes that will be best taken up and made into an organized discussion and description. We can do that later.
 

u