External representation: #[...] vs #r(...) Marc Nieper-Wißkirchen (15 Nov 2022 08:40 UTC)
Re: External representation: #[...] vs #r(...) Shiro Kawai (15 Nov 2022 08:47 UTC)
Re: External representation: #[...] vs #r(...) Daphne Preston-Kendal (15 Nov 2022 10:54 UTC)
Re: External representation: #[...] vs #r(...) Marc Nieper-Wißkirchen (15 Nov 2022 11:20 UTC)
Re: External representation: #[...] vs #r(...) Marc Feeley (15 Nov 2022 12:26 UTC)
Re: External representation: #[...] vs #r(...) Marc Nieper-Wißkirchen (15 Nov 2022 12:34 UTC)
Re: External representation: #[...] vs #r(...) Marc Nieper-Wißkirchen (15 Nov 2022 12:47 UTC)
Re: External representation: #[...] vs #r(...) John Cowan (15 Nov 2022 13:30 UTC)
Re: External representation: #[...] vs #r(...) Lassi Kortela (15 Nov 2022 17:21 UTC)
Re: External representation: #[...] vs #r(...) John Cowan (15 Nov 2022 20:33 UTC)
Re: External representation: #[...] vs #r(...) Arthur A. Gleckler (15 Nov 2022 18:02 UTC)

Re: External representation: #[...] vs #r(...) Daphne Preston-Kendal 15 Nov 2022 10:54 UTC

> On 15 Nov 2022, at 09:40, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> On the other hand, given the existing notations for bytevectors,
> #vu8(...) and #u8(...), the lexical syntax
>
> #r(uid field ...)
>
> may make more sense for records.  (As Scheme has Records and not
> Structs, I am using an R, not an S, here.)
>
> The latter syntax has the advantage that it does not rely on a
> difference between parentheses and brackets (which are, otherwise,
> equivalent, at least in R6RS).

The disadvantage is that we have a limited number of letters to use after #, and we’ve already used quite a number of them.
https://codeberg.org/scheme/r7rs/issues/9

Daphne