guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] r7rs-wip branch: Add reader and print options to support R7R


From: Freja Nordsiek
Subject: Re: [PATCH] r7rs-wip branch: Add reader and print options to support R7RS bytevector syntax.
Date: Wed, 21 Jun 2017 06:04:54 +0000

Mark,


I saw the stuff in the bytevectors code where the SRFI-4 u8 vectors and bytevectors are essentially the same but with different flavors. The reader option was to make #u8 make bytectors that are exactly the same as #vu8.

Merging the two types solves the reading problem completely since it doesn't matter how they are made, they will be the same type. But, it does still leave the printing problem since there are still two ways to print them, R6RS and R7RS. And it introduces the issue that SRFI-4 u8 vectors would print as #vu8 in R6RS code. One potential solution to this would be to have two different print functions essentially, an R6RS one and an R7RS one and which one one gets depends on which libraries one imports from (R6RS or R7RS), though I can imagine ugliness that this would cause. It really is kind of a tough problem that R6RS didn't go with #u8 notation but R7RS did.


Freja Nordsiek

On June 21, 2017 3:13:07 AM GMT+02:00, Mark H Weaver <address@hidden> wrote:
Hi Freja,

Freja Nordsiek <address@hidden> writes:
Was fiddling around with using Chibi's R7RS test-suite in Guile and
found a major R7RS syntax feature currently missing from Guile. The
feature is R7RS bytevector notation, which uses the #u8 prefix like
SRFI-4 unsigned 8-bit integer vectors instead of the R6RS prefix #vu8.

This is mostly not an issue, because in Guile, SRFI-4 vectors are
actually just bytevectors. All of the bytevector operations work on
them, and 'bytevector?' returns true for them. So, I expect that the
overwhelming majority of R7RS code will work.

To support this, Guile's bytevectors include an additional field called
the "element type", which tells what kind of elements are in the
bytevector, e.g. SCM_ARRAY_ELEMENT_TYPE_U8, SCM_ARRAY_ELEMENT_TYPE_F64,
etc. See srfi-4.[ch] and bytevectors.[ch].

The only remaining issue is that, for some reason which I don't recall,
we have distinct element types for plain bytevectors (as produced by our
bytevector operations, and by reading #vu8(...)) and SRFI-4 unsigned
8-bit vectors (from reading #u8(...)), despite the fact that the
elements are actually the same type. In the C code, they are:

SCM_ARRAY_ELEMENT_TYPE_VU8
SCM_ARRAY_ELEMENT_TYPE_U8

This affects how bytevectors are printed, and it also affects equality
testing on bytevectors:

(bytevector=? #u8(1 2 3) #vu8(1 2 3))
=> #f

My preliminary attempt to mitigate this issue in 'r7rs-wip' was:

commit 84aebcaecb78ac87b0039451becf9623e3ddcce4
Author: Mark H Weaver <address@hidden>
Date: Sun Jan 12 04:44:39 2014 -0500

bytevector=?: #vu8(1 2 3) is equal to #u8(1 2 3).

* libguile/bytevectors.c (scm_bytevector_eq_p): Treat VU8 and U8 element
types as equivalent.

but I'm not sure it's the right solution. This alone will still result
in R7RS code ending up with a mixture of U8 and VU8 bytevectors: the
former for bytevector literals, and the latter as the results of other
bytevector constructors.

Perhaps the more obvious solution would be to completely eliminate the
distinction between SRFI-4 u8 vectors and normal bytevectors by merging
their element types, but there may be problems with that idea as well.

Andy Wingo wrote the bytevector and SRFI-4 implementations in Guile. I
remember talking to him about this issue several years ago, and I seem
to recall that he didn't like the idea of merging the element types, but
I don't remember his rationale. In any case, we should not proceed
without his input.

Andy, what do you think?

Regards,
Mark

reply via email to

[Prev in Thread] Current Thread [Next in Thread]