Get string coercions right

[jwiegley]

According to @shlevy , there are 2 axes of string coercion:

• coerceToString + coerceMore: Do I coerce integers? Do I recurse into lists?
• addToStore: If coercing a path, do I just convert it into a string, or add it to the store?

There are several string coercion contexts:

• toString: coerceMore = true, addToStore = false
• ${: coerceMore = false, addToStore = true
• derivation argument: coerceMore = true, addToStore = true
• implicit coercion: coerceMore = false, addToStore = false
• forceString: it simply must be a string and nothing else

Shea will double check this.

According to these criteria, we are getting this wrong on toString right now.

[mightybyte]

I believe this is done, but leaving the issue open so someone else can confirm.

[Anton-Latukha]

Soon I would send/merge a patch. I went into Coersion and started refactoring, now, instead of only 1 function coerceToString with 4 arguments - there are coerceAnyToNixString, coerceStringlikeToNixString & coercePathToNixString :: CopyToStoreMode -> Path -> m NixString.

The coercion for Sets (the main Nix structure for derivations) is moved from previous Stringy mode (*sic), into coerceAnyToNixString. Internal recursion goes on only in traversable structures in coerceAnyToNixString, and it is at least (should be) tail-recursive. But this is a great place to transform through recursion schemes.

All that simplified code, reading & understanding it quite a bit.

As one function was replaced with a set of special ones - source code got updated & became more intuitively descriptive, now it is seen where anything is coerced, where the thing is really string, where the Path is made & reifies into the store.

This code is now easy to extend further.