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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
