[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
- To: Christopher.McConnell@A.GP.CS.CMU.EDU, Masinter.PA@Xerox.COM
- Subject: Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 6 Oct 88 00:41 EDT
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <881005-204718-2157@Xerox>
Given that no one currently supports the suggested action, this
may technically be a clarification, but I think it would be better
to say CLARIFICATION/CHANGE to be clear up front about the fact
that careful reading is in order.
I would prefer if ~S was used instead of ~A in the examples.
This is not a clarification. It's
Date: 5 Oct 88 20:47 PDT
From: masinter.pa@Xerox.COM
...
Issue: PRINT-CIRCLE-STRUCTURE
...
Proposal PRINT-CIRCLE-STRUCTURE:
When *print-circle* is T, the printer should detect and print
circularities using the #n# syntax even if a structure has a user
defined print-function. Circularities need only be detected for
objects that would normally be printed by the default structure
print-function.
Sentences one and two are vague enough that I can't tell why they don't
contradict each other.
A user defined print-function can print any object that is pointed
to by the structure being printed, or any object that would normally
be printed as a component of such an object and expect circularities
to be detected.
This isn't adequately specific for my taste. I can sort of guess where
these restrictions are coming from, but from the point of view of the
explicitly written text here, they seem unmotivated.
...
Cost to Implementors:
I believe that it is a rather straightforward change. All of the
implementations detect circularities for the default structure
printer. All that is required is to perform the same circularity
check and printing #n= before or #n# instead of what would normally be
generated by the user defined print-function.
I don't think this is specific enough.
...
Discussion:
...
This use of the printed representation of objects could be alleviated
if there existed some mechanism equivalent to the
sys:dump-forms-to-file function provided by Symbolics.
This is in a throwaway position in the document. If it's really true
that this is an alternative in general (which I'm not sure I believe),
then I don't think this proposal has given me an adequate survey of
the issues and options.
Overall I'm sympathetic to the issue but not (yet) to the proposal.
There's something kind of vague and hand-wavey about the writeup that
doesn't make me feel like I know exactly what I'm signing up for or why.
It's entirely possible that a tighter rewrite of the same idea would fix
things, though. At this point, I don't have any sense of a fundamental
objection looming in the wings.