Control of record printing #214

New issue

Open

opened 2024-10-10 11:35:54 +00:00 by dpk · 1 comment

dpk commented

2024-10-10 11:35:54 +00:00

Owner

This is, to my knowledge, the only non-R6RS record system feature for which the existing N is even remotely reasonable. In fact, it easily beats 3: Chez (albeit in a section marked ‘legacy’), Chicken, Guile, MIT Scheme, Vicare. (Chibi also seems to support something like this, but it’s undocumented.)

Of these models, Vicare and Chez are likely the closest to being the best to follow if we do adopt this, since they handle recursive structure correctly.

Without readtables, this is purely a debugging feature. But it is useful for implementing data structures, because consumers do not really want to see either the internal structure, nor (if you make the type opaque) an uninformative #<something> which tells them nothing about what’s in it, but a list of the items/associations/whatever in the structure. (And if someone is reimplementing read themselves they can of course add the ability to read back in whatever types they like.)

This is, to my knowledge, the only non-R6RS [record system feature](https://codeberg.org/scheme/r7rs/wiki/Record-system-features) for which the existing N is even remotely reasonable. In fact, it easily beats 3: [Chez](http://cisco.github.io/ChezScheme/csug9.5/objects.html#./objects:s182) (albeit in a section marked ‘legacy’), [Chicken](http://wiki.call-cc.org/man/5/Module%20(chicken%20base)#record-printer), [Guile](https://www.gnu.org/software/guile/manual/html_node/SRFI_002d9-Records.html#Custom-Printers), [MIT Scheme](https://www.gnu.org/software/mit-scheme/documentation/stable/mit-scheme-ref/Structure-Definitions.html#index-print_002dprocedure), [Vicare](https://marcomaggi.github.io/docs/vicare-scheme.html/iklib-records-printer.html). (Chibi also seems to support something like this, but it’s undocumented.) Of these models, Vicare and Chez are likely the closest to being the best to follow if we do adopt this, since they handle recursive structure correctly. Without readtables, this is purely a debugging feature. But it is useful for implementing data structures, because consumers do not really want to see either the internal structure, nor (if you make the type opaque) an uninformative `#<something>` which tells them nothing about what’s in it, but a list of the items/associations/whatever in the structure. (And if someone is reimplementing `read` themselves they can of course add the ability to read back in whatever types they like.)

dpk added this to the Record-Winning Fascicle milestone 2024-10-10 11:35:54 +00:00

dpk added the

Foundations

label 2024-10-10 11:35:54 +00:00

aag commented

2024-10-10 15:32:27 +00:00

Owner

I would love to see this standardized. Even without recursion, it is helpful for debugging.

MIT Scheme has a standard way of including identifying numbers in the printing of an object, even without custom printing. Those identifying numbers are put into a weak hash table associated with the REPL, and stay around for long enough that they can be referred to for a while later, but don't cause too much garbage to accumulate. So if an object is printed like this:

#[unit-test 13 (annual-event->absolute-date)]

it can later be referred to like this: #@13.

Even if that isn't standardized, it would be great if whatever record-printing mechanism we choose could accommodate such a mechanism.

I would love to see this standardized. Even without recursion, it is helpful for debugging. MIT Scheme has a standard way of including identifying numbers in the printing of an object, even without custom printing. Those identifying numbers are put into a weak hash table associated with the REPL, and stay around for long enough that they can be referred to for a while later, but don't cause too much garbage to accumulate. So if an object is printed like this: `#[unit-test 13 (annual-event->absolute-date)]` it can later be referred to like this: `#@13`. Even if that isn't standardized, it would be great if whatever record-printing mechanism we choose could accommodate such a mechanism.

No labels

Macrological Fascicle