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: "Ludovic Courtès" <ludo@gnu.org>, guile-devel@gnu.org
Subject: Re: r6rs libraries, round two
Date: Mon, 29 Jun 2009 14:01:19 -0400	[thread overview]
Message-ID: <2bc5f8210906291101k728e0e81le78378b48aa495fd@mail.gmail.com> (raw)
In-Reply-To: <m3skhkyr3l.fsf@pobox.com>

Hi Andy,

> Your solution of doing whole-program analysis is very much in the spirit
> of R6RS, but it is not in the spirit of Lisp, in my opinion at least.

Well, to be fair, it's not whole-program analysis -- as Neil pointed
out, we only need to analyze the library and program "headers."  But,
sure, point taken.


> I actually think that doing a whole-program analysis is actively harmful
> to the future of Scheme. That's a bit hyperbolic, but it is my opinion.
> To me, Lisp is about living, adaptable systems -- not about static
> programs. There's no need to let mistakes on the part of the R6RS
> editors take us farther down the static path.
>
> Fortunately, we can comply to the letter of the standard, and not the
> spirit.
>
> Back to your question though, what did you think about my symlink
> solution[1]?

It's a fine way of handling version-less dependencies, but I don't see
how it solves the determinism issue.  Let's say my program (or code
stream or script or whatever you want to call it) uses libraries from
two different authors.  Author A trusts his dependencies to remain
stable and doesn't use version specifiers in his library references;
author B does use them.

If my code imports author A's library before author B's, and there's a
version clash in their dependencies, what's the take-away for me, the
user?  Does this mean my code is not well-formed until I reverse the
order of my imports?  Should I not depend on author A's code at all?
On author B's code?  Do I have to patch my libraries before importing
them?

I'm approaching this project in my capacity as a developer with a fair
number of dependencies (that I want manage as abstractly as I can)
wanting to distribute and test my code on as many platforms as
possible.  From my point of view, the fact that there hasn't been a
unified "module" format for Scheme is pretty frustrating.  To the
extent that R6RS has some traction among Scheme implementations, its
library spec is attractive -- although, I recognize, for political
more than technical reasons.

At the same time, after months of poring over the minutiae of R6RS,
I've come around to the position that it's got some serious defects.

Is there some middle ground possible?  The intentions of the R6RS
editors with regard to libraries and programs being "static" seems
pretty clear.  And for certain use cases, that may be appropriate.
But that doesn't mean that Guile modules need to behave that way.
Would people be amenable to having two different ways of working with
libraries / programs?  I.e., the "mode" that Guile would be in when
you ran an R6RS program would be different than when you were in the
REPL.  Maybe it'd even be a different language in the VM.  And we
could establish some prescribed mechanisms by which non-R6RS Guile
code could use R6RS libraries (with caveats attached), and just not
support the converse.

I don't know -- this problem seems to get thornier the more we discuss
it, but I still think it's worth solving.  Sorry if I've missed the
point on any of your comments.


Regards,
Julian




  reply	other threads:[~2009-06-29 18:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-29 20:31 r6rs libraries, round two Julian Graham
2009-05-30 23:22 ` Neil Jerram
2009-05-30 23:34   ` Julian Graham
2009-06-01 19:55   ` Andy Wingo
2009-06-01 22:34     ` Ludovic Courtès
2009-06-03 18:36       ` Neil Jerram
2009-06-04  6:50         ` Ludovic Courtès
2009-06-28  0:20       ` Julian Graham
2009-06-28 13:28         ` Neil Jerram
2009-06-28 18:23           ` Julian Graham
2009-06-28 21:40         ` Andy Wingo
2009-06-29 18:01           ` Julian Graham [this message]
2009-06-29 18:26             ` Ludovic Courtès
2009-07-06 18:02           ` Julian Graham

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=2bc5f8210906291101k728e0e81le78378b48aa495fd@mail.gmail.com \
    --to=joolean@gmail.com \
    --cc=guile-devel@gnu.org \
    --cc=ludo@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).