relational lens nice-to-haves

[jamescheney]

Harvested from #895 and other wishful thinking:

• more examples
• language integrated create table, other ways to make it easier to play with examples
• use the Links Serial type defined in the prelude for non lens tables as well.
• add support for DateTime type (once merged from temporal branch) to lenses
• cleaner integration of relational lens types with type inference
• ~~refactor relational lenses library to avoid replicating database interface code~~

EDIT: removed last item to split it out as a separate issue #1144

[dhil]

• make lenses a proper citizen in the Links ecosystem: lenses should depend on links, not the other way around (inversion of the dependency arrow).

[rudihorn]

* make lenses a proper citizen in the Links ecosystem: lenses should depend on links, not the other way around (inversion of the dependency arrow).

I disagree with this. Unless relational lenses can be implemented as a Links library as done in Haskell, there is no need to complicate the implementation of relational lenses by making them depend on Links. You said yourself that you don't want to face issues where relational lenses are broken by changes to Links, and in their current form the relational lenses code is more precise because e.g. the lens predicate language is more restricted than the full Links language. Doing this would kind of be like re-implementing the mysql driver to depend on Links instead of Links using it as a library which seems pointless.

[dhil]

The MySQL driver depends on Links, just as it should. Links does not depend on the MySQL driver, just as it should.

Links is the upstream product, everything else is a downstream product. Changes in the upstream will potentially have to be dealt with by the downstream, but never the other way around. Links is currently a downstream product to lenses, which makes lenses an improper extension to Links (it rather makes Links an extension to lenses). Abstractions from Lenses leak into the Links code base, which complicates the evolution of the core Links code base (I have previously mentioned a few examples such as names).

You said yourself that you don't want to face issues where relational lenses are broken by changes to Links [...]

I never said this. What I might have said is that I don't want to deal with the implications of the lens library on core Links code base.

[rudihorn]

By MySQL driver I meant the MySQL library (i.e. https://github.com/ygrek/ocaml-mysql). This library is not an "improper extension of Links", but is instead a dependency just as the relational lenses library is. The names problem was resolved super quickly and easily because the equivalent of the MySQL driver package is the translation code in core/lens_*, where the question of how the new change translates into the lens code only has to be solved in a single location.

There are also other undesirable consequences of doing things differently, such as the types module being required to depend on either the sugertypes or ir module to express predicates in a lens type, while both of these modules depend on the type of a lens. Currently relational lenses have a good divide between types of records, types of lenses and types of values, and these keep the code easier to understand and reduces the amount of error handling that has to be performed in the code. Changing any of this just throws those benefits away, complicates the code and will make any Links refactoring even more painful than it already is.

[jamescheney]

I think these two points are related:

• refactor relational lenses library to avoid replicating database interface code
• make lenses a proper citizen in the Links ecosystem: lenses should depend on links, not the other way around (inversion of the dependency arrow).

or at least I think what @dhil meant in the second bullet point is about related issues to the first.

I have been thinking about what would be a good/desirable architecture for nontrivial language extensions like lenses, and I don't have a solution. I think these two bullet points should be a separate issue, maybe broadened to "how do we accommodate deep language extensions in a modular way". Then we can argue about this there.

[jamescheney]

I think these two bullet points should be a separate issue

See #1144