really-small-backpack-example
rust-semverver
really-small-backpack-example | rust-semverver | |
---|---|---|
8 | 8 | |
50 | 641 | |
- | - | |
2.8 | 1.7 | |
9 months ago | 10 months ago | |
Haskell | Rust | |
MIT License | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
really-small-backpack-example
- Haskell is the greatest programming language of all time
-
Implied bounds and perfect derive
Isn’t this what Haskell’s backpack does? https://github.com/danidiaz/really-small-backpack-example
-
Polymorphic unpacking through backpack?
Also worth mention how module identity works in Backapck: two modules instantiated separately but with the same ingredients are "equal" and have compatible types.
-
Using dependent types to write proofs in Haskell
Anyway, an alternative to RULES that I've explored is to put the proofs behind a module signature and compile to versions of the program, one with "real" proofs and another with unsafeCoerced ones. This avoids the danger of the RULEs silently ceasing to apply because of name changes (don't know how common is that danger in practice though).
-
Video Tutorial: "Using proofs to make functions faster over length-indexed vectors" (Richard Eisenberg)
Here's an example of how to use Backpack (instead of rewrite rules) to alternate between "normal" proofs and the ones which use usafeCoerce.
-
Proposal for parametric modules like Coq's?
Perhaps Backpack could enable something similar to that?
-
Anyone actively using dhall-to-cabal or hpack-dhall?
While being nowhere near programmability, Cabal's common stanzas can be very useful to reduce duplication. An example.
- Abstracting monad stacks with Backpack
rust-semverver
-
A byte string library for Rust
1) No. I think semver is just fine for its intended purpose. I mean, I'm sure its spec could be improved in various ways, but its fundamental idea seems fine to me. I think it's just important to remember that semver is a means to an end, and not an end itself. It is a tool of communication most useful in a decentralized context.
2) No.
3) See: https://github.com/rust-lang/rust-semverver --- But also, this is only ever going to be a "best effort" sort of thing. Semver isn't just about method additions or deletions, but also behavior.
-
Toward fearless `cargo update`
How does this compare to cargo-semverver?
-
Are crate versions numbers all low because Rust just works?
Found this: https://github.com/rust-lang/rust-semverver but it doesn't seem to act on git log/diffs... just FYI.
-
Implied bounds and perfect derive
Enter rust-semverver!
-
my company refuses to use rust because it changes to much
Rust type system on the other hand does not allow this. Traits are monotonic logic: adding trait-impls / most qualifiers does't influence already existing and compiling code (note: for code that doesn't rely on disambiguation to compile). There's rules that clarify this disambiguations and breaking/non-breaking changes according to the type system. There's SemVerVer to automatically verify those guidelines.
-
Would you want crates.io/cargo publish to enforce strictly correct SemVer conventions?
In my case it wasn't so bad and an easy fix was fast to write, but it got me thinking of how much of a problem this is for the wider ecosystem. Some searching showed me, that of course there is a tool rust-semverver to do exactly that. Sadly it errors on my system (or maybe im just using it wrong). Would've been interesting to see how often this actually happens on crates.io and how much of a problem this really is.
-
Semantic Versioning Will Not Save You
There's been an attempt at this for the Rust ecosystem: https://stackoverflow.com/questions/41185023/what-exactly-is...
There's also a library that attempts to automatically check sermver adherence of a crate: https://github.com/rust-lang/rust-semverver
And there has been quite a bit of effort into preventing semver requirements from fracturing the ecosystem. This revolves around the compiler working with multiple major versions of a single library: https://github.com/dtolnay/semver-trick
-
cargo-incversion, a command line utility to update Cargo.toml version
Turns out it already exists: https://github.com/rust-lang/rust-semverver
What are some alternatives?
macaroni.nix
wg - Coordination repository of the embedded devices Working Group
agda2hs - Compiling Agda code to readable Haskell
cargo-semver-checks-action - A GitHub Action for running cargo-semver-checks
sdl-gpu-hs
cargo-semver-checks - Scan your Rust crate for semver violations.
Kind2 - A next-gen functional language [Moved to: https://github.com/Kindelia/Kind]
blog - My blog.
dhall-to-cabal - Compile Dhall expressions to Cabal files
imgref-iter - A small crate for iterating over the rows or columns of `imgref` buffers
cargo-crate-api - Superseded by cargo-semver-check
rust-memchr - Optimized string search routines for Rust.