Hi, this is the same question I asked in this PR comment.
In nixlang, how exactly does one go about figuring out all the places in a codebase that reference a given identifier?
In the other languages I know well – Haskell, ML, Rust, Coq, C/C++, and Java – I’m accustomed to simply deleting a declaration and then recompiling to figure out “what uses this declaration?” The compiler will tell me all the places where it is used by producing a compilation error for each of those places.
How do I do this in nixlang?
Despite having a PL background I’ve also realized that I don’t know of the technical name for this language property. My best guess would be “statically resolvable identifiers”.
If nixlang does in fact lack this property I can’t help but suspect that it will someday make maintenance of large-scale codebases extremely difficult. Perhaps that day has already arrived. Clearly a lightweight, dynamically-typed, simple language like nixlang is the right choice for writing package expressions, since these are (ultimately) “bash metaprograms” and bash is about as not-statically-anything as it gets. Given the overlap between the Haskell and nixlang communities, has anybody tried rewriting all of the inter-package stuff (i.e.
nixpkgs/pkgs/stdenv/) in Haskell? Basically using Haskell to orchestrate single-file nix expressions. You’d also get the huge benefit of having real types to document and check interfaces at the inter-file boundaries, where there is the most risk of incorrect assumptions. Of course all the types still get erased when you call from Haskell to nixlang.
I’m sure nobody would be enthusiastic about having nix depend on GHC. OTOH Haskell98 was an incredibly simple language that is easy to write interpreters for.
/me ducks tomatoes thrown by audience