Re: [Chicken-users] r7rs improper redefinition of imported symbol

[John J Foerch]

John J Foerch  writes:

> Evan Hanson  writes:
>
>> Hi John,
>>
>> You're quite right, this was indeed a bug relating to which bindings are
>> implicitly available within R7RS libraries.
>>
>> This should be fixed in 0.0.5, just released and available shortly. If you
>> could have a go with that version and let me know if you still run into
>> problems, I'd appreciate it.
>>
>> Thanks for the report and the nice little test case.
>>
>> Cheers,
>>
>> Evan
>
> Thank you so much!  I'll try it shortly.
>
> --
> John Foerch

Problem solved, thanks again!

--
John Foerch


___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] r7rs improper redefinition of imported symbol

[John J Foerch]

Evan Hanson  writes:

> Hi John,
>
> You're quite right, this was indeed a bug relating to which bindings are
> implicitly available within R7RS libraries.
>
> This should be fixed in 0.0.5, just released and available shortly. If you
> could have a go with that version and let me know if you still run into
> problems, I'd appreciate it.
>
> Thanks for the report and the nice little test case.
>
> Cheers,
>
> Evan

Thank you so much!  I'll try it shortly.

--
John Foerch


___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] r7rs improper redefinition of imported symbol

[John J Foerch]

John Cowan  writes:

> On Mon, Sep 19, 2016 at 4:51 PM, John J Foerch 
> wrote:
>
> I ran into a little problem when working with the r6rs-bytevectors
> egg,
> which provides an r7rs implementation of (r6rs bytevectors). The
> bytevector-copy! procedure has a different call signature in r6 than
> in
> r7, and I found that as r6rs-bytevectors is currently written, its
> bytevector-copy! always shadows or overrides the bytevector-copy! from
> r7rs.
>
> The assumption is that because you've imported r6rs-bytevectors
> explicitly, the R6RS behavior is what you actually want. This is the only
> place where R6RS and R7RS differ in argument order that is not
> automatically detectable. Larceny provides a combined (r7r6) library that
> imports everything from both standards, except that the R6RS version of
> bytevector-copy! comes in as r6rs:bytevector-copy!.

But notice that in moduleb,

  (import (except (scheme base) bytevector-copy!))

The definition of bytevector-copy! in my moduleb is apparently changing
the value of scheme.base#bytevector-copy! from r7rs, but since that
binding was not imported, I think that this behavior is incorrect.

-- 
John Foerch




___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] r7rs improper redefinition of imported symbol

[Evan Hanson]

Hi John,

You're quite right, this was indeed a bug relating to which bindings are
implicitly available within R7RS libraries.

This should be fixed in 0.0.5, just released and available shortly. If you
could have a go with that version and let me know if you still run into
problems, I'd appreciate it.

Thanks for the report and the nice little test case.

Cheers,

Evan

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] r7rs improper redefinition of imported symbol

[John Cowan]

On Mon, Sep 19, 2016 at 4:51 PM, John J Foerch 
wrote:

I ran into a little problem when working with the r6rs-bytevectors egg,
> which provides an r7rs implementation of (r6rs bytevectors).  The
> bytevector-copy! procedure has a different call signature in r6 than in
> r7, and I found that as r6rs-bytevectors is currently written, its
> bytevector-copy! always shadows or overrides the bytevector-copy! from
> r7rs.
>

The assumption is that because you've imported r6rs-bytevectors explicitly,
the R6RS behavior is what you actually want.  This is the only place where
R6RS and R7RS differ in argument order that is not automatically
detectable.  Larceny provides a combined (r7r6) library that imports
everything from both standards, except that the R6RS version of
bytevector-copy! comes in as r6rs:bytevector-copy!.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Mr. Henry James writes fiction as if it were a painful duty.  --Oscar Wilde
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] r7rs improper redefinition of imported symbol

[John J Foerch]

Hello,

I ran into a little problem when working with the r6rs-bytevectors egg,
which provides an r7rs implementation of (r6rs bytevectors).  The
bytevector-copy! procedure has a different call signature in r6 than in
r7, and I found that as r6rs-bytevectors is currently written, its
bytevector-copy! always shadows or overrides the bytevector-copy! from
r7rs.  In order to see exactly what's going on, I made a simple test
case that does not using the r6rs-bytevectors egg, but instead using a
minimal module that illustrates the problem:

 moduleb.sld

(define-library (moduleb)
  (export bytevector-copy!)

  (import (except (scheme base) bytevector-copy!)
  (scheme write))

  (begin
(define (bytevector-copy! to at from start end)
  (display "derp\n")))

)

 import-except-test.scm

(import chicken scheme)

(use r7rs)

(load "moduleb.sld")

(define dst (make-bytevector 10 0))

(define src (make-bytevector 10 1))

(bytevector-copy! dst 0 src 8 10)

(print dst)

 shell session

$ csi -s import-except-test.scm 

Warning: redefinition of imported value binding: bytevector-copy!
derp
#u8(0 0 0 0 0 0 0 0 0 0)

Note that import-except-test.scm does not import moduleb, it only loads
the sld.

When I made an equivalent test using a chicken (module ...) form instead
of an r7rs define-library form, I did not encounter the redefinition
problem.

This looks like a bug in chicken's r7rs egg to me, but is it?  Should
moduleb (and r6rs-bytevectors) be written differently to avoid this
problem?

Thank you,

John Foerch


___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users