This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home. For a version of this page that may be more recent, see WG1Ballot3Results in WG2's repo for R7RS-large.

WG1Ballot3Results

cowan
2012-04-04 10:13:46
3history
source

WG1 Ballot 3 Results from July 1st

Notes about Results

See WG1BallotExplanation.

Previous Undecided and Re-opened Ballot Items

#32 user-defined types

Do we support any means of creating disjoint user-defined types, such as in SRFI-9, SRFI-99 or the R6RS record system?

WG1 voted srfi-9 before. New arguments against filter constructors were raised, so the ticket was re-opened.

Cowan
The most important thing about SRFI 9 is how pervasive it is (26 out of 30 implementations I track at http://tinyurl.com/scheme-s5 support it). Yes, it's messy. Yes, we should keep it.
Gleckler
I had initially voted for SRFI 99 as my top choice, but I'm now convinced that that's just too complicated a system for core Scheme. We need something more fundamental upon which other systems can be built. However, I don't want to give up convenient syntax, so I've added a new choice, RecordsGleckler, which is simple combination of RecordsCowan and RecordsArcfide. That way, we get both. SRFI 9 is widely used and is about the simplest syntactic implementation one could hope for. It doesn't support inheritance. As Aaron Hsu has pointed out, it has problems with filtering constructors. RecordsArcfide is also simple and, while an earlier version supported inheritance, this one doesn't. It is a syntactic system. It uses the name `define-disjoint-type'. It is car...
Hsu
SRFI-9 is flawed by the filtering constructor and a lack of extensibility in its syntax, but represents a good minimal set of features that are found everywhere.
Medernach
Please notice that there was a Condorcet's paradox on this item in the last ballot: as such I think that we need to be open-minded and have space for alternatives record systems, instead having "one record system to bind them all". I would put widespread srfi-9 into a module named (scheme record srfi-9) and let doors open for others (scheme record ...).
Read
I'm a big fan of unique types since with unique types and vectors you can build records. However, SRFI-9 is so widespread and so relied upon by the R5RS community that it's worth it not to turn our backs on those users. Standards should be about reflecting the best of common practice, not handing down new untested practice.
Shinn
This is what we voted on before, it's extremely widely supported, and I remain unconvinced of the alternatives. Filtering constructors can be a useful convenience (and optimization) in some circumstances.

#28 Binary I/O ports

Do we provide any binary input or output ports, and if so how do we construct them and operate on them? Can binary and textual operations be mixed on the different port types?

BinaryPortsCowan provided binary port operations, being a mild revision of the relevant parts of PortsCowan. It has been removed by Cowan in favor of PortsShinn.

PortsShinn provides binary port operations, with similar operations to BinaryPortsCowan but keeping the binary/textual ports disjoint.

R6RS provides an entirely new I/O system, as well as a separate R5RS-compatible I/O system.

The withdrawn SRFI-91 provides yet another I/O system supporting binary ports.

Note this item as well as #29 and #31 specify semi-orthogonal aspects of I/O systems which are typically specified together by individual proposals. If the same proposal doesn't win for all three, the aspects will be merged as needed.

WG1 voted weakly in favor of PortsCowan before.

Hsu
I think we still need more time on this. R6RS' biggest trouble is its I/O system, and I don't want the same mistake being made again. We need more effort into this domain first by more people.
Read
The Gambit port system is a working, tested implementation generally regarded as a win.

#83 Auxiliary Keywords

In R6RS auxiliary keywords (such as else in cond and case forms) are explicitly exported from the (rnrs base (6)) library. Do we want to bind and export these from the core library?

If else is bound in the default module, then it must be imported at the call site whenever using it in cond or it won't match hygienically.

If else is not bound in the default module, then it must not be bound or imported at the call site whenever using it in cond or it won't match hygienically.

Another option is to specify for cond and case that they match the else identifier literally, ignoring any hygiene. This breaks compatibility with R5RS and R6RS.

WG1 voted unbound previously. New issues were brought up on the list so the ticket was re-opened.

Cowan
The arguments for binding this convince me.
Gleckler
I just don't understand the issues here well, so I'll leave the debate to others for now.
Hsu
While there are advantages to being unbound, unbound is still too limited and the advantages do not outweight the disadvantages. Bound has a few disadvantages, but we gain much more flexibility and the advantages just outweigh the disadvantages. Unbound limits what you can do, while Bound presents only some minor inconvenience that sometimes occurs, but that is easily worked around in ways that aren't hacky.
Shinn
I'm reversing my former preference on this. Keywords in Scheme are broken, but we can't break hygiene and we need to decide whether they are bound or not in this standard, pending future improvements. Leaving keywords unbound allows multiple unrelated macros to use the same keywords, but Chez breaks in this case. Fortunately, for the keywords used in the standard, all macros can refer to the same bindings, so I recommend we bind them and perhaps recommend third-party modules to _not_ bind their keywords.

#3 module naming convention

We need a naming convention for the core modules and standard libraries of the new module system.

The existing break down is based on John Cowan's earlier proposal of factorings in items #71, #72, #73, #74, #75, #76, #77, as well as an I/O module breakdown in PortsCowan. There have been various tickets proposing changing this, so we are re-opening the ticket.

Cowan
Note: The (scheme io) module in the draft was never voted on and doesn't belong there.
Gleckler
My own proposal, ModuleFactoringGleckler, is a simple combination of ModuleFactoringCowan and ModuleFactoringShinn.
Hsu
I have not had enough time to look this over.
Shinn
I prefer Medernach's proposal to my own here.

New Ballot Items

WG1 - Core

#85 Blobs, bytevectors, byte-vectors, octet-vectors, or something else?

Now that we have blobs, we have to decide what to call them. R6RS uses bytevector, SRFI-4 and SRFI-68 uses u8vector, while the original WG1 proposal used blob (which is therefore the default).

Cowan
I call them blobs because I see them as objects whose size is measured in bytes, not specialized vectors of 8-bit unsigned integers. It's easy to layer such an interpretation, along with many other interpretations, on top of blobs, but blobs should themselves remain simple for WG1.
Gleckler
While "blob" is a widely used term these days, I prefer a properly hyphenated, descriptive term.
Hsu
Blob doesn't give enough information to the reader and feels strange, despite its terseness. Bytevector very accurately describes the data structure we are dealing with. No matter how you decide to treat those bytes, we are still dealing with a vector of bytes, not a vector of 3 bits or something else. I disagree that there is confusion on how to use a bytevector just because the word "byte" appears in the name. On the other hand, blob gives no hints on how to use the structure at all, or even what sort of things might be available.
Read
I am partial to "bytevector" myself. Failing that the Erlang term for these things is "a binary". I can understand where that might cause confusion, so "blob" is probably as good an alternative as any.
Shinn
This is pure bikeshedding, and the charter makes it clear we should prefer the R6RS option when there is no good reason otherwise.
SnellPym
I think it's important to keep blobs distinct from typed arrays. A blob is a region of memory; u8vectors are a particular interpration thereof. Blobs may be measured in bytes, but that's just due to the granularity of access - they aren't necessarily composed of independent u8s (they might be composed of u16s, or floats, or a complex structure). However, if we have to conflate them, I'd rather go with SRFI-4 names.

#118 Simple literals must be explicitly delimited.

In R5RS syntax such as #t#f is left unspecified - some readers may parse this as the true literal followed by false. R6RS requires identifiers, characters, booleans, number objects, and . to be terminated with a "delimiter" or by the end of input.

Cowan
Allowing #true to mean #t rue is just silly. If implementations want to accept #true, they should be able to do so.
Hsu
I prefer to create less ambiguity here.
Read
What are we, 8-bit kiddies packing code into Microsoft BASIC? FORI=1TO10? Delimiters are there for a reason. We should make use of them.
Shinn
This is an ambiguity in R5RS that has no benefit and should be clarified.

#119 Whether to treat # as a delimiter.

In R5RS foo#f is a valid identifier, whereas R6RS requires # to act as a delimiter, so that this would parse as the identifier foo followed by the false literal.

Cowan
Backward compatibility rules here. Chicken depends heavily on identifiers with embedded #s.
Hsu
We have ways such as with the vertical bar of enclosing data, so there is no reason to make something like # confusing to the reader. |foo#f| is clear, while foo#f is not, so let's make # a delimiter.
Read
You would break Gambit's namespace separator!!!
Shinn
Several implementations make use of this for extended identifier syntax.

#123 Extend unquote and unquote-splicing to multiple arguments

This is a change also made by R6RS (and CL).

Cowan
I'm not convinced this is useful enough.
Gleckler
One of the threads above indicates that Alan Bawden approves of this change. I defer to Alan's infinite wisdom in all things related to macros.
Hsu
Convincing arguments have been made as to why this is a good thing on the mailing list, and there are too many unsolved issues if we leave it as single.
Shinn
I'm unconvinced. The use cases seem rare (especially since WG1 has no low-level macros), and the semantics not obvious.

#124 Nested quasiquote semantics

Cowan
R6RS is better defined, and we should accept it. The vagueness in R5RS helps nobody.
Hsu
R6RS makes things much easier to work with in this regard. We should adopt this. I have encountered situations where this makes a great deal of sense, especially in macro writing.

#125 Allow procedures not to be locations (making EQV? unspecified in some additional cases)

This is a change also made by R6RS.

Cowan
Treating procedures as locations distinguishable by eq? is a hack nobody ought to depend on.
Hsu
This gives more flexibility to the implementation when dealing with quasiquote.
Read
What if a procedure gets inlined at every call site? What is its location then?
Shinn
We need a better rationale. Do any implementations do this, and why?

#126 Partly specify the mutability of the values of quasiquote structures

This is a change also made by R6RS, specifically:

A quasiquote expression may return either fresh, mutable objects or literal structure for any structure that is constructed at run time during the evaluation of the expression. Portions that do not need to be rebuilt are always literal BEFORE is called whenever execution enters the dynamic extent of the call to THUNK and AFTER is called whenever it exits that dynamic extent. Jeronimo Pellegrini scripsit: > According to Section 6.7.1, "Conversely, not all character ports are > binary ports -- for example, the /string ports/ discussed below". It > is not really clear to wether the document *requires* string ports not > to be binary or if it was just an example of a port that *could* be > character but not binary. I haven't thought about it, but I guess it *could* be the latter, if the environment provides a default encoding for string ports. Existing features of IEEE Scheme may be removed only if a strong case can be made that they are fundamentally flawed. Insofar as practical, the language should be backwards compatible with the IEEE standard, the R5RS standard, and an appropriate subset of the R6RS standard. Unfortunately, most programming languages give nondescript names such as DIV(IDE), QUOT(IENT), MOD(ULO), and REM(AINDER) to these operations. The language should make clear to programmers what division operations their programs are performing, especially when negative dividends and divisors can arise, but perhaps may not often arise during testing. [...] The R5RS gives the names quotient and remainder to the truncating division operator pair, and the name modulo to the remainder half of the flooring division operator pair. For all these three procedures in the R5RS, the dividend may be any integer, and the divisor may be any nonzero integer.

On the other hand, we may prefer relegating them to a backward-compatibility module.

Vote "yes" to keep, "no" to remove, and "module" to relegate to a module.

Cowan
On reflection, every implementation will go on supporting them anyway, if just to keep old code working. Consistent with my "modules = optional" views, I see no reason to have a module here. There should be discouraging language in the report, though.
Hsu
I think we can reasonably relegate these, but I'm hesitant to remove them completely, since they tend to be very commonly used. More discussion is a good thing here.
Medernach
Please keep it, too much code rely on it and there are natural names.
Read
We should not suddenly take away what many Scheme programmers rely on.
Shinn
Too big a change.
SnellPym
I'd love to see them removed to make Scheme more consistent, but in hindsight, it's a petty incompatibility with existing code.

#151 Extend finite? and nan? to non-real values

R6RS specifies the domain of finite? and nan? as the real numbers only. I propose that finite? return #t on a non-real value iff both the real part and the imaginary part are finite and not +nan.0, and that nan? return #t on a non-real value iff either the real or the imaginary part is +nan.0.

Cowan
That is, what's proposed there. This is what people who do complex flonum programming need.
Hsu
I don't know the ramifications of this, and I would like more discussion on this.
Shinn
This seems reasonable assuming the implementations have such numbers.

#152 exact-integer-sqrt inconsistent with multiple values module

R5RS does not actually specify any procedures which return multiple values, and so the decision to separate multiple values to a module was reasonable. However, we also voted to make exact-integer-sqrt, which is in the base module, return multiple values, namely the root and the remainder. That would make the procedure useless unless multiple values are provided.

We can either make multiple values not a module, make exact-integer-sqrt return a list (or single integer) rather than multiple values, relegate exact-integer-sqrt to a new module, remove it altogether, or do nothing and leave the inconsistency.

Cowan
Multiple values are cheap to provide poorly for implementations that don't care, and can be provided well with some effort by implementations that do. No need to make them optional, therefore. Doing so also removes an extra dependency from WG2 packages that want to return multiple values.
Hsu
I don't want to have any procedure in the language that uses lists/pairs as intermediate container constructs, as I am offended (in some ways) by that sort of conflation of the use of lists. Values should be in the core.
Medernach
Why not a module containing tricky arithmetic operations ?
Read
Multiple values is the cleanest way to do this. Promote to core.

#180 Make case and cond clauses into bodies

Andy Wingo suggests: make the clauses in case and cond forms (without =>, naturally) be BODY instances, to allow them to have definitions. It is well defined AFAIK, and costs nothing.

The counter-argument is that it doesn't "look" like the sort of place definitions are allowed.

Cowan
There is nothing in Scheme like ((= x y) (define z ...) (+ z x y)) except at top level. Let's not go there.
Gleckler
Ugly, and let's not extend the language beyond common practice in trivial areas like this.
Hsu
There is no reason not to do this. If you don't like the style, then don't use it, but a standards body should not be in charge of dictating good style.
Read
Oh no you di'int.
Shinn
This is confusing.

#181 Add WHEN and UNLESS to the base module

Cowan
These are good things, and there is no reason to keep them separated out as if they were untouchables.
Hsu
These are very useful and help to discourage one-armed ifs.
Read
These sound like Perl or Ruby constructs. Scheme could use a dose of the brevity and convenience those languages provide. (Thought not too much...)
Shinn
If anything, WG2.

#182 Add WHILE and UNTIL

These trivial syntaxes add familiarity for new Scheme programmers coming from other languages, as will almost always be the case. LOOP is too big and named-LET too alien.

Cowan
Yes, I know we are not supposed to encourage mutability. But we have a lot of it already, particularly when dealing with ports.
Gleckler
These go against the grain of the language. Are they even widely supported?
Hsu
They are rarely if ever used among non-beginner Scheme programmers, and I know of very few teachers who would encourage its use. Thus, they don't provide enough usefulness to the general Scheme community to warrant standardization.
Read
They are convenient. But what about DO?
Shinn
Emphatically not - this actively encourages non-functional programming, and proper loop macros are more flexible anyway.
SnellPym
named-let is a good thing to learn!

#183 Escaped newline removes following whitespace?

Andy Wingo suggests the R6RS handling of escaped embedded newlines:

"asdadf \ asdfadf"

in R6RS has the same meaning as "asdf asdfadf". It allows you to nicely indent strings that you need to line-break for width. I suggest that the production

\ NEWLINE WHITESPACE*

within string literals be elided.

Note an alternate method for handling embedded strings with nice indentation is scribble syntax.

We voted on various string syntaxes previously but did not specifically propose this R6RS extension. We should have a rationale if we don't follow it.

Cowan
Cheap and useful.
Hsu
This is really useful, but the scribble syntax is also very useful, and we should consider this as a separate ticket.
Read
Shell scripts and C use it all the time.
Shinn
This is ugly and confusing, and unnecessary if embedded newlines are specified.

#184 Require CHAR=?, STRING=? etc. to accept arbitrary numbers of arguments?

R5RS makes a point of specifying that supporting more than two arguments is optional. (Everything not explicitly mentioned is optional, so this may have significance.) R6RS requires accepting 2 or more arguments. Currently Racket, Gambit, Guile, Chez, Ikarus, Larceny, Ypsilon, Mosh, and Scheme 9 support the feature, whereas Gauche, MIT, Chicken, Bigloo, Scheme48/scsh, Kawa, SISC, Chibi, STklos, and SSCM don't.

Cowan
I think the R5RS implementations should be bootstrapped into the future here. It also meets the consistency guideline in the charter.
Hsu
I don't understand why we would limit this. It seems like an strange limitation to enforce on users. I would like to see more rationale on why we might want to vote no, but otherwise I tihnk they should accept multiple numbers of arguments.

#185 Add sixth "centered" division operator

From the Guile manual:

These procedures accept two real numbers x and y, where the divisor y must be non-zero. centered-quotient returns the integer q and centered-remainder returns the real number r such that x = q*y + r and -|y/2| <= r < |y/2|. centered/ returns both q and r, and is more efficient than computing each separately.

Note that centered-quotient returns x/y rounded to the nearest integer. When x/y lies exactly half-way between two integers, the tie is broken according to the sign of y. If y > 0, ties are rounded toward positive infinity, otherwise they are rounded toward negative infinity. This is a consequence of the requirement that -|y/2| <= r < |y/2|.

Note that these operators are equivalent to the R6RS operators div0, mod0, and div0-and-mod0.

--Andy Wingo

Taylor Campbell thinks these are useless. We should probably have use cases for _any_ division operator we include.

Cowan
I'm not convinced they are useful except maybe to do bignums with, in which case it's easy to define them. Note: There are rationales for most of the division operators at Riastradh's original proposal.
Hsu
I don't understand these well enough to vote on them yet.
Shinn
There are too many division operators already. What are they all used for? We need to revisit this.

#195 Editorial: proposed rewording for begin

The documentation for `begin' specifies that it is a sequential construct; but really it splices as well, and also of course it's a keyword for the module system currently. This is inaccurate of the spec to say that "begin is for sequencing".

Suggestion: adopt the language of R6RS section 11.4.7.

--Andy Wingo

We should explain somewhere the four kinds of begins: (begin expr ...), (begin decl ...), top-level begin, and module-top-level begin. Note that R7RS like R5RS does not have (begin decl ... expr ...).

Vote yes to adopt the R6RS description, modified for differences in the language.

Cowan
I think this is a documentation issue only: the documentation Andy complained abuot is just for expression-begin.
Hsu
I think we ought to have a splicing begin form, so I don't know what else would differ between R6RS and R7RS in this regard.
Shinn
We can revisit the language, though R5RS doesn't correspond exactly to R6RS here.

#198 Make it an error for a procedure mapped by MAP and friends to mutate the result list/string/vector

This is possibly difficult to enforce, and can break existing R5RS programs written in very bad style.

Cowan
I don't see how it can break anything, because no R5RS program can count on map using a mutable-result implementation anyway. Vector-map and string-map are more likely to.
Hsu
We don't have to enforce this, but it does let people write things in a way that they can get away with being slightly lazy. Making it an error is a good thing in this case.
Medernach
No, but please put a warning about doing it in the report as "shooting yourself in the foot".
Read
You don't want to modify a list you're mapping over. Not EVER. Map is a functor from scheme objects onto lists of scheme objects. It says nothing about HOW the function is to be mapped; if the list is mutated mid-map, you don't know what the results will be. "It is an error" means the behavior could be undefined, which is definitely the case here.
Shinn
But I don't expect many implementations will actually signal an error in this case.

#199 Make it an error for a procedure mapped by MAP and friends to return more than once

This is possibly difficult to enforce, and can break existing R5RS programs.

Cowan
"Difficult to enforce" is irrelevant; "is an error" means no Scheme programmer should rely on the results of it.
Hsu
I would like to know the ramifications of this.
Medernach
Multiple returns is one Scheme essential feature, let not restrict it, there is no reason here.
Read
See above.
Shinn
Returning more than once is not inherently a bad thing, and if anything we should rely on #172. There's simply no reason to make this an error.

#200 Completing the blob procedures

Add blob, blob-map, blob-for-each, and blob conversion functions to and from lists/vectors/strings.

Cowan
Too much for WG1.
Hsu
Ratione: I know that these would be useful, but I don't know what they would look like, and they should be in the spirit of blobs and not ad hoc.
Medernach
Unappropriate for blobs.
Shinn
Too much - we'll want a blob library in WG2 anyway.
SnellPym
Blob's don't have an internal structure to map or for-each over. Sure, we can measure positions in them in bytes, but that's distinct from saying they're *made* of bytes.

#205 Roll partial-blob-copy(!) into blob-copy(!)

... with extra arguments.

Cowan
We did not roll substring into string-copy with additional arguments; the only reason not to use subblob as a name is its risibility.
Hsu
This simplifies the name space and should make things easier. I like this sort of interface better than remembering another name.
Shinn
These are redundant.

#206 Provide read-syntax for blobs

R6RS provides a #vu8(...) read-syntax for bytevectors. SRFI-4 uses #u8(...).

Cowan
I can't see anyone writing these by hand. They might add a little efficiency compared to a blob procedure (analogous to string, vector, and list).
Hsu
We should have one, regardless of what we pick, and I prefer the more descriptive (slightly) R6RS version more than the SRFI-4 version.
Read
Ugly. Not likely to be used in code.
Shinn
Bikeshedding, R6RS wins.

#207 Editorial: Polar complex numbers are inexact

Add a note saying that 1@2 and (make-polar 1 2) MAY evaluate to an inexact complex number.

Cowan
This is obviously an oversight: exact values passed to make-polar aren't going to come out exact from make-rectangular, and essentially all Schemes store complex numbers as rectangulars internally. (The Pure language supports both representations internally, but I can't see going there for standard -Scheme.)
Hsu
I haven't thought enough about this.
Read
If you must do computing with exact polar numbers, you know where to find the records/uniqueness types.
Shinn
This makes sense.

