unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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




  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).