Algebird VS frunk

https://github.com/twitter/algebird (production ready, used at Twitter, but for the JVM)

Hey, I have... I'm a co-author of Algebird[0], which has many ideas that I'd pull over.

I'm hoping to introduce Clojure's "spec" or "schema" libraries so that the types at play can at least be inspectable inside the system. In a fully typed language, I'd implement the extensible generics as typeclasses.

I suspect it would make it quite a bit tougher (at least in the approach I'm imagining) for folks to write new generic functions, due to many type constructors...

On the other hand, the complexity is there, even if you don't write it down!

It would be a big project, and a worthy effort, to write down types for everything in SICM.

[0] https://github.com/twitter/algebird

So rust doesn't support variadics, but I have heard some murmurings around the topic. In the meantime, you can still do a lot with recursive tras. The frunk crate makes working with them a lot easier: In this case

I think the closest possible approach is the one used in frunk where those consecutive types are nested recursively (creating a linked list on type level basically) and special type is used as the end.

I suggest looking into frunk. You could convert the struct into an HList, map over the values to convert and convert into the target struct. README has some relevant examples.

So a while back I got interested in how rust could provide parallel/concurrent APIs that prevent deadlocking shared state. I now created a Proof-of-Concept stream processing library that attempts to do that. The library makes prodigious use of heterogeneous lists from the frunk library. The basic idea is that you can build a graph by combining source streams as source nodes and mutexes for state, then you can add nodes which subscribe to subsets of the previous nodes using various combinators. You can either

Hey, #[derive(LabelledGeneric)] from frunk does something like this, but without const generics, so it has odd representations for things like type-level strings (it's represented as a tuple of chars so (a, b, c) is the type-level representation of the string "abc")

I don't understand why you call it "trickery or "fake". Church encoding of natural numbers is the same technique used in Agda, Coq and Idris to represent the Peano numbers. It's a completely valid encoding and isomorphic to any other representation.

You don't need to use a fixed-length array either - you can used a recursive linked list at the type-level for an unbounded encoding [1]. The Scala library is an example of that; the Github page even has an example of encoding arbitrary units like sheep and wheat.

[1] https://github.com/lloydmeta/frunk

I wonder if frunk can (ab)use this kind of trick to make their crate even more powerful. IIRC they have a bunch of amazing and horrible workarounds to work with type-level lists.