Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

2009-09-02 Thread Ken Raeburn
On Sep 2, 2009, at 04:08, Ludovic Courtès wrote: In the Guile case, I'm a tiny bit concerned about some of the pointer/ int games played (e.g., I'm pretty sure C99 does not guarantee that you can convert an arbitrary uintptr_t value to pointer and back and be guaranteed of getting the original

Re: (set! (@@ MOD NAME) EXP) considered harmful

2009-09-02 Thread Mark H Weaver
Sorry, I meant to say that (set! (@ MOD NAME) EXP) should be considered harmful as well. Mark On Wed, Sep 02, 2009 at 12:17:11PM -0400, Mark H Weaver wrote: > The ability to set! arbitrary module top-level variables from outside > the module, using the syntax (set! (@@ MOD NAME) EXP), destr

(set! (@@ MOD NAME) EXP) considered harmful

2009-09-02 Thread Mark H Weaver
The ability to set! arbitrary module top-level variables from outside the module, using the syntax (set! (@@ MOD NAME) EXP), destroys our ability to several important optimizations. As long as such ability exists, we must pessimistically assume that any module top-level variable might change at an

Re: [PATCH] %nil-handling optimization and fixes v1

2009-09-02 Thread Mark H Weaver
Neil Jerram wrote: > FWIW, dropping "lisp_" looks OK, but I'm not sure about dropping > "and_". "scm_is_false_not_nil" feels notably harder to understand > than "scm_is_false_and_not_nil". Yes, I see your point, and I agree. Mark

Re: truth of %nil

2009-09-02 Thread Mark H Weaver
Neil Jerram wrote: > > One more thing: scheme code can reasonably expect to "write" a list of > > simple values and then "read" it back in. But now, lists might be > > terminated by %nil instead of '(). Therefore, I think "read" needs to > > be able to read SCM_LISP_NIL in whatever form we "write

Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

2009-09-02 Thread Ludovic Courtès
Hi! Ken Raeburn writes: > In the Guile case, I'm a tiny bit concerned about some of the pointer/ > int games played (e.g., I'm pretty sure C99 does not guarantee that > you can convert an arbitrary uintptr_t value to pointer and back and > be guaranteed of getting the original value... but I don

Re: Unicode ports patch

2009-09-02 Thread Ludovic Courtès
Hi! Mike Gran writes: >> > It would be nicer if string ports were actually bytevector ports, and that >> > they were locale-independent?  Or that scm_get_output_bytevector returned >> > a >> > locale-independent (ergo 8-bit or 32-bit) vector? >> >> The latter. > > The test suite requires an