[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

a (revised) draft of R5RS

   From: Kent Pitman <kmp@harlequin.com>
   Date: Wed, 19 Mar 97 14:34:55 EST

   cph> The only way I can see to resolve this is to have two languages.  

   Wouldn't work for me because I believe there is never any shame in
   nor lack of grace in finding a way to explain hard things.  Your
   analysis would lead one to believe that Newtonian physics was clean
   and elegant and Einsteinian physics just gunked things up by making
   things more complicated.

   If you made two languages, I would insist on being on the committee
   that designs the elegant one because my concern is about elegance,
   not about efficiency.  If we have made a mistake, it is in our
   definition of elegance.

   I do not accept that the shortest semantics is most elegant.

   Language elegance and program elegance are in tension, and it seems
   to me both are worth considering--and, I think, sometimes the users
   deserve to win.

I'm not trying to say anything about what is "elegant".  I suspect we
would agree about this -- I think that "elegance" has to do with
making the expression reflect the underlying problem as closely and
succinctly as possible.  Sometimes the underlying problem is complex,
and the program expresion should reflect this.  This view is not
shared by the Scheme community as a whole, and perhaps that is another
reason why standardization is fruitless.

I'm also not trying to say anything about "efficiency", nor about the
tension between language and program.

My point, which I obviously didn't make very well, is that it takes
time to understand things well enough to cast them in an elegant form.
In the meantime, people need to write programs, and sometimes, perhaps
often, they need to be able to say things that we don't yet know how
to say in an elegant way.  That is the essential tension that I'm
concerned about -- the tension between those who need a form of
expression now and will except the current best form of that
expression, even if it's clearly not yet right; and those who want the
most elegant form of expression and are willing to wait until it _is_
right.  I think this is the fundamental tension that prevents the
standardization effort from moving forward.

The analogy that I have in mind is that between abstract mathematics
and applied mathematics.  The two fields have very different goals,
but at the same time they are in a synergistic relationship with one
another, and have a large shared base.

   I don't see a WAY (even a hard way) to describe what will happen
   when escape procedures meet unwind-protect unless you require
   programmers to say what their intent is upon invocation of an
   escape procedure, and that in turn leads me to believe you have not
   made a "sufficient" description of the language.

I agree.

I think I have unintentionally mischaracterized the disagreement
between you and Matthias.  I now see that it is orthogonal to my