In Derivation noted a number of Map.fromList . HashMap.toList. This shows that there should be a newtype boundary between those abstractions or none at all.
> hrg 'Data.Map'
./tests/NixLanguageTests.hs
9:import qualified Data.Map as Map
./src/Nix/Type/Infer.hs
43:import qualified Data.Map as Map
./src/Nix/Type/Env.hs
27:import qualified Data.Map as Map
./src/Nix/Effects/Derivation.hs
19:import qualified Data.Map.Strict as Map
./main/Main.hs
17:import qualified Data.Map as Map
As seen - the additional point is they are mostly lazy maps.
Most of the code overall uses HashMap, the only uses of Map are in Derivation, and in the inference infrastructure. The migration in Derivation seems beneficial. In the inference, Map.Lazy is currently used in substitutions & typing environments, typing environment probably can get big.
Looking at https://github.com/haskell-perf/dictionaries, HashMap is still preferable in the majority of cases. At least the case in Derivation suggest to stick to HashMap there.
There is the slight issue that HashMap are not sorted. However, Nix specifies that attribute sets should be sorted. It is very important for derivations, because the order influences the store path hash.
In
Derivation
noted a number ofMap.fromList . HashMap.toList
. This shows that there should be anewtype
boundary between those abstractions or none at all.As seen - the additional point is they are mostly lazy maps.
Most of the code overall uses
HashMap
, the only uses ofMap
are inDerivation
, and in the inference infrastructure. The migration inDerivation
seems beneficial. In the inference,Map.Lazy
is currently used in substitutions & typing environments, typing environment probably can get big.Looking at https://github.com/haskell-perf/dictionaries,
HashMap
is still preferable in the majority of cases. At least the case inDerivation
suggest to stick toHashMap
there.