New draft (#4) of SRFI 207: String-notated bytevectors Arthur A. Gleckler (05 Oct 2020 15:56 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Wolfgang Corcoran-Mathe (05 Oct 2020 17:29 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Daphne Preston-Kendal (05 Oct 2020 18:05 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Wolfgang Corcoran-Mathe (05 Oct 2020 19:18 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Marc Nieper-Wißkirchen (05 Oct 2020 20:19 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Wolfgang Corcoran-Mathe (06 Oct 2020 05:44 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Wolfgang Corcoran-Mathe (06 Oct 2020 16:14 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Marc Nieper-Wißkirchen (06 Oct 2020 17:16 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Daphne Preston-Kendal (07 Oct 2020 09:07 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Marc Nieper-Wißkirchen (07 Oct 2020 09:24 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Daphne Preston-Kendal (07 Oct 2020 09:49 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Arthur A. Gleckler (07 Oct 2020 15:08 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Marc Nieper-Wißkirchen (07 Oct 2020 15:22 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Wolfgang Corcoran-Mathe (07 Oct 2020 15:57 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Marc Nieper-Wißkirchen (07 Oct 2020 16:06 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Wolfgang Corcoran-Mathe (07 Oct 2020 16:22 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Wolfgang Corcoran-Mathe (06 Oct 2020 18:14 UTC)
Re: New draft (#4) of SRFI 207: String-notated bytevectors Daphne Preston-Kendal (07 Oct 2020 10:01 UTC)

Re: New draft (#4) of SRFI 207: String-notated bytevectors Daphne Preston-Kendal 05 Oct 2020 18:05 UTC

On 5 Oct 2020, at 19:29, Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:

> * Having two different intepretations for strings is a kluge, so
> `bytestring' should adopt the same interpretation of string
> arguments that string->bytevector uses.  (This might obviate the
> need for string->bytevector in the first place.)

I don't see your point here. string->bytevector parses the string it is
given as input; bytestring does not (except in the most rudimentary
possible sense of the word 'parse').

> * Can we get rid of the horrible `v' argument to bytevector->string?
> R6RS implementations of this function could be allowed to prepend the
> 'v', and I think this could be handled more cleanly with cond-expand.

I've been hoping an R6RS implementor or heavyweight user would weigh in
on whether a #vu8"…" syntax would be desirable or useful. for them. If
it's not, it can go. (Also all mentions from the library procedures.)
But I've never seriously used R6RS, so I'm not qualified to decide.

Daphne