Thank you for the recent comments. Let me respond to all in one message, as they overlap in scope.
I address a few issues, in sequence, as follows:
- Markdown reader dependencies: I now understand the conflict. In many potential deployment scenarios, for example applications that employ Markdown source, the embedding of snippets in some target language is unlikely to be needed, except perhaps as narrowly allowed for equations. Thus, if this functionality were entirely enclosed in extensions, and if those extensions could be disabled in the build, then in principle it may be possible to realize the benefit of removing the dependencies on the parsers. I understand that it would require restructuring the code.
- Evaluating size of library dependencies: If, as Albert says, only a handful of packages may be eliminated from the build, even in the case that only a few readers or writers were needed, and if the size of these packages is not vastly greater than the size of others, then clearly the material benefit of eliminating certain readers and writers from the build is very limited. However, I make a few notes:
- Is the reason that most dependencies would remain even after removing most of the readers and writers that these dependencies are needed separately by all the readers and writers, or rather that they are needed by the core application? In the latter case, perhaps some of the core functionality not needed in basic uses, again at least in principle, can be separated.
- My earlier question directed mostly at the difficulty of determining confidently the complete set of dependencies to remove, without invoking a formal solution such as graph traversal, compared to the possibility of missing a set in an informal assessment.
- Footprint of Runtime System: No, I was not specifically aware of the size of the Runtime System. I am having difficulty finding a clear indication of how much size it adds to the final executable size, but estimates that seem to recur are in the 10-15 megabyte range. If these estimates are accurate, then it would be impossible to achieve vastly smaller sizes, obviously, but this information alone is not sufficient to conclude the impossibility of achieving significant savings through methods already discussed. Also, I am seeing some hints that a GHC backend for LLVM is available that makes possible much more optimal build results. Unfortunately, I have not found any quantitative assessment of these savings, nor can I find any active project maintaining this interface.