base64-bytestring
Our great sponsors
base64-bytestring | semigroupoids | |
---|---|---|
1 | 2 | |
45 | 75 | |
- | - | |
4.7 | 3.2 | |
7 months ago | 3 days ago | |
Haskell | Haskell | |
BSD 3-clause "New" or "Revised" License | BSD 2-clause "Simplified" 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.
base64-bytestring
-
Yatima: A programming language for the decentralized web
Sure, if you consider Haskell's runtime (I know that technically GHC /= Haskell, but in practice it's the only Haskell that matters, except maybe something like Asterius) all the primitives are backed by C libraries: https://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GH...
Likewise with conventions around pointers, arrays, etc. to the point where if you want to do anything really low-level or performance sensitive in Haskell, you're essentially punching a hole into C. As a random example, within the fast base64bytestring library, you find lots of use of `malloc`, `ForeignPtr` etc.: https://github.com/haskell/base64-bytestring/blob/master/Dat... And of course because this is C there aren't really many safety guarantees here.
The plan with Yatima with its primitives, and eventually when we write an FFI is to integrate with Rust in the same way that Haskell uses C. My hope is that with Yatima's affine types we might even be able to FFI to and from safe Rust (since the borrow checker uses affine types), but this is a little bit of a research project to see how much that works. Even to unsafe Rust though, we have better safety guarantees than C, since unsafe Rust's UB is still more restricted than C's is.
semigroupoids
-
I came across the "Fantasy Land Specification", it somewhat conflicts with my own simplistic understanding of monads and functors. Is this specification valid, and should I honor it?
I think of this as the "semigroupoid" factoring. Here's the canonical Haskell library, with an explanation of why the extra classes exist: https://hackage.haskell.org/package/semigroupoids. In this library, fantasyland's Chain is called Bind.
-
Folding Nonempty Structures In Haskell
obligatory shoutout to semigroupoids 🤘
What are some alternatives?
msgpack - Haskell implementation of MessagePack / msgpack.org[Haskell]
kan-extensions - Kan extensions, Kan lifts, the Yoneda lemma, and (co)monads generated by a functor
asn1-encoding - ASN1 Raw/BER/DER/CER reader/writer in haskell
proto-lens - API for protocol buffers using modern Haskell language and library patterns.
data-lens - Haskell 98 Lenses
cassava-conduit - Conduit interface for cassava [Haskell]
comonad - Haskell 98 comonads
bimap - Bidirectional mapping between two key types
monoid-extras - Miscellaneous constructions on monoids
filesystem-trees - Traverse and manipulate directories as lazy rose trees
order-statistic-tree - Order statistic tree in Haskell