Frunk
frunk frəNGk
- Functional programming toolbelt in Rust.
- Might seem funky at first, but you'll like it.
- Comes from: funktional (German) + Rust → Frunk
The general idea is to make things easier by providing FP tools in Rust to allow for stuff like this:
use *;
let v = vec!;
assert_eq!;
// Slightly more magical
let t1 = ;
let t2 = ;
let t3 = ;
let tuples = vec!;
let expected = ;
assert_eq!;
For a deep dive, RustDocs are available for:
- Code on Master
- Latest published release
Table of Contents
Examples
HList
Statically typed heterogeneous lists.
First, let's enable hlist
:
extern crate frunk; // allows us to use the handy hlist! macro
use *;
Some basics:
let h = hlist!;
// Type annotations for HList are optional. Here we let the compiler infer it for us
// h has a static type of: HCons<i32, HNil>
// HLists have a head and tail
assert_eq!;
assert_eq!;
HLists have a hlist_pat!
macro for pattern matching;
let h: Hlist! = hlist!;
// We use the Hlist! type macro to make it easier to write
// a type signature for HLists, which is a series of nested HCons
// h has an expanded static type of: HCons<&str, HCons<&str, HCons<i32, HCons<bool, HNil>>>>
let hlist_pat! = h;
assert_eq!;
assert_eq!;
assert_eq!;
assert_eq!;
// You can also use into_tuple2() to turn the hlist into a nested pair
You can also traverse HLists using .pop()
let h = hlist!;
// h has a static type of: HCons<bool, HCons<&str, HCons<Option<{integer}>, HNil>>>
let = h.pop;
assert_eq!;
assert_eq!;
You can reverse, map, and fold over them too:
// Reverse
let h1 = hlist!;
assert_eq!;
// Fold (foldl and foldr exist)
let h2 = hlist!;
let folded = h2.foldr;
assert_eq!
// Map
let h3 = hlist!;
let mapped = h3.map;
assert_eq!;
Generic
Generic
is a way of representing a type in ... a generic way. By coding around Generic
, you can to write functions
that abstract over types and arity, but still have the ability to recover your original type afterwards. This can be a fairly powerful thing.
Frunk comes out of the box with a nice custom Generic
derivation so that boilerplate is kept to a minimum.
Here are some examples:
HList ⇄ Struct
extern crate frunk;
// for the hlist macro
extern crate frunk_core;
use *; // for the Generic trait and HList
let h = hlist!;
let p: Person = from_generic;
assert_eq!;
This also works the other way too; just pass a struct to into_generic
and get its generic representation.
Converting between Structs
Sometimes you may have 2 different types that are structurally the same (e.g. different domains but the same data). Use cases include:
- You have a models for deserialising from an external API and equivalents for your app logic
- You want to represent different stages of the same data using types (see this question on StackOverflow)
Generic comes with a handy convert_from
method that helps make this painless:
// Assume we have all the imports needed
let a_person = ApiPersion ;
let d_person: DomainPersion = convert_from; // done
LabelledGeneric
In addition to Generic
, there is also LabelledGeneric
, which, as the name implies, relies on a generic representation
that is labelled. This means that if two structs derive LabelledGeneric
, you can convert between them only if their
field names match!
Here's an example:
// Suppose that again, we have different User types representing the same data
// in different stages in our application logic.
let n_user = NewUser ;
// Convert from a NewUser to a Saved using LabelledGeneric
//
// This will fail if the fields of the types converted to and from do not
// have the same names or do not line up properly :)
//
// Also note that we're using a helper method to avoid having to use universal
// function call syntax
let s_user: SavedUser = labelled_convert_from;
assert_eq!;
assert_eq!;
assert_eq!;
// Uh-oh ! last_name and first_name have been flipped!
// This would fail at compile time :)
let d_user = convert_from;
Validated
Validated
is a way of running a bunch of operations that can go wrong (for example,
functions returning Result<T, E>
) and, in the case of one or more things going wrong,
having all the errors returned to you all at once. In the case that everything went well, you get
an HList
of all your results.
Mapping (and otherwise working with plain) Result
s is different because it will
stop at the first error, which can be annoying in the very common case (outlined
best by the Cats project).
To use Validated
, first:
extern crate frunk; // allows us to use the handy hlist! macro
use *;
use *;
Assuming we have a Person
struct defined
Here is an example of how it can be used in the case that everything goes smoothly.
// Build up a `Validated` by adding in any number of `Result`s
let validation = get_name.into_validated + get_age + get_street;
// When needed, turn the `Validated` back into a Result and map as usual
let try_person = validation.into_result
// Destructure our hlist
.map;
assert_eq! );
}
If, on the other hand, our Result
s are faulty:
/// This next pair of functions always return Recover::Err
let validation2 = get_name_faulty.into_validated + get_age_faulty;
let try_person2 = validation2.into_result
.map;
// Notice that we have an accumulated list of errors!
assert_eq!;
Semigroup
Things that can be combined.
use *;
assert_eq!;
assert_eq!; // bit-wise &&
assert_eq!;
Monoid
Things that can be combined and have an empty/id value.
use *;
let t1 = ;
let t2 = ;
let t3 = ;
let tuples = vec!;
let expected = ;
assert_eq!
let product_nums = vec!;
assert_eq!
Todo
Stabilise interface, general cleanup
Before a 1.0 release, would be best to revisit the design of the interfaces and do some general code (and test cleanup).
Benchmarks
Benchmarks are available in ./benches
and can be run with:
$ rustup run nightly cargo bench
It would be nice to use something like bench-cmp to compare before and after, but for some reason, there is no output. Should investigate why.
Not yet implemented
Given that Rust has no support for Higher Kinded Types, I'm not sure if these
are even possible to implement. In addition, Rustaceans are used to calling iter()
on collections to get a lazy view, manipulating their elements with map
or and_then
, and then doing a collect()
at the end to keep things
efficient. The usefulness of these following structures maybe limited in that context.
Functor
Monad
Apply
Applicative
Contributing
Yes please !
The following are considered important, in keeping with the spirit of Rust and functional programming:
- Safety (type and memory)
- Efficiency
- Correctness
Inspirations
Scalaz, Shapeless, Cats, Haskell, the usual suspects ;)