On Sat, 2013-01-05 at 01:31 -0500, John Cowan wrote: > Sam Tobin-Hochstadt scripsit: > > > This is not correct for R6RS (even though Aziz's dissertation suggests > > otherwise). Explicit phasing in R6RS, combined with expansion time > > side-effects, means that modules with no exports can be imported at > > some phase N, this choice of phase (a) cannot be deduced from the > > program and (b) affects the semantics of the program under > > consideration. > > It sounds like this code is not portable to arbitrary R6RS > implementations, specifically those which ignore phasing information in > the library specifications, as any R6RS implementation is free to do. > This is not in itself a Bad Thing, but but it seems to undermine its > value as evidence that R6RS code can be both compliant and depend on > explicit phasing. So, Sam's example is not actually strictly non-portable in the sense that you make. R6RS explicitly does mention that expecting each library instantiation of each phase to be either unique or identical is not portable. [A] library whose meaning depends on whether the instances of a library are distinguished or shared across phases or library expansions may be unportable. -- R6RS, Section 7.2, Final sentence However, Sam's example is broader than that, encompassing library's that have no shared state, but some other sort of side-effects that are the *only* thing you care about in the importing library. Here we again enter an unspecified part of the R6RS standard, but only by omission, rather than explicit mandate. That is, the R6RS mandates that a library be instantiated (evaluated/loaded) if an identifier exported by that library is referenced by the importing library, but is says nothing about what happens to a library that is imported, but that has no explicit references to it or exports from it. This is again an unspecified part of the standard. Arguably, the issue of explicit versus implicit phasing is not important here. Rather, it is a question of whether an imported library is guaranteed to be instantiated or not, and when that will happen. Nothing about explicit or implicit phasing makes any guarantees about this in their nature. In practice however, all explicit phasing systems of which I am aware take the approach of a separate library instantiation per phase, with a guaranteed instantiation of at least once when the library is imported. I believe they also guarantee that no more than one instantiation per phase occurs, though I do not know this for sure. Implicit phasing systems, on the other hand, tend to always share state among phases and to guarantee zero or one loadings, but no more, across all phases. These behaviors can be reasonably decoupled from the implicit/explicit debate, but in practice, few people tend to do that. I am aware of no practical implementation of Scheme that does so. I would actually like to see this, but I suspect that it is too much work for either camp to attempt it. Implicit and explicit phasing are both allowed by the R6RS standard, as the standard does not mandate that an exception be signalled in the case of an identifier reference to a library imported into a different phase. Both systems in practice allow you to control when side-effects occur, either explicitly or implicitly. In the systems that I am familiar with implicit phasing systems also allow you to have controllable state at different phases using identifiers. In the end, it is the methods and patterns that differ, at least on these issues. Regardless, relying on implicit or explicit phasing at all is non-portable, and the only portable libraries are those that would work on either system equally well. -- Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us לֵ֤ב חֲכָמִים֙ בְּבֵ֣ית אֵ֔בֶל וְלֵ֥ב כְּסִילִ֖ים בְּבֵ֥ית שִׂמְחָֽה׃ _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
