[plt-scheme] to define, or to let

Some responses to various parts of the thread:

1. Evaluation order is a different issue from allowing access to
   previously-bound variables in the right-hand side of a `letrec'
   binding.

The former is in the spirit of adding hash tables, etc. These are
extras that you can rely on in MzScheme, but not in plain R5RS.

The latter is a case of MzScheme ignoring "is an error" in the
standard. I think there's only one other case like this: if an
expression in a `begin' sequence returns multiple values, MzScheme
always allows it (except for the last expression, where it depends on
the dynamic context).

2. MzScheme is not actually R5RS-compliant.

Anton is obviously correct --- it's the time at which the variables
receive their values that makes MzScheme non-compliant, not the lack of
an error, and not the order of right-hand-side evaluation. I've been
sloppy to leave the "MzScheme is R5RS" claims in place.

2. Internal defines versus `letrec'.

I agree that `letrec*' is a more natural target for a sequence of
internal definitions. In fact, it's possible that `letrec*' will appear
in R6RS for this purpose.

3. Changing MzScheme's `letrec' to match R5RS.

I don't know.

Originally, `letrec*' was included in MzScheme so that programmers
could explicitly request the current behavior. But I only saw the
is-an-error difference, and not the time-of-assignment difference, so I
defined `letrec' as an alias for `letrec*'. Of course, no one used
`letrec*', so it was dropped.

For v300, we could restore `letrec*' and make `letrec' compliant with
R5RS. But we would also need something like `begin*' to have internal
definitions expand to `letrec*' (since R5RS requires `letrec'), and
that's where it starts to get painful.

Another possibility is to add `letrec*', change `letrec', and define
internal-definition expansion to use `letrec*'. MzScheme would remain
technically non-compliant with R5RS, but it might be well-positioned for
R6RS compliance.


Matthew