From: Keith Wright <kwright@keithdiane.us>
To: ttn@gnuvola.org
Cc: guile-user@gnu.org
Subject: Re: rfc (define-module ... #:use-modules ...)
Date: Sun, 7 Oct 2007 00:05:13 -0400 [thread overview]
Message-ID: <200710070405.l9745DBe003737@fcs13.keithdiane.us> (raw)
In-Reply-To: <877im0lg1x.fsf@ambire.localdomain> (message from Thien-Thi Nguyen on Sat, 06 Oct 2007 11:59:22 +0200)
> From: Thien-Thi Nguyen <ttn@gnuvola.org>
>
> for me, it means everyone interested should say what they would
> (or would not) do and then if there is concensus (after some
> refinement), i follow. if there is no concensus, i muddle
> through the best i can (as always). from the sound of the
> responses thus far, this is the most likely outcome.
Consensus - same sense or feeling (<-Latin sentire)
Concensus - if that were a word,
it might mean same head-count
Anyway carry on. Or muddle on. My opinion means
little with no code to back it up, and I have none.
> If you want to harmonize, maybe both branches could
> think about implementing R6RS library forms.
>
> the library body is specified to be included in the `library'
> form. OTOH, `define-module' is a peer top-level form to the
> library body. how would you reconcile these approaches?
I don't want to rudely inject my opinion, but if
you keep asking quesions it would be rude not to
answer.
I am not totally sure I understand the question.
Are you worried about the systactic difference
between
(define-module blah blah)
(def xx)
(xx xx xx)
<end-of-file>
versus
(library blah blah
(def xx)
(xx xx xx) )
?
The later (with parentheses on both sides)
seems more lispy to me, but it seems like a
pretty trivial change of syntax. It would
be more interesting to learn about the deep
magick hidden in the blah blah.
I would leave modules alone for backward
compatibility, and try to add something
with the (library ...) syntax but with an
underlying semantics as much as possible
like the current module system.
Then I would write a paper or manifesto
on the exact reasons why libraries and
modules are too different to be inter-
changeable.
At least, that is how I would reconcile the
two approaches if I were even to begin
reconciliation. In the real world, I
will type my pipe dream to the mailling
list and then go to bed and not care about
it in the morning.
-- Keith
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
next prev parent reply other threads:[~2007-10-07 4:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-04 14:10 rfc (define-module ... #:use-modules ...) Thien-Thi Nguyen
2007-10-04 15:29 ` Ludovic Courtès
2007-10-04 18:40 ` Thien-Thi Nguyen
2007-10-04 15:30 ` Mike Gran
2007-10-04 16:29 ` Ludovic Courtès
2007-10-04 19:12 ` Thien-Thi Nguyen
2007-10-04 17:14 ` Clinton Ebadi
2007-10-04 19:09 ` Thien-Thi Nguyen
2007-10-04 19:21 ` Klaus Schilling
2007-10-04 19:18 ` Klaus Schilling
2007-10-05 23:47 ` Keith Wright
2007-10-06 9:59 ` Thien-Thi Nguyen
2007-10-07 4:05 ` Keith Wright [this message]
2007-10-07 9:37 ` Thien-Thi Nguyen
2007-10-07 14:23 ` Ludovic Courtès
2007-10-07 15:15 ` Thien-Thi Nguyen
2007-10-07 17:11 ` 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=200710070405.l9745DBe003737@fcs13.keithdiane.us \
--to=kwright@keithdiane.us \
--cc=guile-user@gnu.org \
--cc=ttn@gnuvola.org \
/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).