I see the advantage of the inline lambdas, but also it seems like it would hamper the ability to test the functions which can often have intricacies that catch you out. I believe one of the principles of Tinygrad is that tests shouldn't be part of the core codebase and shouldn't add to the total linecount.
I think there is an opportunity there to have a tag in comments for tests.
Have a hotkey to generate an id so you could have
# lift x+y out of reduce on lt :testID: color_adjective_noun
((UPat.var("x")+UPat.var("y")).or_casted() < UPat.var("c"), lambda x,y,c: (x < (c.cast(y.dtype)-y)) if no_range(y) and no_range(c) else None),
and it creates a test that exists away from the main codebase. A process that runs tests could scan the code for testID's, intelligently extract the relevant part of the code into the test harness and runs the tests. There would need to be some infrastructure needed to handle placing the code to be tested into the right context but you could have
1. A codebase that contained no active code required simply to facilitate tests,
2. All test tags auto removable for distribution builds
You don't really want or need classical unit tests for compilers. You need a harness that you can feed a program representation into and get a transformed one out, then check the result -- ideally mostly just by running it, or alternatively by comparing the output against a reference.
I think there is an opportunity there to have a tag in comments for tests.
Have a hotkey to generate an id so you could have
and it creates a test that exists away from the main codebase. A process that runs tests could scan the code for testID's, intelligently extract the relevant part of the code into the test harness and runs the tests. There would need to be some infrastructure needed to handle placing the code to be tested into the right context but you could have