From: Andy Wingo <wingo@pobox.com>
To: Julian Graham <joolean@gmail.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: r6rs libraries
Date: Tue, 27 Jan 2009 11:51:54 +0100 [thread overview]
Message-ID: <m3ocxt10ol.fsf@pobox.com> (raw)
In-Reply-To: <2bc5f8210901251627t5d59f9fg5bc5dcceaf2a0b9f@mail.gmail.com> (Julian Graham's message of "Sun, 25 Jan 2009 19:27:46 -0500")
Hi Julian,
On Mon 26 Jan 2009 01:27, Julian Graham <joolean@gmail.com> writes:
> Maybe some more advanced Schemers than I can shed some light on the
> following:
Well, that's not me, but I'll join you in fumbling for a solution :-)
> The levels system is simply a numerical way of encapsulating this
> information, but the proper order of evaluation can also be inferred
> by inspecting the import- and export-specs of the libraries being
> loaded
I think you're right, yes. I think that the approach that you describe
has been called "Implicit phasing" by Ghuloum and Dybvig. They have a
paper about it, "Implicit phasing in R6RS libraries" -- but I haven't
been able to find it freely on the web. ACM fail.
> * R6RS says that a library's imports need to be visited/instantiated
> at the time the bindings they export are "referenced." Why? As
> above, why can't they be visited/instantiated at the time the imports
> for the importing library are processed?
I could not find the quote that you referred to here -- I think what I
can tell (from 7.2):
If any of a library’s definitions are referenced at phase 0 in the
expanded form of a program, then an instance of the referenced
library is created for phase 0 before the program’s definitions and
expressions are evaluated. This rule applies transitively: if the
expanded form of one library references at phase 0 an identifier
from another library, then before the referencing library is
instantiated at phase n, the referenced library must be instantiated
at phase n. When an identifier is referenced at any phase n greater
than 0, in contrast, then the defining library is instantiated at
phase n at some unspecified time before the reference is evaluated.
Similarly, when a macro keyword is referenced at phase n during the
expansion of a library, then the defining library is visited at
phase n at some unspecified time before the reference is evaluated.
So what this says to me is that:
(1) At phase 0, libraries that you need to run a /program/ are
instantiated before the program is run.
(2) At phase n > 0, we do not specify when libraries are imported.
> Is there any noticeable difference to the user?
Dunno, to me it sounds like a concession, that side effects from loading
libraries occur before side effects from running a program; but that for
meta-levels things are left unspecified.
> Or do you guys read R6RS 7.2 to mean that the side-effects of
> top-level expressions absolutely need to happen at a time determined
> by the import level?
No.
So, for some of your other questions here's section 7.5 of the
rationale:
7.5. Instantiation and initialization
Opinions vary on how libraries should be instantiated and
initialized during the expansion and execution of library bodies,
whether library instances should be distinguished across phases, and
whether levels should be declared so that they constrain identifier
uses to particular phases.
As I read this, it means that at least PLT wanted the separate
instantiation model, and Chez wanted single-instantiation, implicit
phasing.
This report therefore leaves considerable latitude to
implementations, while attempting to provide enough guarantees to
make portable libraries feasible.
So from 7.2 of R6RS itself:
An implementation may distinguish instances/visits of a library for
different phases or to use an instance/visit at any phase as an
instance/visit at any other phase.
Which is to say, "we allow single instantiation" -- as Guile modules
are.
An implementation may further expand each library form with distinct
visits of libraries in any phase and/or instances of libraries in
phases above 0.
Which is to say, "we also allow the PLT model, explicitly."
An implementation may create instances/visits of more libraries at
more phases than required to satisfy references.
This is an odd one. I suppose what it means is that if you need a macro
from library A to expand library B, but you don't need library A at
runtime, the spec allows library A to be /instantiated/ at runtime.
When an identifier appears as an expression in a phase that is
inconsistent with the identifier’s level, then an implementation
may raise an exception either at expand time or run time, or it may
allow the reference.
So, furthermore, it seems that not only may library A be instantiated at
runtime, /it may be in library B's "import list" as well/. This is what
happens with Guile's current module semantics.
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.
Indeed, indeed.
> I understand that the authors of the reference implementation
> re-created a lot of machinery out of whole cloth since they were
> avoiding assumptions about features of their target Scheme platforms,
> but, man, both van Tonder and Dybvig-Ghuloum look like overkill for
> Guile. Am I missing a major piece of understanding here?
I don't think you're missing anything big, no. I hadn't fully poked into
these implementations -- if it is easier just to build something on top
of Guile's modules than to retrofit guile's modules into one of their
implementations, then that's all the better, right?
Cheers,
Andy
--
http://wingolog.org/
next prev parent reply other threads:[~2009-01-27 10:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2bc5f8210812271705h3f57cb29w5bb83cb02abe971@mail.gmail.com>
[not found] ` <m3k59ktv2g.fsf@pobox.com>
[not found] ` <2bc5f8210812282238p1f91f352id7eca5280dc9ff6a@mail.gmail.com>
[not found] ` <2bc5f8210901012010g2ebb6effx5c966d0e26fe382b@mail.gmail.com>
[not found] ` <8763kt48zi.fsf@gnu.org>
[not found] ` <m3iqosrcn7.fsf@pobox.com>
[not found] ` <2bc5f8210901111521i1a5ec85em65ee20135cc55ebb@mail.gmail.com>
[not found] ` <877i4z89jy.fsf@gnu.org>
2009-01-26 0:27 ` r6rs libraries Julian Graham
2009-01-27 10:51 ` Andy Wingo [this message]
2009-01-27 20:09 ` Ludovic Courtès
2009-01-28 17:26 ` Julian Graham
2009-02-16 18:35 ` Julian Graham
2009-02-16 20:58 ` Andreas Rottmann
2009-02-18 6:08 ` Julian Graham
2009-02-18 14:27 ` Andreas Rottmann
2009-02-17 21:43 ` Ludovic Courtès
2009-02-18 5:37 ` Julian Graham
2009-02-18 8:53 ` Ludovic Courtès
2009-02-18 21:16 ` Andy Wingo
2009-03-04 5:23 ` Julian Graham
2009-03-04 8:39 ` Ludovic Courtès
2009-03-04 22:51 ` Julian Graham
2009-03-06 23:39 ` Ludovic Courtès
2009-03-07 0:43 ` Julian Graham
2009-03-22 22:30 ` Julian Graham
2007-02-06 15:55 R6RS Libraries Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3ocxt10ol.fsf@pobox.com \
--to=wingo@pobox.com \
--cc=guile-devel@gnu.org \
--cc=joolean@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).