Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
Adapton in Rust
A general-purpose Incremental Computation (IC) library for Rust.
The library exposes a small core interface.
Rust macros provide syntactic sugar.
Lazy Evaluation (simple, pure caching).
- Implements Bill Pugh's notion of IC, pure function caching.
- changeable input cells
- bidirectional DCG structure
- dirtying traversal; repair traversal.
- first-class names
- nominal memoization
- generic list and tree traits
- balanced trees from lists ("unfold")
- tree folds (left-to-right, right-to-left, bottom-up)
Data Structures and Algorithms
- tries that represent sets, maps,
- generic fixed-point loop
- graphs, graph exploration algorithms (e.g., search)
- Canonical balanced trees for sequences: Where should data go? Only at leaves (B-Tree style)?
- List/Tree intro forms should take unboxed, references, or boxes?
error: type annotations required: cannot resolve
<_ as structures::ListT<A, _>>::List == _[E0284]
ArtId::Structuralfor cell and thunk to do hashing internally, not externally.
The concept of "object safety" seems to bite me a lot in naive designs:
src/adapton_impl.rs:653:51: 653:111 error: cannot convert to a trait object because trait `adapton_impl::Producer` is not object-safe [E0038] ... src/adapton_impl.rs:653:51: 653:111 note: method `eq` references the `Self` type in its arguments or return type
I sidestepped this problem in
adapton_state.rs twice: by writing
Producer::copy and the
ShapeShifter trait. Both avoid returning a
- Do I need really need
Rc<Box<Fn (_) -> _>>instead of
Rc<Fn (_) -> _>? (Why?)