Am Di., 15. Nov. 2022 um 13:34 Uhr schrieb Marc Nieper-Wißkirchen <[email protected]>: > > 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.
PS A representation tailored to debugging is outside the scope of SRFI 237 (and should probably remain implementation-defined); as you write, such can coexist with the SRFI 237 representation by setting some parameter on the relevant textual port. PPS How does Gambit print serial numbers assigned to pairs and vectors? > > > > 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 > > > >
