sicmutils VS frunk

They seem to be in the middle of transitioning from the old repo.

There are some good resources here including some nicely formatted HTML versions of the book: https://github.com/sicmutils/sicmutils/wiki/SICM-and-FDG-Lea...

^ The Github repo contains a Clojure version of the Scheme library used by the book.

If you want to try this out, give the sicmutils Computer Algebra System a go (I’m the maintainer). Repo lives here: https://github.com/sicmutils/sicmutils

The library works in the browser as well, so interactive TeX rendering from Clojure symbolic expressions and functions is available at the quickstart page here: https://nextjournal.com/try/samritchie/sicmutils

I am the maintainer of the "sicmutils" computer algebra system in Clojure, and I think that you'll find it very nice for your project: https://github.com/sicmutils/sicmutils

https://github.com/sicmutils/sicmutils is a really interesting development in the direction(s) you stated in b. Since terms can be rendered in various ways (latex, js, etc.), they can be embedded in documents, web pages, etc. You can go from symbolic expressions to animated dynamic systems with relevant formulae.

- multiple stories about the same piece of code, but all with the ability to IMPORT the story as a library

I've been writing sicmutils[0] as a "literate library"; see the automatic differentiation implementation as an example[1].

A talk I gave yesterday at ELS demos a much more powerful host that uses Nextjournal's Clerk to power physics animations, TeX rendering etc, but all derived from a piece of Clojure source that you can pull in as a library, ignoring all of these presentation effects.

Code should perform itself, and it would be great if when people thought "LP" they imagined the full range of media through which that performance could happen.

[0] sicmutils: https://github.com/sicmutils/sicmutils

[1] autodiff namespace: https://github.com/sicmutils/sicmutils/blob/main/src/sicmuti...

[2] Talk code: https://github.com/sritchie/programming-2022

[3] Clerk: https://github.com/nextjournal/clerk

Hey, so fun to see this here! These demos feature work from https://github.com/sicmutils/sicmutils and the newly maintained-by-me Mathbox library.

I’m around and happy to answer any questions about the library, future plans, etc.

Give my SICMUtils computer algebra system a look as well, if you like Lisp / Clojure: https://github.com/sicmutils/sicmutils

Works on the web too, which is a big boost for sharing work.

It is good enough! Almost all code forms from the book live in the tests (see the FDG directory[0], for example), and there are a few nice environments like Nextjournal[1] where everything from the books works in the browser.

The Clojure port is quite fast, faster than the original for all benchmarks GJS has sent me, and more fleshed out. (That will change, as I've been pushing bugfixes and performance improvements back upstream as I go, as a meager gift to GJS for making this huge, amazing library in the first place.)

I actually wrote to GJS this morning asking for instructions on how to compile the original "scmutils", since I have the same problem. He responded saying he'll get back to me this afternoon, so I'll post here once I have details.

If you are still interested in getting the books going with MIT-Scheme, I put a decent amount of work into the exercises using the original codebase here[2], including a dockerized version of mit-scheme[3] and the scmutils package[4] that might be useful.

- [0] https://github.com/sicmutils/sicmutils/tree/main/test/sicmut...

- [1] https://nextjournal.com/try/samritchie/sicmutils/

- [2] https://github.com/sicmutils/sicm-exercises

- [3] https://hub.docker.com/r/sritchie/mit-scheme

- [4] https://hub.docker.com/r/sritchie/mechanics

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.