#208 Is || a valid identifier?

The grammar in 7.1.1 allows || as an <identifier>. However, page 5 suggests the |...| form is only for convenience (e.g. |foo bar| is equivalent to foo\x20;bar). There's no way to normalise || to anything without the vertical bars that's a valid identifier. Was that intentional, or should the rule be

<vertical bar> <symbol element>+ <vertical bar>

Vote remove to remove the |...| syntax altogether.

Cowan
Not sure why this is supposed to be the default. || is convenient on occasion, and allows string->symbol to accept any string.
Hsu
There's no reason to limit the bar syntax when || is a perfectly good identifier. We should remove language that suggests it is only for convenience.
SnellPym
What else would (string->symbol "") return?

#191 Include CLOSE-PORT ?

Should we include close-port, as a generic version of close-input-port and close-output-port?

Cowan
I could see adding this to a Scheme that has input/output ports to close both sides of the port, but the WG1 standard doesn't have them. Just as a generic procedure, no.
Gleckler
It seems silly to omit this since it's so useful and common. I note that the title of this ballot item takes advantage of case-insensitivity.
Hsu
It's useful and general, but I'm not attached to it.
Shinn
You generally know whether it's an input or output port.

#188 Clarify wording of and and or definitions

The definitions of and and or may be slightly confusing. Reword them to be more clear. One possible hiccup is that the current language permits the return of different false values, while a clearer wording may preclude this.

