From: Julian Graham <joolean@gmail.com>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: r6rs libraries
Date: Wed, 28 Jan 2009 12:26:45 -0500 [thread overview]
Message-ID: <2bc5f8210901280926o399f4505nc1d30c6017886a81@mail.gmail.com> (raw)
In-Reply-To: <m3ocxt10ol.fsf@pobox.com>
Hi Andy,
Thanks so much for helping me parse!
> 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.
Oooh -- if you do find it, let me know. That sounds interesting.
> I could not find the quote that you referred to here -- I think what I
> can tell (from 7.2):
(Yes, that was the bit I was referring to. Sorry about that.)
One thing that occurred to me, though, while I was brooding on this,
is the case in which you've got two bindings that share the same name
that are both imported (from different libraries) into library foo --
one's a syntax transformer used to expand library foo, the other's a
function used by library foo at runtime. R6RS seems designed to
address cases like this so that they work out, you know, hygienically.
And I think Guile's module system can handle this as well, though it
may require some slightly weird designs.
E.g., one thing I was thinking of trying was mapping an R6RS library
onto *two* generated Guile modules: One to represent the expansion
environment, and one to represent the environment of the expanded
library in which the library bindings and top-level expressions are
actually evaluated (I guess this is the same as the runtime
environment?). The first module's imports would include bindings
required for expansion; the second's would include the stuff for
runtime.
> 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?
Strongly agree.
Regards,
Julian
next prev parent reply other threads:[~2009-01-28 17:26 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
2009-01-27 20:09 ` Ludovic Courtès
2009-01-28 17:26 ` Julian Graham [this message]
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=2bc5f8210901280926o399f4505nc1d30c6017886a81@mail.gmail.com \
--to=joolean@gmail.com \
--cc=guile-devel@gnu.org \
--cc=wingo@pobox.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).