I know a couple of good people annoyed by capslocking.
And moreover, studies show it is harder to grasp the capslocked text.
Capslocking does not work anyway and not worth it, somewhere since we got Web & URLs.
In Nix the `<CYCLE>` only used in one case:
`data/nix/src/libexpr/eval.cc`
```cpp
static void printValue(std::ostream & str, std::set<const Value *> & active, const Value & v)
{
checkInterrupt();
if (active.find(&v) != active.end()) {
str << "<CYCLE>";
return;
}
...
}
```
it never appears otherwise and so is not checked in expression tests, so it is a cosmetic output.
Semantically `<CYCLE>` was remotely right only in `opaque` `src/Nix/Normal.hs`
which tries to detect cycles, and only partially right, even if just due to non-termination detection problem (halting problem).
In other cases, where `<CYCLE>` was used - they are no cycles, which people see: https://github.com/haskell-nix/hnix/issues/663#issue-646681651, and felt confused.
In REPL case - they are simply thunks, or as in XML - just mark expressions.
& they are all expressions after all.
Even most of the infinite nonterminating expressions can be WHNF & studied as expression layer by layer.
And since we can say "expr", that also saves users & devs from communicating what in the lazy FP programming "thunk" slang means.
And currently by itself explains the #777 situation.
Also updated the text. It talked about differences in `NValue` & `NValueNF`, and John made a proper move removing explicit `NValueNF` a while ago, it just tool me some time to become sure I understand it properly and attend to it.
Close: #723, `NValue`, `NValueF` and `NValueNF` were addressed. And Wiki article now full with info and promoted from the draft to article.
Full text and more is now here: https://github.com/haskell-nix/hnix/wiki/Design-of-the-HNix-code-base
https://github.com/haskell-hvr/cryptohash-sha512/pull/5#issuecomment-757068529
Nixpkgs is Ok with all this, it does not import these overrides and have own separate mechanics for the overrides. Since cryptohash-sha512 package is essentially in the unmaintained state - I think it is not worth cleaning the Nixpkgs description because soon (on soon arriving 9.0) - it may be needed again in Nixpgs store, and to that time I hope we make a transition.
This cleaning has a nice side-effect that after release HNix would not need to recompile the cryptohash and Store packages every build.
The Cabal testing is really enough.
Maybe form a network test switch and disable those tests when the variable is
set. So we configure that in the CI and in Nixpkgs.
This nearly finishes the work people did on the NixString & StringContext handling.
HNix had hacky* implementations used for a long time, and now type and implementation systems arrived into great shape that all of the functions become principled.
* Closes: #383#384#385.
* Removed hacky functions/.
* Reduced prefixes from functions.
* NixString now is a Monoid, project code now leverages that.
* Clean-up & restructure in the Nix.String module.
Use of cross-project overlay complicated this and so the package override was
required.
Nixpkgs makes it simple, Core derivation and Nix infra takes care of it.