Re: [Scheme-reports] Write procedure is not backwards compatible

[Aaron W. Hsu <arcfide@x>]

John Cowan <cowan@x> wrote:

> Aaron W. Hsu scripsit:
>
> > > 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. 

[...]

> Alternatively, you can traverse the whole graph using the length algorithm
> before you start to print anything, but that necessarily costs time.

My question was not whether it costs time at all, but whether that cost is 
actually significant. I am sure that you could come up with some arbitrary 
micro-benchmarks that would allow you to measure this cost, but what I 
really want to know is whether this cost is a measurable, significant 
part of any unwanted lack in performance in non-trivial, practical code 
where people care about the speed of the program execution.

I strongly suspect, but have no proof, that the cost of having a safe 
write procedure is dwarfed by most other costs, and will not contribute 
significantly to the running time of the vast majority of programs, if 
it contributes significantly to any at all. If this suspicion is true, then 
there is no reason to have a standard, unsafe write procedure. The 
dangers that it necessarily entails cannot be justified, either in terms 
of the cost of putting in the standard itself, or the cost in maintainence 
compared to just using the safe variant. Like I said, in the worst case, 
this is a flag you switch on and off for compilers. I see no justification 
for putting it in the standard. I see justification for the other two 
variants, and I think that keeping the unsafe version and the shared 
version, but leaving the safe variant out of the standard is strange. 
It's like saying that we should have fx+ but not +, to me.

> Lastly, write/small-fast is perfectly safe if you know you don't construct
> cycles, and lots of programs do know that (if they don't use set-car! or
> set-cdr!, for example).

Again, it strikes me as the wrong choice to have an unsafe variant sitting 
around for no demonstrable benefit, leaving out the safe one. This is a 
performance hack that need not be in the standard.

-- 
Aaron W. Hsu | arcfide@x | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.