corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <pmke...@apache.org>
Subject Re: lenses
Date Mon, 15 Jun 2015 17:00:39 GMT
> On 15 Jun 2015, at 7:59 pm, Ian C <ian@amham.net> 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
pmkelly@apache.org

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)


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message