In my system, you should be able to build up fisheye as a bidirectional program itself. (This is pretty easy, since DIV(attributes, [ html ]) and all of the other element constructors can easily be lenses!) In that case, it would be compositionally derivable that fisheye introduces no new data to the model.

So I don’t fully understand your problem, or what you mean by “[the] data the fisheye provides … should be made explicit, rather than being pulled out of a returned DOM node.” What do ‘data’, ‘explicit’, and ‘returned’ mean? I have the feeling that explaining my lens driver — the system which decides when to get and putback — would clarify things.

Yep.

>> Of course, if there’s no data to read out, it’s a boring lens, but so it goes.

How would it be clear what data the fisheye provides? I think it should be made explicit, rather than being pulled out of a returned dom node,
which is why I said module (not sure about state implications), though a return of a record would work superficially:

(module ‘fisheye’ (header : htmlb, buttons : list htmlb) (iconSize : number)
div(header, input({id: iconSize} /* lense magik */), map ( x -> div(x), buttons)))

…

x = fisheye(div(), (div(), div())) /* record: x.domNode, x.iconSize */

>> What does Crash have to do with Preston of the unending opinions?

Reminded me of one of the opinions he exposed to me, some reason I thought you were there to witness it.

You need a preview button :)

What does Crash have to do with Preston of the unending opinions?

(module ‘fisheye’ (header : htmlb, buttons : list htmlb)
{! header !}
{! button !})

…

or some similarly eye-gauging syntax. ‘buttons’ in the above case would naturally be a Behaviour, but what happens when we are describing a list with dragable items? Hello lenses.

It’s simple, obvious, and grunt work – but stops one of the biggest complaints against templating: the loss of modular reasoning.

Just be careful not to Crash (http://www.imdb.com/title/tt0115964/) – my lingering memory of Preston.

In your sense of “template as widget”, I’m not sure how lenses and templates are different at all. Lenses, in my proposed system, would be model-to-view isomorphisms. Any intervening “template” which expanded a view element to a more complicated view element could be nothing other than a lens — how else would be extract the data? So to say they’re orthogonal doesn’t even compute for me.

I am excited to see how the lens work will interact with animation. I’m not sure what attributes/elements an animation will need to affect; I think so long as id attributes are left alone, the lens system will be happy.

The race is on indeed! And it is of epic, Deathrace 2000 proportions. Call me Thomasina Paine.

Yes, if by exported variables you mean variables to be shared between a template instantiation and whatever code instantiated/embedded it. This interface is what I mean by allowing abstraction over templates: a widget template should be explicitely parameterized. The theory of lenses is orthogonal to templates, but I think most data passed into a template would be best described with lenses. I haven’t had a chance to read Pierce’s ~60 page report yet but the idea seems intuitive – I may be way off base.

>> As for abstraction, I think that should all take place in the code, not in the
template itself.

I do not know what you mean – I view the template as most of the code, with helper functions for describing the data relationships (the lenses) and animations (frp). I am interested in describing the smallest templates (for example, a display list) and then combining their instantiations into bigger templates, such as two lists sharing their data and styled extended with some externally defined animations.

It will be interesting to see when lenses would be more appriate than frp, more specifically in the gap between what I have been calling data relationships and animations.

The race is on: me with adding basic FOL style operators to frp for defining animations (a looser letrec) and you for lenses :) It will be kick ass if even just one of us delivers :)

As for abstraction, I think that should all take place in the code, not in the template itself. In fact, my thesis is that a succinct bidirectional specification (‘program’) of the presentation structure (along with functional reactive programing) is sufficient to connect the model to the view, i.e. act as a controller. In this case, templates aren’t necessary at all.

One should be able to cut a chunk of template out and abstract it.

As we’re in a position to provide this sort of approach, I think we should do it and let naysayers shove it and depend on the current approach of convoluted advice systems with callbacks.