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(...) Marc Nieper-Wißkirchen 15 Nov 2022 11:20 UTC

Am Di., 15. Nov. 2022 um 11:54 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> > 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.

This also came to my mind, but records are a fundamental concept, so
reserving one letter for records does not seem too costly.  After all,
by using the record syntax, one can possibly get rid of a lot of
otherwise needed lexical syntax.

E.g., instead of reserving "#&<datum>" for boxes, one could simply
write "#r(box <datum>)" (when we reserve the uid "box" for SRFI 111
boxes).

In fact, I would suggest reserving record uids that are not of the
recommended R6RS form <name>-<uuid> for the standard.  This opens up a
whole new namespace for written representations.

Also, note that hypothetical prefixes like #r8 or #ru16 would still be
in the list of not yet reserved prefixes.

> https://codeberg.org/scheme/r7rs/issues/9
>
> Daphne
>
>