''What exactly is and isn't a "message"? It's a term commonly found in, but not limited to, the SmallTalk community.''

A "message" is a bounded package of information that can be/has been/is in the process of being delivered from a sender to a recipient. 

That's all. The rest is explanation. Use of 'message' tends to imply the following:

* A message is ''not'' a continuous stream of information, because such streams are neither bounded nor fully packaged prior to delivery. For example, you would not call the continuous data feed from a webcamera a 'message'. That said, one might send messages across a stream, or may emulate a stream as a sequence of messages. 

* The recipient decides what to do with the package of information. In this sense, a message communicates across module or component boundaries, allowing for InformationHiding (the recipient can hide implementation from the sender). Messages are appropriately also used for InterProcessCommunication. 

* It suggests a concurrency model where the sender can continue taking other actions after sending the message on its way. 'Synchronized' MessagePassing tends to mean that the sender will wait for a reply before doing anything else. Despite this, many common implementations of MessagePassing are synchronous by default.

* Once sent, a 'message' (or a copy thereof) is out of the sender's hands and cannot be modified further by the sender. Of course, a message could contain references or URIs to objects that can be modified further. In that sense, the message itself may be rather small, consisting only of a reference - a bit like someone handing you a business card that contains only a phone number or identifier for a PO box. One may measure the size of the message by how much of the 'package' is immutable to all but the recipient.

The term message is almost always used in the context of MessagePassing. MessagePassing communication is important to ObjectOriented programming and in InterProcessCommunication (e.g. ErlangLanguage processes and ActorsModel are both based heavily on MessagePassing).

MessagePassing discriminates from a variety of other communication mechanisms:

* SharedMemory (including variants such as: DataBase, TupleSpace, BlackboardMetaphor, FileSystem)
* FunctionalReactiveProgramming
* Streaming Data
* Concurrent ConstraintProgramming (delayed, iterative, partial bindings between attributes)

The Message itself - ''a bounded package of information that can be/has been/is in the process of being delivered from a sender to a recipient'' - certainly distinguishes from data streams (which have sender and recipient, but are not bounded). It also is distinguishable from reactive expressions, constraints, and shared memory resources - none of which have specific recipients or senders. 

Beyond that, 'Message' discriminates from the process of MessagePassing in the same sense that Mail can be distinguished from act of pushing bags between the post office and the mail trucks.

''How is a message distinct from the following?''

* ''Function call''
** A function call is a process, certainly not a message. You might say the parameters and function ID are messages, though. (RemoteProcedureCall is clearly a form of MessagePassing, and sending <methodID,Parameters> to objects is the basis for messages in ObjectOriented systems.)
** ''But messages may be implemented with functions and vise versa. The "user" cannot tell the difference (see the under-the-hood implementation). DataAndCodeAreTheSameThing. Is the definition tied to implementation?''
** It is unclear what you mean. You could package up a function's ''definition'' and send it somewhere, as a message, but what does that have to do with the function '''call'''?
** ''And why do "remote" calls qualify but not local ones? What's the threshold distance?''
** "Remote" function calls are not messages.  They are typically implemented using messages.  However, a function call is no more a message than a post-office letterbox is a letter.  Or, alternatively, a function call is not a message, in the same way that if I write "cook dinner at 6pm" on a postcard and mail it, the act of cooking dinner at 6pm is not a message.  The postcard is the message.  Cooking dinner is the function call.
*** ''Note I used function *call*, not function. It is "function call" that is the issue, not function by itself. The function call is roughly analogous to your "cook dinner at 6pm" postcard, which looks as messagey as anything else.''
*** Sigh. You asked: ''"Why do 'remote' calls qualify [as Messages]?"'' The answer is: they don't. Clearly written above is: "RemoteProcedureCall is a form of '''MessagePassing'''", not "RemoteProcedureCall is a form of Message".
*** ''Okay, let's do this one step at a time because side issues keep clouding the important stuff. You said, "RemoteProcedureCall is clearly a form of MessagePassing, and sending <methodID,Parameters> to objects is the basis for messages in ObjectOriented systems." correct? So <methodID,Parameters> is a "message", correct?''
*** Indeed.

** And MessagePassing is distinct from the Message, in the same way that M''''''ailDelivery is distinct from the Mail, and B''''''icycleRacing is distinct from the Bicycle. I bet a two year old would get it.

* ''Query''
** A message may contain a query, certainly. The query is not a message, though.
** ''Why not?''
** The abstract notion of "love letter" is not a message, but a specific one sent from you to your beloved is a message.  Replace "love letter" with "query" and "beloved" with "DBMS". 

* ''HTTP "GET" or "POST"''
** Sending a whole GET or POST across an HTTP stream is message passing at that layer.

* ''File "Save"''
** The act of persisting a file is a process, not a message. And we typically do not send a 'save' message to our files.  
** ''No, but selecting "File/Save" from a UI menu, for instance, may result in a message being sent through the window manager, which the program then interprets to begin the process of persisting the file.''
** True.  A message is not the process, nor is the process a message, but messages may be used as part of the process.
** {See function scenario above for issues surrounding "process".}

I'm not getting the message (bad pun). I still don't see a useful distinction.

''If you are interested in elucidation, you must ask the right questions, or at least clarify the nature of your blindness. Do you suspect MessageDefinition makes a distinction, but find yourself ignorant of its utility? If so, where? Or are you seeking a distinction where you suspect MessageDefinition makes none? If so, why? Be precise.''

The rules are not clear. I'd like to see the rules stated, and where and how the test scenarios pass or fail the rules, hopefully with unambiguous descriptions.

''See top of page, to wit: A "message" is a bounded package of information that can be/has been/is in the process of being delivered from a sender to a recipient.  Can you identify both a sender and a recipient?  Is there a package of information?  Is it bounded?  Etc.  Now please stop quibbling.  If you're bored, go do something.''

Hey rudeboy, your definition is vague. Many things fits those. Bits are ALWAYS jumping around from spot A to spot B ("sender" and "recipient"). "Packaged" and "bounded" is also too vague, and often relative. It's a Handwavy buzzword and I'm calling people on it even if it's painful for them to face the ugly truth. 

* ''The definition is clear, but you appear to be conflating various applications of MessagePassing with the messages themselves. You appear to be confusing the post office with the mail.''

* Also, "bounded" is very well defined, in both Math and CS. For messages, "bounded" means that, at the very least, upon receiving a message you can place an upper bound on its size (in the units of information - bits) and place an algorithmic upper bound on the amount of time it will take you to read all those bits. "Packaged" means the message is grouped 'together' in space and time rather than scattered across space or time. I'll agree this latter term is 'relative' in some theoretical senses, but it is rarely vague or unclear in practice.

''To reasonably claim a definition is "vague", you must first find a relevant borderline case in reality. Can you do so?''

----
FebruaryTen