Lens

[jeffreyrosenbluth]

No description provided.

[byorgey]

Hmm, there are quite a few things in -core which were cute as accessor names but are sort of strange and ugly as lens names, e.g. unTransInv, appTrace, inEnvelope, runQuery, unQD, unSubMap. Basically anything beginning with app, run, un... Since we're going to be breaking things anyway I wonder if we should consider renaming these. Actually, in the case of appFoo and runQuery we could even leave appFoo and runQuery as backwards-compatible partial applications of view. What do you think?

As concrete suggestions, perhaps something like traceFun, envelopeFun, and queryFun? (or ...Func, or ...F?) And instead of unQD we can just have qd, and so on.

Thoughts?

[byorgey]

Getting rid of all these in... functions makes me so happy. =)

[bergey]

Yeah, I noticed those. The unFoo series especially bother me. I didn't want to come up with a new scheme myself, especially since I was changing code that I had never looked at before. Any of your suggestions seem better than the current naming. I don't like fooFun as much - every time I see names like that I stop to wonder what's so fun about foo.

[jeffreyrosenbluth]

I agree, we should change the names and I don't like fooFun either. I have a slight preference for FooF

[byorgey]

Is there a lens for Max? PResumably this could become just over (inEnvelope . mapped . mapped . maxLens) t or something like that.

[bergey]

startling on #haskell says there should be a Control.Lens.Wrapped instance for Max, but there is not. I can write one, but that doesn't help us right now. Also, it's (Max .) because we're taking (v -> Scalar v) to (v -> Max (Scalar v)); so we'd need to find a lensed ("optical"?) way of writing that, also.

[byorgey]

Ah, OK. Let's not worry about this then.

[byorgey]

OK, point taken, forget about fooFun then. Shall we just go with fooF then? (Of course we can't generally use foo because those names are already taken --- envelope, trace, query, etc.)

Concrete suggestions:

• unTransInv -> transInv
• appTrace -> traceF (and re-export appTrace = view traceF)
• inEnvelope -> envelopeF
• runQuery -> queryF (and re-export runQuery = view queryF)
• unQD -> qd
• unSubMap -> ... hmm, not sure about this one. subMap is already taken.

[bergey]

I restored appTrace and runQuery as non-lens field accessors, without an underscore. I removed the other newtype field names while adding Wrapped instances. I'm fine putting them back, of course.

I used a mix of makeWrapped calls (where easy) and explicit instances. The explicit instances help in Types.hs, because of the cyclic dependencies, and where there are complicated type constraints, in particular where the type needs to refer to a type family.

makeWrapped produces some very ugly signatures:
Wrapped (Point v0 -> m0) (Point v_16274429970 -> m_16274429980) (Query v0 m0) (Query v_16274429970 m_16274429980)
One last thing to decide is whether it's worth replacing makeWrapped with explicit instances to have nicer signatures. I don't see an equivalent to makeLensesWith.

[byorgey]

Ugh, those are really ugly signatures indeed. How much work is it to write the signatures manually? Or, if we want to be extra ambitious, how hard would it be to submit a patch for makeWrapped which generates nicer signatures? @mgsloan, maybe you have an idea about that?

[mgsloan]

@byorgey Yeah, certainly seems doable - it should be a matter of replacing a newName with a mkName. Since this is a top-level definition, there's really no reason to have unique names for its type variables!

You would have to make sure that none of the type variable names you use alias eachother, though. This is probably why it uses newName.

[bergey]

Writing the instances manually is very easy. I'd rather leave improving makeWrapped to someone who's used TH before.

I think this branch is just waiting for -lib to be ready, now. (So let me know if you see something I missed.)

[mgsloan]

Yeah, that's quite reasonable. Having TH handle the boilerplate of isos is much less important than with lenses / traversals / etc.

[byorgey]

OK, sounds good. And re: merging, yeah, once we polish up all the lens branches I'll merge them all at once.