> On 15 Jun 2015, at 7:59 pm, Ian C <[email protected]> wrote:
> 
> Hi Peter,
> 
> I see in the word processing you use a series of structures with get and
> put function pointers (lenses ) to drill down - focus on  - particular
> parts of the document.
> 
> Do you think we should replicate this for odf processing?
> 
> I was thinking just of a series of functions to drill down but hadn't seen
> the funky lenses idea. I kind of like it but wonder as to whether it helps
> or obscures?

The design of the Word filter (and what I’d had in mind for other filters but 
had not gotten round to implementing) is based on the idea of bidirectional 
transformation, which is actually a whole field of research within the domain 
of programming languages. The best overview I’ve seen is this:

http://www.cis.upenn.edu/~bcpierce/papers/icmt-2009-slides.pdf 
<http://www.cis.upenn.edu/~bcpierce/papers/icmt-2009-slides.pdf>

There’s a lot of underlying theory here (and in other papers), which I’ve yet 
to fully explore myself, but currently the parts of the theory I’ve used are 
the notion of get/put/update operations. When I started out with the original 
version of the code (in Objective C), each lens was a class.

A key aspect of lenses (at least in other work that’s been done, not fully 
realised in the current DocFormats implementation) is their composability. That 
is, the notion of building up larger/more complex lenses out of smaller ones, 
combining them using different relations.

I’ve got a lot more to say on this topic, and I’ll outline this in a separate 
email as it’s a pretty long discussion.

—
Dr Peter M. Kelly
[email protected]

PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

Reply via email to