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

   anton at appsolutions.com responded to me:

   > Then here's a dumb question:  I do this all the time:
   >
   >         (let* ([x (first L)]
   >                [p (first x)]
   >                [q (second x)])

   I think that's fine, although you can see an aspect of the issue
   I'm referring to in the above.  [How about]

     (let ([x (first L)])
       (let ([p (first x)]
	     [q (second x)])

I guess that's fine, Anton!  It looks nice, and the only cost is the
extra indentation.  Maybe what confused me is that I use a variable
width font in DrScheme, Helvetica 24, which has just one indentation
problem: To line up p & q indented, I need to skip a line:

(let ([x (first L)])
  (let 
      ([p (first x)]
       [q (second x)])
    ...))

Now I'll respond to you substantively, and then quit.  But I solved my
Math problem which DrScheme was aiding me on, and I feel wordy:

You're making a good point, that there are advantages to unspecified
order of evaluation.  I'm surprised you were able to convince me of
this.  But surely these advantages are too small in this PLT context:

1) MF's crew of theorem provers must have a fixed order of evaluation,
for otherwise, as you say, the semantics are ambiguous, i.e. the
compiler is not a function/algorithm.  

2) As you explained, the historical reason for unspecified eval order
is C compiler speed.  It's not even a Scheme idea!  Again, MF's crew
of theorem provers are sharp enough to overcome the disadvantage of
fixed left->right eval order.  So they do it.  They can & they must.

3) Your let vs let* modification of my code looks better to me.  It
brings out your message: p and q both depend on x, but not on each
other.  But let has similar expressiveness problems!  In the code

(let ([x foo]
      [y goo]
      [z zoo])
  ...)

the order of evaluation of foo, goo & zoo may well matter!  To us, it
might look like it shouldn't, but all we know by not using let* is
that x can't occur freely in goo or zoo, etc.  Mzscheme is gonna
evaluate foo, goo & zoo in order.  

4) I feel that the real issue isn't expressiveness, but compatibility.
Mzscheme is a fundamentally different language than R5RS Scheme.  As
John Clements explained, an R5RS Scheme isn't valid until the
programmer proves to him or herself that their program does not depend
on order of evaluation!  In Mzscheme, you don't have to prove it, and
as you say, the programmers won't prove it, and then their programs
will misfire on other fine Scheme interpreters.  (Actually I don't
know: Do Larceny, Gambit & Trotsky do left->right eval order?)  But
I'm in favor of deviation myself.  As Shriram posted a long time ago,
we don't think of Python and Pearl as being dialects of the same
language, so why Mzscheme & Guile?  That's kinda like shooting fish in
a barrel, but think big: why Mzscheme & anyscheme?