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.
On Tue, 17 Dec 2002, Marc Feeley wrote: >This is not at all my perspective. I manipulate large cyclic data >structures all the time (doubly-linked lists, trees with >back-pointers, object system class descriptors, etc), my programs >(sometimes!) have bugs and I want to dump these cyclic data-structures >nicely so that I can figure out what the problem is. I do this all >the time! It would be a shame if I could not combine the >pretty-printing feature with the shared data printing feature. My >point is that these features are not mutually exclusive, so the API >should be designed to let the user pick the features needed. Okay.... you've convinced me that there needs to be some kind of extensible mechanism for specifying options. > - 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 concept in R5RS and, AFIR, also undefined in all existing Scheme standards and SRFI's. I'm not convinced that hidden fields as such are a good idea, and if anyone needs them they can be implemented with standard scheme data structures such as pairs, vectors, etc. I'm not going to piggyback definitions of entirely new, or implementation- dependent, language features onto this SRFI. > - Should numbers that are eq? be marked as shared or not? For > example in (123 . 123) both numbers are probably eq?, and perhaps > also in (0.0 . 0.0). Well, my intent was to recover (eq?) relationships when reading anything that had been written. And at first glance I was prepared to simply answer, "no, numbers are (eq?) whenever they are (eqv?), so this is a distinction that makes no difference." However, that was over hasty, because R5RS states: > Eq? and eqv? are guaranteed to have the same behavior on symbols, > booleans, the empty list, pairs, procedures, and non-empty > strings and vectors. Eq?'s behavior on numbers and characters is > implementation- dependent, but it will always return either true > or false, and will return true only when eqv? would also return > true. Eq? may also behave differently from eqv? on empty vectors > and empty strings. So it appears that there may be situations in which numbers may be (eqv?) without being (eq?) in some schemes. (What scheme are you using, marc? I've never had this happen and didn't know it was possible!) So at second glance it would look like this would gum up the works badly, because if I, in an implementation where numbers are (eq?) whenever they are (eqv?), write a structure and marc, in an implementation where numbers have individual identities as well as values, reads a structure, odds are the structure I wrote is not going to be the same as the structure he reads regardless of the behavior of our (write-showing-shared) function. And vice versa, of course. But at third glance, (eq?) objects behave just like (eqv?) objects in the absence of assignment - and there is no way in R5RS to assign to a number or a character without changing its identity and thereby terminating the (eq?) relationship -- without a side effect on whatever it formerly had an (eq?) relationship with. In an implementation where (eqv?) numbers can be non-(eq?), they are guaranteed to be non-(eq?) after an assignment to one of them, and the other will not be changed by that assignment. This is just as though they had been non-(eq?). And this is also true of characters. Numbers and characters are the lowest-level entities, not mutable containers for values. So the effects of mutation on numbers or characters that are or aren't (eq?) will never make a difference to normal program semantics. So this must be why the R5RS authors chose to allow implementation-dependent behavior on exactly those two classes of values; because under normal program semantics the distinction can never matter. And at fourth glance, we must take into account abnormal program semantics. Of course, those are the ones that are specifically relying on the function (eq?) itself -- and this is unavoidable because (eq?) itself has different semantics in our two implementations and our programs would have behaved differently even on the identical original structure! Aargh! What we have here is a clear case of trying to provide stable, portable infrastructure and discovering that infrastructure necessary to support it and beyond the scope of what we are trying to provide here, is neither completely stable or portable. Crap. I still believe that (write-showing-shared) is more portable and reliable than (write), but clearly the Right Thing To Do is forced to also be implementation-dependent, and thus of limited portability, here; on schemes that allow non-(eq?) numbers and characters to be (eqv?) it should show (eq?) relationships among numbers and characters, and in schemes where all (eqv?) numbers and characters are also (eq?), it should not. > - Should the low-level code of procedures (bytecode, or whatever) be > dumped? Same issue for continuations. Again, implementation-dependent. (Write-showing-shared) must produce an external representation for anything that has an external representation under (write), and those are entities that may or may not have an external representation under your particular implementation's (write) and (read) functions. If this SRFI mandates implementors coming up with a portable notation for the low-level code of comiled routines, just watch how fast they scramble to ignore it. I'd like to have that, sure, but it's unreasonable - and also not easily or portably implementable. > - Should the object be written as text or in binary? After all if a > human is not going to read the data using text is just wasteful. > A binary representation, or even a special purpose textual > representation would be more compact. Text is now and has always been more portable across systems. And human readability, while not the purpose of a structure write, has benefits in debugging and other places as you've pointed out. >So in the end the "write-showing-shared" procedure still needs >parameters. I'm considering it, but I'm far from convinced. > We don't yet know how many we need (and probably never >will as the need for new features never ceases to grow). And this makes me exceedingly loath to include and define them at this point. > This is why >an API based on dynamically bound parameter objects is needed. >Alternatively, explicit keyword parameters could also be used: No. Dynamically-scoped parameters and keyword parameters are pure mud in a lexically-scoped prefix-notation language. I will not recommend them because they are ugly and introduce complications and dependencies. What you want to pass in, *IF* you insist on parameterizing the call at all, is probably a thunk. > (write obj port shared: #t pretty: #t) Without introducing any strange unportable calling conventions or syntax definitions, you could say this; (let ((writetable (lambda (arg) (case (arg) ((prettyprint) #t) ((show-shared) #t) (else #f)))) (port standard-output-port)) (write port writetable)) You can dress it up with syntax any way you want, but the above is the basic structure of the call you want, and probably what I'd write because I don't like keeping bunches of syntax definitions in my head. But I persist in saying that while leaving room for a prettyprint extension isn't a bad idea, providing the prettyprint extension, or any other beyond showing shared structure, is absolutely not what this is about. >I have also found readtables to be a good way to package up the >parameters that are used by "write" and "read". The readtable >specifies the external representation and "write" and "read" use >the readtable when generating the external representation or >when parsing an object. Right, the same idea as the thunk I assigned to the variable named 'writetable' above. But I would avoid calling it readtable; that name is in use for a different concept by Common Lisp. Bear