Syntax

[eparejatobes]

Including how to better approach this, both from the user and library point of view.

There's no simple way of avoiding explicit imports, as the types depend on these values. The only approach that looks feasible is a compiler plugin in the spirit of local-implicits, which would add syntax for each sort of structure. We will need

1. one term for each type of syntax we want to provide
2. export the corresponding types and implicits required

This is too complex I think, and the improvement over an explicit import is not that significant. Just having something like this would be OK:

import syntax.scala.category._
val f = g >-> id[Z]

[eparejatobes]

I've managed to tweak local-implicits to generate val imports. This paves the way for the following

0. Define export types and ops classes for each notion. For example, if you have a cartesian category, you get the 1 and _ × _ types, plus standard product morphisms/combinators
1. Define value classes (mostly on morphisms) which provide infix syntax derived from the corresponding notion. In the cartesian category example, you get f × g as Syntax(f).×(g). Then syntax requires an implicit value of the corresponding type (cartesian category in this case)

2. use the local import construct for providing scoped implicits and types. Possible syntax:

   in(Scala.asDistCat) {
     any( f × g, both(i, j) ) + h
   }
   
   // for a monad
   in(FCMon.kleisli) {
     (f >=> g) ⊗ h
   }
   
   // etc etc

The usability improvements this would bring are truly exciting.

To think

• [ ] What's the best way of "reusing" syntax, if possible? is there something better than the approach outlined above?
• [ ] what happens with nested constructs and imports?
• [ ] do we want custom syntax? why? what's the point? why not make it standard for each entity?

[eparejatobes]

See ohnosequences/local-imports v0.4.0.

[eparejatobes]

Tests fail due to ohnosequences/local-imports#2.

[eparejatobes]

After thinking about it, I don't like custom syntax. Inside each entity, we should provide

• aliases for types (tensor, hom, ...)
• infix syntax for existing functions

This simplifies the syntax architecture.

[eparejatobes]

There will be some repetition in wiring implicits for nested components, but this only needs to be done once. I really like this approach.

[eparejatobes]

This works nicely. I'll leave it unmerged for a while, just in case.

[eparejatobes]

LGTM