Exploiting hashes for Scheme refactoring

["Nathan Benedetto Proença" <nathan@vieiraproenca.com>]

Good morning!

As a new Guix developer, I want to learn about workflows which help me
catch bugs in Scheme development.

Is it a good idea to exploit Guix hashing infrastructure to ensure that
a Scheme refactoring did not change the packages produced?
Has some developer already done that?
Are there another tools and techniques I should be aware of?

As I said in the other email I sent to the mailing list, I am interested
in upgrading the texlive package in tex.scm.
Depending on what you teach me there, a solution could involve changing
more than 100+ places where the origin of packages is specified.

Without proper tooling, this can demand a whole lot of developer time
--- be it my time, or other contributors time.
Would this imply more than 100+ patches submitted and reviewed, and
perhaps in an alternative branch which core developers would have to
maintain?

Then I noticed I could use the hashes for the packages produced as a
test of whether my refactor was satisfactory or not.

For example, let's say I want to change the signature of a function.
I could simply change the function, and Emacs my way into changing the
call sites (Occur-mode, search-replace, or perhaps a some custom
elisp).
While developing, I could simply test if the hash of a single
package was the same as its previous hash.
When I got confident with my change, I could then log to a machine
stronger than my notebook and test if *every* package I touched has the
same hash as the previous one.
This log/procedure could even be sent together with a possible patch, so
to help reviewers trust my patch.

Is this a good use of hashes?
Are there similar techniques already in place?

Thanks in advance,
Nathan