R6RS provides a clearer definition that does not provide wiggle room for multiple false values. Should we use that?

Cowan
I know why Guile needs multiple false values (to handle Emacs Lisp as well as Scheme), but I'd rather see such a system saying it overrides the Standard in this respect.
Gleckler
I don't see any reason we should have to vote on whether to make things clearer. However, I don't see any reason to worry about permitting different false values.
Hsu
We should clarify this wording specifically to eliminate this ambiguity about false values.
Read
I've seen where multiple falses can lead us in Python. I don't want to go there.
Shinn
I don't see why we need to go out of our way to forbid multiple false values if an implementation has them.

#187 Clarify duplicate bindings in let*

The language of the standard could clarify that duplicate bindings are permitted in the clauses of a let*.

Cowan
Why not?
Hsu
Arguably this is not necessary, but it does help people who are trying to read the standard. This is an issue that has cropped up from time to time so maybe it makes sense to include language about it in the standard, even at the expense of a bit of verbosity.
Read
Given the sequential nature of let*, it makes more sense than for let or letrec.
Shinn
Meh.

#215 initial value argument to make-blob

make-blob should either have an initial value argument, or rationale why it is inconsistent with make-vector and make-string.

Vote yes for an initial value argument.

Cowan
As noted, I don't see blobs as specialized vectors. Still, I suppose initialization to all zeros couldn't hurt. Okay.
Hsu
I assume that this will be an optional argument, so, yes.
Read
Consistency is good.
Shinn
This is pretty useful, especially without blob-fill!.
SnellPym
BLobs don't have an internal structure to "fill". Let new blobs be all zeroes, as there's no boundaries in a string of zero bits...

#216 Controlling use of reader labels on output

There are cases when one does not want to output reader labels for shared structure, such as when you don't care (and want the output to be more legible), or when you know that the time or space requirements to construct the table will be too large.

We could offer a parameter to control this, or have a separate procedure (e.g. write/simple) which doesn't use the reader labels.

Finer grained control may also let use specify a predicate for which values are interesting (e.g. never use labels for strings), or only use labels for cycles, etc.

Cowan
I think a separate procedure is marginally better than a parameter.
Gleckler
However, I don't like the name. I'd prefer write-simple', write-simply', or `write-without-reader-labels'.
Hsu
Is this is common use? What would this look like? I want more discussion on this, but otherwise, I am not sure it makes sense, so I'm going with none after undecided.
Medernach
However write-simple would be a better name (Ok, this is bikeshed)
Read
A separate procedure makes sense, and is easy for the programmer to comprehend.
Shinn
This control is necessary.
SnellPym
Putting too much of this stuff into parameters means it's easy to assume wrongly about how write will behave, forgetting that some caller might tinker with some parameter and BREAK YOU.