[plt-scheme] Re: to define, or to let
Bill Richter wrote:
> Then here's a dumb question: I do this all the time:
>
> (let* ([x (first L)]
> [p (first x)]
> [q (second x)])
>
> The alternative seems to be nested lets, or not to use the shortcuts p
> and q. I don't like either one. Even if I'm only going to use p and
> q once, I still want to give 'em names!
I think that's fine, although you can see an aspect of the issue I'm
referring to in the above. Without looking at the contents of the
initializers, you can't tell whether q depends on p. In this example, it's
trivial to answer that by inspecting the initializers, but in more complex
code, it's not always as easy. As you point out, you could make this more
explicit with:
(let ([x (first L)])
(let ([p (first x)]
[q (second x)])
Now, you don't need to examine the initializers to tell that q doesn't
depend on p. There's a tiny bit more information in the latter program. In
this case, it's redundant information, since you can infer the latter
program from the former program; but that's not always the case, and
redundant information is often a good thing, anyway.
If you fix evaluation order throughout a program, and lift the
order-dependence prohibition on function application, LET, and LETREC, then
essentially, the same kind of information is removed from all over the
program.
> The "ambiguity" is the part where you don't necessarily know what order
> the compiler will use to lay out evaluations.
>
> OK, thanks, I wouldn't call that an "ambiguity". I'd say that
> somebody's who's good at equivalence proofs might need to know the
> order of eval, in order to drive their proofs.
It is ambiguity if there is no specific guaranteed evaluation order: for
example, if the compiler picks evaluation order for every expression based
on whatever will execute fastest, and if you can't tell from the semantics
what that order will be. This isn't necessarily a good rationale for
unspecified evaluation order, but R5RS allows it.
Anton