I think that most of the users coming to Finch would want to see the high-level interfaces first. We should make it clear that there's a whole tensor compiler underneath, but ultimately I think all users need to see is the high-level stuff first. We can frame the rest of Finch as a specialized "Finch IR".
I briefly considered splitting out the high-level stuff into it's own package, but I think it's too much work to figure out where all of the various functionalities (fileio, fsparse stuff, etc.) should live, and it's rare to want one without benefitting from the convenience of the other. Also, duplicating the test suite and code caching functionalities would be too much code duplication, and I don't want to make a separate utility package just yet.
I'll leave code splitting open as a future possibility, but we can separate the docs first.
willow-ahrens
commented
3 hours ago
I think that most of the users coming to Finch would want to see the high-level interfaces first. We should make it clear that there's a whole tensor compiler underneath, but ultimately I think all users need to see is the high-level stuff first. We can frame the rest of Finch as a specialized "Finch IR".
I briefly considered splitting out the high-level stuff into it's own package, but I think it's too much work to figure out where all of the various functionalities (fileio, fsparse stuff, etc.) should live, and it's rare to want one without benefitting from the convenience of the other. Also, duplicating the test suite and code caching functionalities would be too much code duplication, and I don't want to make a separate utility package just yet.
I'll leave code splitting open as a future possibility, but we can separate the docs first.