a (revised) draft of R5RS

[Kent Pitman <kmp@harlequin.com>]

Matthias> I don't agree with the purpose of such efficiency hacks.

The issue is not just efficiency, it's also semantics.  The only
meaningful semantics that can be usefully applied when an escape
functions passes through an unwind-protect is the one I mentioned
before: the cleanup is run by the GC when it is finalizing the cleanup
function for collection.  That's not just an "efficiency hack", that's
a major aspect of correct program behavior.

To me there is little value to having a clean semantics that can only
describe programs of little value.  Programs that open files, execute
code, and then close them at a deterministic time are not just "obscure
exercises"--they are typical of what people do with computation.

  Telephone Operator: Ok, I've made your plane reservation.

  Me: Could I have the confirmation number.

  Telephone Operator: Certainly, if you don't mind waiting.  I've
    finished my part but we have to wait for the TWA computers to
    run out of memory and garbage collect.  When that happens, the
    system will know I plan to make no further use of the open file
    I had and will close it for me--quite convenient, huh?  I don't
    have to type a thing!  Such a time-saver.  Once the system closes
    the file, I'll be able to get you the confirmation number.

  Me: How long should that take?

  Telephone Operator: Well, it shouldn't be that long.
    You see, the whole system uses this strange technique and so lots
    of memory is held onto that doesn't need to be--and that means we 
    fill up a lot and do lots of GC's--so you see, GC is our friend.
    It adds confirmation numbers AND if it happens often, so our customers
    get their numbers that much faster!

  Me: Wow, is there someone I can call and thank for that?

  Telephone Operator:  Yes, you can call Matthias Blume at--oops, there's
    the GC now....

Also, it won't surprise anyone either that I'd oppose making some
arbitrary and bogus notion that "exceptions" were involved in
here--they are not.  Unwind clauses are not about exceptions--they are
about maintaining the integrity of known program state around a
bounded computation--it is continuations, not exceptions, which create
any problem for that by defeating the notion that there is such a
thing as a bounded computation.  Insisting that the most fundamental
notion is that "I might be back" and that the exception is "I have
some theory of whether or not I'll be back" is the essence of what
makes "goto" unruly and why there is no surprise in my mind that goto
and continuations have a trivially demonstrable relationship and can
even be translated back and forth ...

And if efficiency really should be banned from the language, I suggest
removing any vector-like structures (such as strings).  The only
difference between strings and lists is the computational complexity
of access, and if that's not our concern then I definitely think the
spec could be shortened quite a bit by the removal of a bunch of
things that are presently just for efficiency.  ...  Just thinking aloud.

Matthias> Dynamic-wind _really_ bothers me, because I see no use for it at all.

In my head, this is not dynamic-wind, by the way.  That's something else.
To me, unwind-protect is about setting up wind to happen initiailly
and unwind to be done on "last exit".   Dynamic-wind is about setting up 
wind to be done on each of possibly several entries, and unwind to be done
on each of possibly several exits.  To me, unwind-protect is for protecting
a file's closure even if the writing of the file may involve several swaps
to other stack groups while it writes.  To me, dynamic-wind is about 
keeping straight which dynamic variables, etc. belong to which stack group
so that each can have the illusion of having separate dynamic variables.

In any case, the question I'm talking about is orthogonal to that--its'
a question of having continuations say whether they plan to be re-used so
that one can implement unwind-protect correctly by being able to tell
the final exit; dynamic-wind is easy to implement because it treats all
exits the same, whether you're planning to come back or not. (I could,
with some work, imagine some occasional advantage for it knowing the last
exit, too, but it wasn't my focus here.)

Matthias> The programmer should never have to write (close-port ...)
Matthias> at all.  In fact, there shouldn't have to be a procedure to
Matthias> close ports.

Hmmm.  Maybe we should get people to integrate this into the world in
general.  Good plan.  Waitresses could grab your water glass when you
take the last sip (even if you like to munch on the ice--we'll define
you to be done when you take the last standing liquid), teachers could
collect tests when they see you have answered all questions (we'll
define you to be done when you write the last answer--no use checking
things over), books will be finished after the first draft, if the
system crashes in the middle of writing your mail file, we're declare
it to have been correctly written because no more data seemed to be
forthcoming, ... no, you're right--a world without people consciously
choosing to say open/close will lose no value....

Did you ever use hypercard?  I use it a lot.  It has no save command
to bother me.  I also have no way to revert when I make a mistake
since there is only ever one live copy and quitting saves it.  I can
never know what a "previous version" is since it never "bothers me
about that".

I also know that Alta Vista and other search tools don't "bother me" about
versioning--they just index any old versions of anything they find at any
moment, and they declare (without "bothering me") that they are synchronized.

How about shared sources in a multi-person editing environment.  Let's none
of us access those files by saying when we're taking a lock and when we're
yielding it.  Heck, databases too.  Messy, messy--that "efficiency" biz of
having to say "I'm starting to use now" and "I'm done using now".  Let's
assume any time someone's not reading or writing actively, he's in a correct
and synchronized state--this will certainly improve DB throughput immensely.
Big advance.