no_std support?

[SerenaLynas]

First of all, nice crate!

I was considering using this in an embedded project, but it would need to be no_std. I took a cursory glance at the code and I dont think it would be too hard to support -- switch std traits to their core:: variants and feature gate the stuff that is std-only. Is this something you would like to add to the project? I might be able to help.

[nothingnesses]

Hi @SerenaLynas, thanks for your interest in the project and for opening this issue! I'm definitely open to adding support for no_std use-cases, but I haven't yet done any work on this front, since I'm currently focused on the effects system. That said, I am open to contributions, and I think your understanding is correct. Most of this work will involve converting std:: paths to their core::/alloc:: equivalents and feature-gating the genuinely std-only parts.

If you're willing to work on it, some things worth knowing:

• CONTRIBUTING.md covers the process and the dev environment (Nix, with everything run through just recipes rather than bare cargo; just --list shows what's available). PRs need to pass just verify and should come with tests for new behaviour.
• The realistic target is probably no_std + alloc rather than no-alloc, since the library relies on boxed closures and Rc/Arc-backed types pretty much everywhere. So we'd most likely want a default-on std feature, extern crate alloc, and the mechanical conversion you described.
• The main genuinely std-only piece I can think of is the thread-safe half of the lazy machinery, which uses std::sync::LazyLock/OnceLock. Those have no core equivalents, so they'd need to sit behind the std feature (or an embedded-friendly alternative, if you actually need them). The optional rayon and stacker features are also std-only and should probably imply std. Threads only show up in tests and doctests, which can stay as they are.
• Dependency-wise it should be fine: frunk_core and thiserror v2 both support no_std. It's probably worth re-running just deny after any manifest changes though.
• One subtlety: fp-macros runs on the host, so the macro crate itself doesn't need to be no_std, but the code it emits ends up in user crates, so any emitted ::std paths would need to become ::core/::alloc.
• The doctests won't catch regressions here, since doctests always build with std. So the port would need its own gate: a justfile recipe that builds with --no-default-features for a no-std target, something like thumbv7em-none-eabihf (the existing effects-feature-off recipe is the pattern to copy), plus a CI job that runs it.
• The biggest gotcha is timing: the effects subsystem is in the middle of a ground-up rebuild on a long-lived branch, so a whole-crate sweep would conflict badly with current work. I'd suggest scoping a first PR to the stable core (the kinds/classes machinery and the everyday container types) and leaving types/effects (already behind the off-by-default effects feature) plus the Free/Coyoneda machinery alone for now, since the rebuild rewrites those too. The effects feature can just imply std until it lands.

If you have any questions, I'd be open to discuss the work further before you start, so we can iron out the details.

Out of curiosity, what's your embedded project about and how do you plan to use fp-library in it?