Oddly enough, it allows lossy bidirectional translations. The general setup is that you have an "abstract" representation of some information, and a "concrete" representation that may have extra details in it. Then the three key operations are:
"get" abstract info from a concrete version;
"put" new abstract info into a concrete version, returning a new concrete version;
"create" a new concrete version from abstract info, presumably filling in extra details with defaults.
The running example in their tutorial is a database of information about composers. The "concrete" version is an XML file. The "abstract" version is something more compact, one entry per line, which omits the nationality data in the XML file.
Comments
Oddly enough, it allows lossy bidirectional translations. The general setup is that you have an "abstract" representation of some information, and a "concrete" representation that may have extra details in it. Then the three key operations are:
"get" abstract info from a concrete version;
"put" new abstract info into a concrete version, returning a new concrete version;
"create" a new concrete version from abstract info, presumably filling in extra details with defaults.
The running example in their tutorial is a database of information about composers. The "concrete" version is an XML file. The "abstract" version is something more compact, one entry per line, which omits the nationality data in the XML file.
Oh, ok....bidirectional != roundtrip-able
Now that makes sense.
Not quite. A lens comprises three operations:
And the GetPut, PutGet, CreateGet laws require of every lens that: In other words, if there are no edits, then it is a round trip. The real inequality you mean is bidirectional != bijective.(EDIT: for typesetting equations.)