This page is part of the web mail archives of SRFI 38 from before July 7th, 2015. The new archives for SRFI 38 contain all messages, not just those from before July 7th, 2015.
> > - Should hidden fields of an object be written or not? This is > > useful for debugging but also for saving an object to a file and > > reading it back in later. > > This is immaterial since "hidden fields" are a completely undefined The list of on/off switches I mentioned in my message was just an example to show that many variations exist. I was not suggesting that you add them to the SRFI, in fact for most of the switches it is clearly premature to finalize a design. My point is that there are many variations to "writing data so that it can be read back". The fact that many of them are implementation dependent is not important. It just means that individual implementors will be faced with the problem of expressing these variations. Because there are so many variations (at least at some point in the future) and they are not mutually exclusive, the variations should not be expressed through the name of the procedure. Parameters should be used. Your choices are: 1) positional parameters 2) keyword parameters 3) dynamically scoped parameter objects I have expressed my preference between these three. But this preference is a detail. The important thing is to have a parameterized procedure. Let me move on to a second topic. Orthogonal to the particular parameter passing being used is the issue of whether the options should be packaged or not into one structure. This can be a procedure, as you suggested, or as a data structure, that is the "readtable" that I suggested. Now don't be fooled by the name "readtable" which was chosen for historical reasons (and because it is a short name). It is really a data structure that specifies the external representation of data. This information is both useful for "write" and for "read". In fact, to guarantee that "read" is able to read data that has been written with "write", the same readtable must be supplied to "read" and "write". For example, here is some of the information that can be found in a Gambit-C readtable: - Whether sharing is allowed (i.e. the notation #0#, #0=...). - The maximum depth and length that should be written. - Whether case should be preserved in symbols, character names, etc. The choices are: yes, no and map to lowercase, no and map to uppercase. - Whether keywords are allowed. The choices are: no, yes and ":" is at end, yes and ":" is at start. - Whether control characters in strings should be escaped. - The set of characters that can be escaped in a string (i.e. \n, \\, etc). - The set of characters that are named (i.e. #\space, #\newline, etc). - The set of special #! objects (i.e. #!eof, #!void, etc). - Whether evaluation is allowed (i.e. the notation #.<expression>). - The formatting rules for pretty-printing. Once again this is just an example. I'm not suggesting that you handle all of these. You could limit yourself to the first one and leave the "readtable" type open for extensions. Readtables and dynamically scoped parameter objects can be combined in an interesting way. Imagine that to each port is attached a parameter object that corresponds to the readtable that is used for calls to "read" and "write" on that port. When a port is created some sort of "standard" readtable is used (which makes "write" and "read" behave as specified in R5RS). Suppose that (port-readtable-parameter port) returns the parameter object that is attached to the port and that (readtable-shared-set readtable flag) returns a copy of the readtable where the "shared" option is set to flag (it does *not* mutate the readtable passed as an argument). This gives a very flexible API: - You can "write" in a standard way: (write X port) - You can setup a port so that all output is in a particular style: (let ((port (open-output-port "foo"))) (let ((rt-param (port-readtable-parameter port))) (rt-param (readtable-shared-set (rt-param) #t))) (write X port) ; uses the sharing notation (write Y port) ; uses the sharing notation ) - You can temporarily do output in a particular style, on a specific port: (let ((port (open-output-port "foo"))) (let ((rt-param (port-readtable-parameter port))) (parameterize ((rt-param (readtable-shared-set (rt-param) #t))) (write X port))) ; uses the sharing notation (write Y port) ; uses the standard notation ) - You can have different threads doing output in their own particular style (this could be useful if you have a REPL thread and a "main program" thread and you want output from the REPL to be in a particular style): (let ((port (open-output-port "foo"))) (thread-start! (make-thread (lambda () (let ((rt-param (port-readtable-parameter port))) (parameterize ((rt-param (readtable-shared-set (rt-param) #t))) ...body of the child thread...))))) ; uses the sharing notation ... ; the parent thread uses the standard notation ) Again I'm not suggesting you go this far. The main point of my message(s) is to make your procedure parameterizable so that such extensions are possible (to be defined in other SRFIs). Marc