unicode-transforms
Fast Unicode normalization in Haskell (by composewell)
refined
Refinement types with static checking (by nikita-volkov)
unicode-transforms | refined | |
---|---|---|
1 | 1 | |
47 | 180 | |
- | - | |
2.5 | 1.0 | |
7 months ago | 7 days ago | |
Haskell | Haskell | |
BSD 3-clause "New" or "Revised" License | MIT License |
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
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.
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.
unicode-transforms
Posts with mentions or reviews of unicode-transforms.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2021-04-17.
-
[ANN] unicode-collation 0.1
Thanks! Here's a puzzle. Profiling shows that about a third of the time in my code is spent in normalize from unicode-transforms. (Normalization is a required step in the algorithm but can be omitted if you know that the input is already in NFD form.) And when I add a benchmark that omits normalization, I see run time cut by a third. But text-icu's run time in my benchmark doesn't seem to be affected much by whether I set the normalization option. I am not sure how to square that with the benchmarks here that seem to show unicode-transforms outperforming text-icu in normalization. text-icu's documentation says that "an incremental check is performed to see whether the input data is in FCD form. If the data is not in FCD form, incremental NFD normalization is performed." I'm not sure exactly what this means, but it may mean that text-icu avoids normalizing the whole string, but just normalizes enough to do the comparison, and sometimes avoids normalization altogether if it can quickly determine that the string is already normalized. I don't see a way to do this currently with unicode-transforms.
refined
Posts with mentions or reviews of refined.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2022-08-28.
-
Can types replace validation?
In one respect, nothing. You’re right. Even given refinement types as in Haskell or Scala, there is indeed a necessarily-partial function (refineV in Scala) to refine a value to its refinement type.
What are some alternatives?
When comparing unicode-transforms and refined you can also consider the following projects:
with-utf8 - Get your IO right on the first try
elf - Parser for ELF object format.
hashable - A class for types that can be converted to a hash value
semantic-source - Parsing, analyzing, and comparing source code across many languages
jump - Jump start your Haskell development
fmlist - FoldMap lists
code-builder - Packages for defining APIs, running them, generating client code and documentation.
hnix - A Haskell re-implementation of the Nix expression language
critbit - A Haskell implementation of crit-bit trees.
llrbtree - Left-leaning red-black trees
ruby-marshal - Haskell library to parse a subset of Ruby objects serialised with Marshal.dump
unicode-transforms vs with-utf8
refined vs elf
unicode-transforms vs hashable
refined vs semantic-source
unicode-transforms vs jump
refined vs fmlist
unicode-transforms vs code-builder
refined vs hnix
unicode-transforms vs critbit
refined vs llrbtree
unicode-transforms vs hnix
refined vs ruby-marshal