Re: [Scheme-reports] library syntax: "visiting" a library left undefined?

["Aaron W. Hsu" <arcfide@x>]

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@x | http://www.sacrideo.us
לֵ֤ב חֲכָמִים֙ בְּבֵ֣ית אֵ֔בֶל וְלֵ֥ב כְּסִילִ֖ים בְּבֵ֥ית שִׂמְחָֽה׃


_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports