On Mon, Jan 2, 2012 at 8:29 PM, Jeronimo Pellegrini <j_p@aleph0.info> wrote:
>
> The report mentions that
>
>  "In a library declaration, it is an error to import
>  the same identifier more than once with different bindings,
>  or to redefine or mutate an imported binding with define,
>  define-syntax or set!."
>
> So a library cannot, for example, export a variable that
> is supposed to be mutated by the user. But can it export
> a getter and a setter?

You can, but the exact semantics are undefined.  R7RS
small ignores phases altogether because for the most
part it's irrelevant when all macros are referentially
transparent, as syntax-rules macros are.  However, when
visiting a library itself causes side-effects, or different
instantiations of a library may define separate copies of
the same top-level variables, then phasing still matters.

R6RS defines precise phasing semantics in section 7.2,
but then proceeds to say that the semantics are unspecified.

  http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html#node_sec_7.2

Specifically, the last sentence says:

  Thus, a library whose meaning depends on whether the
  instances of a library are distinguished or shared across
  phases or library expansions may be unportable.

The reason is that while the tower of phases described is
aesthetically appealing and prevents programmers from
making certain types of phasing mistakes, it's an unpopular
implementation strategy and can be very expensive in
time and space for large inheritance hierarchies.  There
are also cases where there truly are mutable variables that
you want to be unique throughout a program, such as large
caches.

Since R7RS large intends to provide low-level macros it
will probably need to specify an import-for extension to the
library syntax, and say something about phases.  I'd recommend
it go beyond the R6RS semantics, and consider providing some
way to guarantee a binding is not duplicated in simple cases.
One approach would be to require that all libraries in the level 0
import hierarchy are instantiated only once (within that hierarchy).
Another approach would be to allow a "singleton" type library
annotation which states the library is only instantiated once
(which would allow for easily incompatible code involving macro
expansion time).

In the meantime, for R7RS small (and R6RS), keep in mind
that while mutating top-level library bindings or the data-structures
they refer to is unportable, most of the time if constrained to
simple run-time libraries (level 0), it will do what you expect.

--
Alex

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