Here is a great "Monoid found in the wild story": I just implemented a library for binary message serialization that follows Google's protocol buffer format. The documentation of this was very scattered in some respects but I kept reading snippets which I have pasted below. The effect of these snippets is to document that the messages on the wire should mimic an API where they can be combined in various merge operations (right-biased, concatenation, and recursive merging), and that well-formed messages have default values for all fields (which can be set in the spec). So the code below is a well thought out collection of properties that has reinvented the wheel known as "Monoid", so the Haskell API creates Monoid instances. http://code.google.com/apis/protocolbuffers/docs/encoding.html
Normally, an encoded message would never have more than one instance of an optional or required field. However, parsers are expected to handle the case in which they do. For numeric types and strings, if the same value appears multiple times, the parser accepts the last value it sees. For embedded message fields, the parser merges multiple instances of the same field, as if with the Message::MergeFrom method – that is, all singular scalar fields in the latter instance replace those in the former, singular embedded messages are merged, and repeated fields are concatenated. The effect of these rules is that parsing the concatenation of two encoded messages produces exactly the same result as if you had parsed the two messages separately and merged the resulting objects. That is, this:
MyMessage message; message.ParseFromString(str1 + str2);
is equivalent to this:
MyMessage message, message2; message.ParseFromString(str1); message2.ParseFromString(str2); message.MergeFrom(message2);
This property is occasionally useful, as it allows you to merge two messages even if you do not know their types.
And this at http://code.google.com/apis/protocolbuffers/docs/proto.html
As mentioned above, elements in a message description can be labeled optional. A well-formed message may or may not contain an optional element. When a message is parsed, if it does not contain an optional element, the corresponding field in the parsed object is set to the default value for that field. The default value can be specified as part of the message description. For example, let's say you want to provide a default value of 10 for a SearchRequest's result_per_page value.
optional int32 result_per_page = 3 [default = 10];
If the default value is not specified for an optional element, a type-specific default value is used instead: for strings, the default value is the empty string. For bools, the default value is false. For numeric types, the default value is zero. For enums, the default value is the first value listed in the enum's type definition.