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
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
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
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
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
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
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