This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.
Date: Sun, 04 Dec 2005 09:51:14 +0100 From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> Taylor Campbell <campbell@xxxxxxxxxx> writes: > It does, though, make it difficult to extend in the current syntax > in a way that bear wants. Grovelling through the source to > libraries is not an option, but currently the EXPORT syntax is > embedded in the library bodies. But in a way that's trivial to extract. Trivial in the sense that it's placed at the head of a library's body, but to extract that you would have to open the file the library is defined in, read the whole library form, and then quickly scan the head of the form form for the EXPORT form. This is probably not satisfactory for bear's scenario, where there might be thousands or hundreds of thousands of modules, and reading every library's body for every time it is used in another library is simply not an option. The only way I can think of to get around this would be to kludge together a provisional reader to extract the EXPORT form and nothing else, but this is a poor, inflexible workaround for a problem that needn't be necessary in the first place. Yes; I worded this very poorly. What I meant is that you need access to the implementation of modules you import in many cases anyway; the (implied) interface is not enough. Right, but the dependency graph, in general, is dramatically diminished if restricted to macros, and this diminution is probably critical for bear's scenario. Anyway, I suspect that the specified interface is enough for the majority of cases.