Am Di., 15. Nov. 2022 um 13:26 Uhr schrieb Marc Feeley (via srfi-237 list) <[email protected]>: > > The external representation for records used by many implementation of Scheme > is the syntax #<name ...> . Wouldn’t it make sense to use that syntax?
This syntax is already used by a lot of implementations for things without a standard written representation and which are not records. > It isn’t clear what purpose the external representation will serve. It could > be just for debugging, or to have a write/read invariance of records (for > saving/restoring objects from files for example). Write/read invariance is a > much more complex feature, especially if the records are generative, but also > if the Scheme implementation has added features to records such as > inheritance and hidden fields (very useful if you have circular structures > such as a “parent” field in a tree node). It is about read/write invariance. Please take a look at SRFI 237 how the issues you point out are resolved; in particular, only non-generative, non-opaque records are given representations. Marc > For debugging it is convenient to have the names of the fields as part of the > external representation. A record with more than 3-4 fields becomes > difficult to read (for humans) when there are no names next to the fields. > > Moreover, I find it very convenient for debugging to assign serial numbers to > records (and other not-necessarily-readable objects) so that they can be > referenced at the REPL to get the exact same object back (not a copy). > Here’s an example at the Gambit REPL: > > > (define-type point x y) ;; a generative record type > > (define rect (list (make-point 11 22) (make-point 33 44))) > > rect > (#<point #2 x: 11 y: 22> #<point #3 x: 33 y: 44>) > > (point-x-set! #2 999) ;; reference the first point in the list using #2 > > rect > (#<point #2 x: 999 y: 22> #<point #3 x: 33 y: 44>) > > (lambda (x) (* x 2)) > #<procedure #4> > > (#4 100) > 200 > > Note the use of #N to refer to the object wih serial number N. The serial > number of objects are generated lazily (when the object is written) and they > are kept in a weak hash-table so they are generally valid until the object is > no longer reachable. The #N notation does not conflict with #N= and #N# that > is used for representing cycles and sharing (as long as the character = and # > don’t follow the N a #N is a reader macro that expands to > (serial-number->object N) ). > > Write/read invariance of records (and other typically not-readable objects) > is achieved by setting the input/output port to a special mode because this > is typically not what you want for casual writing of data. > > Marc > > > > > On Nov 15, 2022, at 6:20 AM, Marc Nieper-Wißkirchen > > <[email protected]> wrote: > > > > Am Di., 15. Nov. 2022 um 11:54 Uhr schrieb Daphne Preston-Kendal > > <[email protected]>: > >> > >>> On 15 Nov 2022, at 09:40, Marc Nieper-Wißkirchen > >>> <[email protected]> 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 > >
