R7RS tangerine (scheme bytevector) and R7RS small (scheme base)

[Shiro Kawai]

I couldn't find discussion on this elsewhere.   Is it required that the bytevector object created by make-bytevector of  (scheme bytevector) and

the one created by make-bytevector of (scheme base) the same type?

I supposed there would be no reason to make them different.  However, there are some procedures that have the same name but

different signature, so we can't simply import both (scheme bytevector) and (scheme base) without fiddling names with only/except/rename/prefix.

If two libraries are that different, I noticed it'd be better to make it clear that both work on the same type of object, if that's the intention.

[John Cowan]

On Thursday, July 25, 2019 at 10:53:52 PM UTC-4, Shiro Kawai wrote:

I couldn't find discussion on this elsewhere.   Is it required that the bytevector object created by make-bytevector of  (scheme bytevector) and the one created by make-bytevector of (scheme base) the same type?

Not required (because Guile doesn't do it), but strongly recommended by SRFI 160.

 

I supposed there would be no reason to make them different.  However, there are some procedures that have the same name but

different signature, so we can't simply import both (scheme bytevector) and (scheme base) without fiddling names with only/except/rename/prefix.

Oops.  That's not supposed to happen.  Can you specify which ones for me?  Thanks.

-- 

John Cowan          http://vrici.lojban.org/~cowan        co...@ccil.org

All Norstrilians knew that humor was "pleasurable corrigible malfunction".

        --Cordwainer Smith, Norstrilia

[Jeronimo Pellegrini]

I'm really sorry to bring back such an old thread, but while working on a (scheme bytevector) implementation for STklos I have found the same problem as Gauche's author. The incompatibilities that I found are (only the first one is really a problem):

1. bytevector-copy! -- the signatures are different:

(bytevector-copy! source source-start target target-start k) ; R6RS

(bytevector-copy!  to at from [ start end ]) ; R7RS

2. bytevector-copy -- signatures are different, but not incompatible:

(bytevector-copy bytevector) ; R6RS

(bytevector-copy bytevector [ start end ]) ; R7RS

3. (Not a big problem, but introduces an inconsistency in design, and requires attention, and perhaps changes to other R7RS procedures to keep the system consistent with itself)  Negative byte/octet arguments to make-bytevector, bytevector-fill! etc:

R7RS says bytevectors are vectors of "bytes" which are positive, but do not actually restrict make-bytevector or bytevector-set! to values in [0,255], so it is possible to interpret "signed 8-bit numbers" as bytes (but that is not the first intuitive interpretation -- STklos forbids negatives here, for example). Luckily, any programs written for the R7RS API will till work with the R6RS one (which accepts anything in the [-128,255] range, as explicitly required by the standard), although it feels a bit strange. One needs to be careful to also modify the other bytevector constructors (like `bytevector`) to maintain consistency.

Were these modified in the R6RS errata? I can't connect to r6rs.org for some reason (is the site down?), and can't find the R6RS errata anywhere else -- standards.scheme.org also points to r6rs.org for the errata...

Thanks a lot!

J.

[John Cowan]

On Sat, Jul 16, 2022 at 3:22 PM Jeronimo Pellegrini <jeronimo....@gmail.com> wrote:

I'm really sorry to bring back such an old thread, but while working on a (scheme bytevector) implementation for STklos I have found the same problem as Gauche's author. The incompatibilities that I found are (only the first one is really a problem):

1. bytevector-copy! -- the signatures are different:

(bytevector-copy! source source-start target target-start k) ; R6RS

(bytevector-copy!  to at from [ start end ]) ; R7RS

This is indeed a problem, and we have no solutions, only workarounds.  Larceny's approach is, when running in a hybrid REPL ("larceny --r7r6"), to import the R6RS version as `r6rs:bytevector-copy!`.  This choice was made because all other destructive copy procedures place the destination before the source.  If you impot (rnrs bytevectors) explicitly, you get the unprefixed R6RS version, of course.

Fortunately, all other conflicts between R6RS and R7RS-small procedures and macros can be handled under the general R7RS permission for domain extension, signature extension, etc.  See Clinger's paper "R7RS Considered Unifier of Previous Standards" at <http://andykeep.com/SchemeWorkshop2015/papers/sfpw1-2015-clinger.pdf> for details.

 

3. (Not a big problem, but introduces an inconsistency in design, and requires attention, and perhaps changes to other R7RS procedures to keep the system consistent with itself)  Negative byte/octet arguments to make-bytevector, bytevector-fill! etc:

This is also a domain extension, though not mentioned in Clinger's paper.

Were these modified in the R6RS errata? I can't connect to r6rs.org for some reason (is the site down?), and can't find the R6RS errata anywhere else -- standards.scheme.org also points to r6rs.org for the errata...

See <http://web.archive.org/web/20220622194331/http://www.r6rs.org/>.

[Marc Nieper-Wißkirchen]

Am So., 17. Juli 2022 um 16:22 Uhr schrieb John Cowan <co...@ccil.org>:

On Sat, Jul 16, 2022 at 3:22 PM Jeronimo Pellegrini <jeronimo....@gmail.com> wrote:

I'm really sorry to bring back such an old thread, but while working on a (scheme bytevector) implementation for STklos I have found the same problem as Gauche's author. The incompatibilities that I found are (only the first one is really a problem):

1. bytevector-copy! -- the signatures are different:

(bytevector-copy! source source-start target target-start k) ; R6RS

(bytevector-copy!  to at from [ start end ]) ; R7RS

This is indeed a problem, and we have no solutions, only workarounds.

Is it really a problem? I don't think so because we have a library system.

 

  Larceny's approach is, when running in a hybrid REPL ("larceny --r7r6"), to import the R6RS version as `r6rs:bytevector-copy!`.  This choice was made because all other destructive copy procedures place the destination before the source.  If you impot (rnrs bytevectors) explicitly, you get the unprefixed R6RS version, of course.

Fortunately, all other conflicts between R6RS and R7RS-small procedures and macros can be handled under the general R7RS permission for domain extension, signature extension, etc.  See Clinger's paper "R7RS Considered Unifier of Previous Standards" at <http://andykeep.com/SchemeWorkshop2015/papers/sfpw1-2015-clinger.pdf> for details.

It should be noted that Clinger's paper does not contain a complete survey of all such "conflicts". For example, let-syntax in R6RS splices, while it does not in R7RS.

Moreover, it should be noted that many of these "conflicts" go away in Clinger's paper because the requirement of R6RS that the implementation raises an exception when a procedure is called with arguments outside its specified domain is ignored.  However, it is this requirement that some of those favoring R6RS find an important asset of R6RS.

Thus, I would, in general, treat the R6RS and the R7RS version of a procedure or library as a different thing.

But, as said above, fortunately, we have the library system.

 

 

3. (Not a big problem, but introduces an inconsistency in design, and requires attention, and perhaps changes to other R7RS procedures to keep the system consistent with itself)  Negative byte/octet arguments to make-bytevector, bytevector-fill! etc:

This is also a domain extension, though not mentioned in Clinger's paper.

Were these modified in the R6RS errata? I can't connect to r6rs.org for some reason (is the site down?), and can't find the R6RS errata anywhere else -- standards.scheme.org also points to r6rs.org for the errata...

See <http://web.archive.org/web/20220622194331/http://www.r6rs.org/>.

http://www.r6rs.org works for me.

Marc

[John Cowan]

On Sun, Jul 17, 2022 at 11:26 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

This is indeed a problem, and we have no solutions, only workarounds.

Is it really a problem? I don't think so because we have a library system.

A nuisance problem is still a problem.

It should be noted that Clinger's paper does not contain a complete survey of all such "conflicts". For example, let-syntax in R6RS splices, while it does not in R7RS.

True.

Moreover, it should be noted that many of these "conflicts" go away in Clinger's paper because the requirement of R6RS that the implementation raises an exception when a procedure is called with arguments outside its specified domain is ignored. 

Also true.  "larceny --r7r6" is an implementation of R7RS that preloads both the R7 and the R6 libraries modulo the R6RS `bytevector-copy!`.  "larceny --r6rs" is a somewhat non-conformant implementation of R6RS.

 

http://www.r6rs.org works for me.

Ah, good.  It wasn't working for me last night.

[Jeronimo Pellegrini]

On Sunday, July 17, 2022 at 11:22:55 AM UTC-3 co...@ccil.org wrote:

On Sat, Jul 16, 2022 at 3:22 PM Jeronimo Pellegrini <jeronimo....@gmail.com> wrote:

3. (Not a big problem, but introduces an inconsistency in design, and requires attention, and perhaps changes to other R7RS procedures to keep the system consistent with itself)  Negative byte/octet arguments to make-bytevector, bytevector-fill! etc:

This is also a domain extension, though not mentioned in Clinger's paper.

Yes - I know it's technically correct to implement it as describe -- I only felt that it feels like the language becomes slightly inconsistent, in an aesthetic sense. But then, it was proposed and accepted -- it's fine.

 

Were these modified in the R6RS errata? I can't connect to r6rs.org for some reason (is the site down?), and can't find the R6RS errata anywhere else -- standards.scheme.org also points to r6rs.org for the errata...

See <http://web.archive.org/web/20220622194331/http://www.r6rs.org/>.

Thank you!  That was all I was missing to finish the implementation.

J.

 

[Vladimir Nikishkin]

FWIW, http://www.r6rs.org works, while https://www.r6rs.org does not.

Who is maintaining the website? I can message them and ask to add a
letsencrypt certificate, if that's appropriate.

> --
> You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAD2gp_T%2B42F837dtVoRiaO2vbhu2Kq0VGBujxwwMqiMtwt2neQ%40mail.gmail.com.



--
Yours sincerely, Vladimir Nikishkin
(Sent from GMail web interface.)

[Taylan Kammer]

On 17.07.2022 17:26, Marc Nieper-Wißkirchen wrote:
> Am So., 17. Juli 2022 um 16:22 Uhr schrieb John Cowan <co...@ccil.org <mailto:co...@ccil.org>>:

>
>
>
> On Sat, Jul 16, 2022 at 3:22 PM Jeronimo Pellegrini <jeronimo....@gmail.com <mailto:jeronimo....@gmail.com>> wrote:
>
> I'm really sorry to bring back such an old thread, but while working on a (scheme bytevector) implementation for STklos I have found the same problem as Gauche's author. The incompatibilities that I found are (only the first one is really a problem):
>
> 1. bytevector-copy! -- the signatures are different:
>
> (bytevector-copy! source source-start target target-start k) ; R6RS
> (bytevector-copy!  to at from [ start end ]) ; R7RS
>
>
> This is indeed a problem, and we have no solutions, only workarounds.
>
>
> Is it really a problem? I don't think so because we have a library system.

I think it's a very serious problem. I wrote a bug because of it in the past,
because the following piece of code may work regardless of which library you
import, but will do different things:

(bytevector-copy! bv1 i1 bv2 i2 k)

One of the most common uses is also the most problematic:

(let ((len (bytevector-length bv1)))
(bytevector-copy! bv1 0 bv2 0 len))

With R6RS, it copies bv1 into bv2.

With R7RS, it copies bv2 into bv1.

Just awful, really. Probably the one worst incompatibility between R6 and R7.

I wonder if bytevector-copy! should be deprecated because of this, and a
different name introduced. (Probably with the R7 semantics.)

Maybe bytevector-transfer! or bytevector-copy-to!.

--
Taylan