[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt

[ChrisK]

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.