Newsgroups: comp.lang.scheme
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: mkatz@garlic.stanford.EDU (Morris Katz)
Subject: Fixing the order of evaluation. Minimizing the unexpected.
Message-ID: <9104081645.AA16444@garlic.Stanford.EDU>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
References: <9104062148.AA00250@letaba.rice.edu>
Date: 8 Apr 91 16:45:14 GMT
Lines: 74

   Date: Sat, 6 Apr 91 15:48:09 CST
   From: matthias@rice.edu (Matthias Felleisen)


     It seems to me that the logical extension of your argument is that we
     should return to pure scheme by removing all of the imperative
     constructs from Scheme since their value does not offset the loss of
     referential transparency.

   (1) I want a simple mental model for what I have and in particular an
   expressive language. That includes call/cc, side-effects, ...

   (2) You're wrong about referential transparency. Talcott, Mason, and I
   have shown that side-effects have equational theories, in which you
   can substitute equals for equals. 

While I am perfectly willing to believe that this theory fulfills the technical
definition of referential transparency (based on substitution), I continue to
believe until convinced otherwise that languages with side effects of the type
present in Scheme lack an intuitive property which has coloquially refered to
as referential transparency.

      I have yet to hear from your side a real cost/benefit analysis.  What
     I have heard is that you (collectively) do not have a good feel for
     the benefits of unspecified order of evaluation and see a cost to it,
     so it should go.

   I was hoping that Scheme would be a semantics like ML, which has a
   simple semantics that can be used to prove meta-properties about the
   language. And in which simplicity and elegance ALWAYS (empahsis added by
   mjk) takes priority over ease of implementation.

I never understood the goals of the Scheme community to be such that the word
always would be appropriate in the above sentence.  I would substitute often,
usually, or normally.

      my current research involves automatic parallelization of scheme
      through optimistic concurrency plus rollback.  The ability to choose
      the effective order of evaluation of arguments at runtime can greatly
      reduce the amount of rollback required in a system like mine and
      thereby markedly improve performance.

   I am not an expert but notice that left-to-right does not mean that
   the assembly code goes from left to right. It only means that any
   effects that happen will always occur from left to right. 

   My calculi always begin the evaluation in expressions in some
   arbitrary order. But the axiom for discharging a beta and side-effects
   forces left-to-right. I strongly believe that compilers could do that
   too. And quite a few compiler writers tell me that I am probably
   right.

     I would like to see serious programs people desire to write that a
     seriously hampered by unspecified order of evaluation so I can better
     appreciate that category of costs.

   I hope that the above made it clear that this is not my kind of
   argument. Just because I do have an order of evaluation does not mean
   that my code will rely on it. Ever. It only means that I rely on it
   when mentally tracing execution. And my mind just cannot imagine
   unordered execution. 

For metally tracing execution of a program written in a language with
unspecified order of evaluation, one should be able to chose any arbitrary
order of evaluation in order to determine what the program does.  I do not see
the problem with tracing correct programs.  There is a potential problem in
tracing incorrect programs which unintensionally depend on evaluation order,
but this seems to me to be more of a problem in debugging and development
environment technology than of language design.  What exactly is troubling you
here?
--------------------
Morry Katz
katz@cs.stanford.edu
--------------------