[plt-scheme] to define, or to let

Felix Klock wrote:
> > Isn't violation-detection just a small modification of standard
> > free-variable analysis, where in this modification you do not descend
> > into the bodies of LAMBDA expressions (and instead, the free-vars of
> > a lambda is always the empty list)?
> >
> > This sounds *cheaper* than free-variable analysis to me.
> >
> > What is the difficulty here?  The need to macro-expand prior to doing
> > the analysis?  Or...?
>
> Or did I once again backtrack in understanding of the problems here?
>
> Is the real problem this business of capturing (and re-entering)
> continuations within the expression-to-be-bound?
>
> I agree that seems hard to detect.

There's some overlap between the two issues.  If you guarantee left-to-right
evaluation, *and* allow right-hand-sides to depend on prior bound values,
then unless you go to impractical extremes in the implementation, you
violate the R5RS semantics.  The reason is that evaluating the
right-hand-sides and
variable binding then have to be interleaved, whereas R5RS says that
right-hand-sides should be evaluated before binding takes place.

But you're right, simply detecting variable dependencies should not be
*difficult*, exactly.  But it still might not be all that desirable from the
implementor perspective:

> But I wasn't trying to address detection of that violation.  I was
> instead trying to suggest that the R5RS language in DrScheme detect the
> access of previously-bound variables in the right-hand side of `letrec'
> binding.  That, to me, seems like the piece of the extension that is
> most likely to be mistakenly used by a developer when they attempt to
> write portable code that conforms to R5RS (as Anton stated in his
> response to Matthew).

It would also have to handle shadowed variables, i.e. references to a
variable which is bound both in the letrec as well as in an enclosing scope.
This might then merit a warning that the variable may not be the one that
the programmer intended to reference - at least, it's not an actual error,
even per R5RS.

As you say, this analysis would have to be done on the macroexpanded result,
so might not fit nicely in a macro implementation of letrec.  If I were an
implementor, I think I'd rather implement the R5RS semantics, than implement
a warning about non-R5RS-compliant dependencies (and I think MzScheme is
fine doing neither).

One issue is that the analysis is unnecessary simply for the purpose of
compiling and executing the program.  It might fit better into something
like the "Check Syntax" feature (or a corresponding "Check Semantics"
feature - MrFlow?)

Anton