Jesús López-González

Does it make sense to place `MapAlg` and `At` in the same folder? What are the differences between the abstractions located in *op* and the ones located in *lib* to...

Our current indexed optic fundamentals are not very solid. We should take a look at the state-of-the-art of indexed optics to check its validity. By now, they work for our...

The performance of the standing doobie mapping is not good, since we're doing too many accesses to the database. In order to reduce them, we're probably gonna need `Free` representations,...

The facilities to deal with Doobie are very experimental. Thereby, we need to determine the optimal way to map our data layer into this technology.

We provide some utilities to create optic algebras from monocle optics. However, they were created in an ad-hoc way, to fulfill the needs from the applications that we were working...

We define our entities in the data layer this way: ```scala trait Entity[A] { type P[_] } ``` We know that `P[_]` and `A` are related, since `P` is somehow...

Current algebra of `MapAlg` is not straightforward. Mimic the interface from the standard collection library. In addition, consider moving this algebra to the *raw* section if that makes sense.

When defining an association between entities, we need something like this: ```scala trait Person[Pr] { type P[_] type Ad; val Address: Address[Ad] val optAddress: OptionalAlg.Aux[P, Address.P, Ad] } ``` This...

Each optic algebras comes along with the laws that it should hold. We provide a ScalaCheck hook to test them, but it turns to be useless, since generating the evidences...

Right now, we're publishing *stateless* in our own (Habla Computing) repository. This is producing warnings on SBT 0.13, and it doesn't even work for SBT 1.0. Since the project is...