recursion-schemes VS klister

Reasonably proud of my part 2 solution, although would like to try using a recursion scheme rather than unstructured recursion:

Yeah, that project is pretty much at the bottom of my list, unfortunately. My top projects these days are mgmt, klister, recursion-schemes, and hint... And that's already too much!

In a programming context, recursion schemes can be used to write recursive (or corecursive) functions, by automating/abstracting away the common boilerplate part of actually doing the recursion. They take the form of polymorphic higher-order functions, which can be imported from a library like this classic one.

Maybe I didn't link the best post. It is unfortunately the only one I know that uses Rust. If you are able to read Haskell, the documentation for the recursion-schemes package might be a better resource?

Writing something as a type of fold over an infinite sequence is nicer than using recursion directly in my opinion. See: https://hackage.haskell.org/package/recursion-schemes

Consider recursion schemes! It let's you separate the logic of how your recursion is structured on your data, and the logic of what you're doing on each recursion stage. So e.g. you can write the core logic of a recursive linked list summation as just fun x accum -> x + accum, and then you just find the appropriate recursion scheme to pipe the list values into x and handle recursing to build accum (a catamorphism in this case)

It's a pretty complicated bug, documented in details at https://github.com/recursion-schemes/recursion-schemes/issues/50

It’s also trivial and easy in Haskell — you just need an instance of `Foldable` or `Traversable` on your collection, and then you can fold or traverse it in a configurable way. Or for recursive structures, use https://hackage.haskell.org/package/recursion-schemes. Or even just pass a traversal function as an argument for maximum flexibility.

https://hackage.haskell.org/package/recursion-schemes is the "normal" library for this type of generalized folding. It even contains Base instances for Maybe and Either.

I've been working on a system which uses recursion-schemes to annotate a recursive type. The annotated tree itself is pretty simple; at each level, we pair the annotation with the base functor, or

Yeah, that project is pretty much at the bottom of my list, unfortunately. My top projects these days are mgmt, klister, recursion-schemes, and hint... And that's already too much!

case is a special form, ie a bit of core syntax, but, interestingly, data is not. (It is presumably a macro; typechecking is actually done as a part of macro expansion.) The syntax remains pretty uniform. Or, in Klister, type ascription is done via normal S-expression syntax with a form called the, as (the $type $expression); again, the syntax is uniform.

Shameless plug: we don't have that problem in Klister, because our equivalent to main is a run macro which runs an IO action, and your alternate prelude can define its own run macro which expects an IO action from your alternate prelude.

Klister is very similar to Hackett, but implemented in Haskell instead of Racket, and my most recent PR is from 20 days ago, if that's the metric which counts for you. Still very much of a WIP though.

You might be interested in Klister: https://github.com/gelisam/klister

I've now also found an implementation for klister, which is meant to interleave type checking with macro expansion.

In Klister, which already has Scheme-like macros and Haskell-like types (polymorphism, algebraic types and higher-kinded types, but not yet fancier types like RankNTypes and GADTs), our plan to get the best of both worlds (lexical syntax and typed ASTs) is to separate parsing from macro evaluation. That is, users write their programs using the surface syntax of s-expressions, parsers parse those into typed ASTs, and macros are typed by the type of the ASTs they receive as input and produce as output. At this stage this is only a research idea, I don't know if that's going to work out yet, but I hope so!