Tuple syntax inside expressions

[kenbot]

Possible syntax extension:

get"$foo.(bar, baz).blah"
// (foo.bar.blah, foo.baz.blah)

get"${List(1,2,3)}.(*, [0])"
// List((1,1), (2,1), (3,1)) 

I suspect that a user could guess the meaning without reading documentation, although the syntax is certainly not as universally recognisable as the existing features. This might greatly increase the internal complexity of the implementation, especially if the (...)s can be recursively nested.

This would significantly increase the complexity of the AST, which would become explicitly recursive, and the parser would need to be expanded. This might pose a problem for the detailed error messages - should each intermediate and sub-expression in the tree be shown in the table as a separate line? I suspect so.

[kenbot]

Something like half the Monocle questions in StackOverflow and Gitter are about lens products, and as @julien-truffaut endlessly points out, it breaks the lens laws if the same data gets referenced more than once. So this can't be done, unless Goggles decides to provide syntax sugar for lawless behaviour that is not directly supported in either Monocle or Control.Lens. Which it shouldn't.

Now.

It is actually possible to wring some guaranteed lawful behaviour out of this: get mode will always be lawful, because we know it won't be setting anything. Furthermore, even for set & lens modes, if no Monocle optics are interpolated, we can introspect on the expression and determine whether each field is referenced once only, and fail compilation with a helpful message if not.

The question is, is it worth it introducing all this syntactic weight for such a constrained benefit? On the other hand, if the feature is dropped, how can #13 (support for successive or nested modifications) be satisfied?

[kenbot]

Closing, I don't think I can salvage this idea.