[plt-scheme] Re: to define, or to let

Bradd, everything you say is fine, except I did make sense here:

   > But I bet MF would say just that, and it sounds reasonable: "My
   > interpreter isn't gonna let people assert things that my
   > interpreter (static or no) can't enforce."

   That doesn't make sense: The interpreter is just one tool for testing
   correctness, and it's not even the most important tool. 

OK, but the interpreter isn't just a tool to testing for correctness.
It's the definition of the programming language.

   "It compiles and runs" is a very weak verification criterion. 

Sure, you can have all kinds of bugs in your code waiting to leap out
when some minor change is made.  I'm sure you & Anton know a lot more
about this than me, and I'm not trying to dismiss your skills.
BrBackwards sound like a good tool for someone to write.

I think I'm about done.  Let me summarize:

1) I jumped in mostly because I was grateful to DrScheme for helping
me solve a Math problem <http://www.lehigh.edu/~dmd1/br49.txt>.

2) And I was shocked that R5RS Scheme has ambiguous semantics (about
   eval order).  That's perfectly obvious, but I missed it somehow.

3) And I decided I like definite semantics, i.e. an algorithm for the
   interpreter, and even like left->right eval order, for LC reasons.
   It sounds right up MF's alley: we can reason about an algorithm.

   One benefit is that a class of bugs has been eliminated, the
   moving-target-compiler bug.  It's no longer necessary to prove that
   your program works for this wide variation of compiler.  It only
   has to work for the left->right Mzscheme compiler.  I'm not saying
   this is a huge benefit, or even an overall plus, but it means you
   no longer have to prove this theorem about your code: "there's no
   place where changing the order of eval would affect my program."

4) But you, Anton & others are making good points: a fixed eval order
   isn't altogether a good thing.  Ambiguous eval order can flush out
   bugs, and it encourages functional programming.  The best way to
   make sure you don't trigger the moving-target-compiler bug is
   functional programming: don't use any mutation.  And that's good!

5) But I'm not convinced that anyone's made a suggestion that would
   really improve matters.  I think what's really needed is good
   articles about how to program with mutation.  As Anton pointed out,
   HtDP doesn't say much about mutation. plt-scheme is even a great
   place to post articles about good mutation programming practice.