Re: low-hanging SRFI fruit (SRFI-98)
Hi Julian, I concur with Neil's review. One more thing: Julian Graham jool...@gmail.com writes: --- a/NEWS +++ b/NEWS @@ -10,6 +10,7 @@ Changes in 1.9.0: * New modules (see the manual for details) ** `(srfi srfi-18)', multithreading support +** `(srfi srfi-98)', an interface to environment variables ** The `(ice-9 i18n)' module provides internationalization support This change can go in 1.8, so you might want to modify the patch with that line moved under Changes in 1.8.7. :-) Thanks, Ludo'.
Re: r6rs libraries, round two
Hi Neil, I didn't follow why we decided that, but it feels wrong to me. (It seems to me that Guile should be able to handle loading ((foo) v1) and ((foo) v2) simultaneously as easily as it could handle loading ((foo-v1)) and ((foo-v2)) simultaneously.) I guess I should look up the previous thread, please let me know if you have a convenient reference. Here's a link [1]. It's possible I misinterpreted Andy's comment and Ludo's follow-up. Regards, Julian [1] - http://www.mail-archive.com/guile-devel@gnu.org/msg03541.html
Re: [Guile-commits] GNU Guile branch, syncase-in-boot-9, updated. e3c5df539640a36eb1493f581087d54a4714f337
Hi! Andy Wingo wi...@pobox.com writes: commit 34f3d47df9311852ba7eab6f8d1c36535c3774dd Author: Andy Wingo wi...@pobox.com Date: Thu May 28 14:49:33 2009 +0200 [...] * module/ice-9/boot-9.scm: Remove #' read-hash extension, which actually didn't do anything at all. It's been there since 1997, but no Guile code I've ever seen uses it, and it conflicts with #'x = (syntax x) from modern Scheme. I find this point questionable. Do we really need to break this functionality? It would be nicer if we could both keep `read-hash-extend' and the functionality you want. What do you think? (Besides, this commit appears to contain unrelated changes. Also, I prefer it when the test case appears in the same commit as the feature it tests, for easier review.) You may also want to add SRFI-62 support in `NEWS'. Thanks, Ludo'.
Re: [Guile-commits] GNU Guile branch, string_abstraction2, updated. 4d9dfb466ad6fdc9bd42ae7ed5a47dcedec5981a
Hello!
Michael Gran spk...@yahoo.com writes:
commit 4d9dfb466ad6fdc9bd42ae7ed5a47dcedec5981a
Author: Michael Gran spk...@yahoo.com
Date: Tue May 26 08:56:06 2009 -0700
move reader encoding parameters to fluids
* libguile/ports.c: only use accessors functions for
reader encoding parameters
* libguile/strings.c: move scm_i_port_encoding and
scm_i_conversion_strategy into fluids, and make
accessor functions for the new fluid variables.
* libguile/strings.h: remove macro SCM_PORT_ENCODING
* libguile/posix.c: only use accessor functions for
reader encoding parameters
Besides the broken indentation, this log doesn't correspond to a GNU
change log. It should mention all the changes that have been made
(variables added, removed, etc.), not why changes have been made (info
(standards) Change Logs). It really helps when looking for a specific
change.
+const char *
+scm_i_get_port_encoding ()
+{
+ SCM encoding;
+ if (!scm_port_encoding_init)
+return NULL;
+ else if (!scm_is_fluid (SCM_VARIABLE_REF (scm_port_encoding)))
+return NULL;
+ else
+{
+ encoding = scm_fluid_ref (SCM_VARIABLE_REF (scm_port_encoding));
+ if (!scm_is_string (encoding))
+ return NULL;
+ else
+ return scm_i_string_chars (encoding);
+}
+}
My understanding was that you were initially willing to attach encoding
parameter to individual port objects. I know I did mention fluids, but
now that I see it, I think that having encoding info attached to
individual ports would be more logical (sorry if I caused confusion).
Concretely, that would mean adding an `encoding' field to `scm_t_port'.
What do you think?
Just to be clear: I think that this proposal is an arrangement to keep
the current port API intact while still allow it to be Unicode-capable.
In the long run, I think the R6RS port API, where transcoders (not
ports) encapsulate encoding settings, is superior.
Thanks,
Ludo'.
