From: Rob Browning <rlb@defaultvalue.org>
Subject: Re: Future of ice-9/slib.scm.
Date: Sat, 19 Nov 2005 13:43:03 -0800 [thread overview]
Message-ID: <87acg0gvq0.fsf@trouble.defaultvalue.org> (raw)
In-Reply-To: <87veyoik74.fsf@trouble.defaultvalue.org> (Rob Browning's message of "Sat, 19 Nov 2005 10:09:03 -0800")
Rob Browning <rlb@defaultvalue.org> writes:
> My current intention is to sit down when I have time and see if I can
> figure out what changes, if any, we would have to make to the current
> guile.init in order to be able to rely on it, rather than the code in
> slib.scm.
So here's round one.
Quite a few items in slib.scm are already in guile.init, and so we can
just drop those. There are some other bits that I wanted to present
for discussion and double-checking.
As background, at the point when any of this code executes, the
current module is (ice-9 slib).
A minor difference regards output-port-width. The version in slib.scm
returns 80 where the version in guile.init returns 79.
A more significant question regards evaluation. In slib.scm we have:
(define-public slib:eval
(lambda (x) (eval x slib-module)))
(define defmacro:eval
(lambda (x) (eval x (interaction-environment))))
where guile.init has:
;;; SLIB:EVAL is single argument eval using the top-level (user) environment.
(define slib:eval
(if (string<? (scheme-implementation-version) "1.5")
eval
(let ((ie (interaction-environment)))
(lambda (expression)
(eval expression ie)))))
(define defmacro:eval slib:eval)
The major difference here is that SLIB's slib:eval evaluates in
interaction-environment rather than the slib module. It looks like
the current defmacro:eval behaviors are the same.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2005-11-19 21:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-16 5:23 Future of ice-9/slib.scm Rob Browning
2005-11-16 7:50 ` klaus schilling
2005-11-16 10:14 ` Andy Wingo
2005-11-17 19:16 ` Rob Browning
2005-11-16 15:38 ` Greg Troxel
2005-11-18 3:56 ` Rob Browning
2005-11-18 11:46 ` Greg Troxel
2005-11-19 14:22 ` Marius Vollmer
2005-11-19 18:09 ` Rob Browning
2005-11-19 21:43 ` Rob Browning [this message]
2005-11-19 23:38 ` Marius Vollmer
2005-11-20 1:06 ` Rob Browning
2005-11-20 20:01 ` Rob Browning
2005-11-20 21:09 ` Kevin Ryde
2005-11-20 23:27 ` Rob Browning
2005-12-09 20:42 ` Rob Browning
2005-12-11 0:59 ` Kevin Ryde
2005-12-11 6:08 ` Rob Browning
2005-12-12 19:39 ` Greg Troxel
2005-12-13 1:33 ` Rob Browning
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=87acg0gvq0.fsf@trouble.defaultvalue.org \
--to=rlb@defaultvalue.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).