Space requirements

[Kent Pitman <kmp@harlequin.com>]

   Date: Thu, 15 Jan 1998 15:21:54 -0600 (CST)
   From: Shriram Krishnamurthi <shriram@cs.rice.edu>

   I share Matthias Blume's concern that the new language does not add
   much to the clarity of the document. [...] Why not issue a
   temporary moratorium, await the acceptance of Clinger's paper, and
   base the language on Clinger's classification?

FWIW, I don't share Matthias' expressed concern that this language is
insufficient and would be better off not trying to do a partial job.
That is, I don't think it's worth removing text just to make him
happy.

After my long experience in standards groups, I have evolved some
"wisdom" on consensus-making.  The first part of the wisdom is an
observation: in practice, it's pathetically painful to get people to
agree to something where one group wants it and the other thinks it
would be harmless but useless.  The second part is a recommendation:
the party that thinks it's harmless but useless should yield to those
who don't, because one day the same will happen to them.  This, I
think is the inductive basis of the notion of human tolerance--the
understanding that sometimes we need to concede that others simply see
the world differently than we do, and that if we can't give them
ground even when it costs us virtually nothing, we're never going to
give them any ground.  And if that's so, we breed a horribly
intolerant group.

HOWEVER, in light both of Matthias mail saying maybe e-mail doesn't
present him in the best light, and also Shriram's post above, I have to
also wonder if there's something I could offer for free or little cost
that would satisfy him as well.  And I find myself wondering, as Shriram
does, if--even though Matthias didn't seem to actively propose it--we
wouldn't all be happier to see the full problem solved.

As to timelines, indeed, no one is forcing us.  There may be a sense of
needing to move ahead, but one of the luxuries we enjoy in not being part
of a standards organization is the right to delay things when it would
serve us.  

And we've talked about how we might be reaching a point where we can't go
much farther ahead.  So this might be our last spec.

Finally, it's been on my list for a while to see if I could get
specifications (both Scheme and CL) to be explicit on the issue of
space and speed (or at least algorithmic complexity) in operations.  I
don't think it's a "must do", but I do think it's desirable and would
push the boundaries of "good specification" in a way that would drive
what Sussman has called the "really important" contribution of
programming languages to the 20th century--not "computing" but
"language for human expression of process and computation".  To me,
who isn't generally a Scheme programmer except in occasional
conversations on napkins at restaurants or whiteboards at work, this
standard can really serve me if it contribute usefully to the
terminology for describing computation in spoken language.  And
finding good terminology for talking about space and/or speed seems an
excellent way to do that.  I would hate to see us miss that
opportunity because someone's getting antsy (ANSI?) about milestones
and schedules.

Anyway, if the space discussion ensues and goes nowhere, I will be
among those who ask Matthias to grin and bear it if we add Kelsey's
extra wording (possibly with minor wordsmithing).  But I think we
should indulge ourselves in a "wait and see" expedition on the space
issue if there's any reasonable chance that any full theory (even a
wrong one) could be incorporated.  (Even if we make some mistakes,
they can be revised; but getting the mistakes to a large community to
discuss and think about will be worth it, I think.  Failing to get the
community thinking and talking about the issues will just leave us in
the same place after another publication cycle--wondering if it's
worth a risk.)