On Sat, Jul 7, 2012 at 11:50 AM, Aaron W. Hsu
<arcfide@x> wrote:
John Cowan <
cowan@x> wrote:
> Aaron W. Hsu scripsit:
>
> > write/safe
> > write/shared
> > write/dangerous-stupid-do-not-use-unless-you-think-you-are-neo
>
> Less tendentiously, write/small-fast.
Have we done any benchmarks to see how fast this really is in practice?
It seems like we are assuming it is faster, but I do not remember seeing
anything indicating that it was really significantly faster than
WRITE/SAFE. IMO, the lack of safety of WRITE/SMALL-FAST is hard to justify.
> I assume that the first one writes datum labels for cycles but not
> for shared structure? That would seem to violate the whole notion of
> read-write equivalence: you write out a value with shared structure as
> a datum, but you read it back as a value without shared structure.
It is WRITE/SMALL-FAST when it is safe to do so, but otherwise it is
WRITE/SHARED. Of course if violates read/write equivalence, but so does
normal WRITE with regards to shared structure. As has been pointed out,
read-write equivalence is useful, but it is not the only valid or useful
way of thinking about these things. In particular, backwards compatibility
and pretty printing of code that can be copied back in to a REPL and so
forth. Most of the time you do not need or want to have read-write
equivalence because other things are of more value, such as easier reading,
for humans.
I prefer that we get rid of WRITE/SMALL-FAST and leave only WRITE/SAFE as
WRITE and WRITE/SHARED as either a parameter or an extra procedure. If it
matters that much that they want an unsafe WRITE, then let implementations
provide this separate of the standard, or let them have an implementation
flag that makes WRITE unsafe for cycles. That seems the better approach to
me.