[plt-scheme] two tool ideas

On Friday, February 14, 2003, at 06:55  AM, Neil W. Van Dyke wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> I'd been muddle-headedly using a recursive-function idiom I picked up
> years ago from a CL implementation that (much to my shame) doesn't seem
> to be valid R5RS: essentially treating `cons' as a special form that
> both evaluates its arguments in order and treats the second argument as
> a tail position.  Half a dozen Scheme implementations humored me wrt
> eval order, and it took a debugging session with MIT Scheme to confront
> me with the brutal truth...
>
> This experience suggested two tool ideas:
>
> 1. A useful companion to PLT's evolving test suite framework would be
>    alternate interpreter modes that would vary interpreter behavior
>    within the bounds of the language definition.  For example, after a
>    test suite passes using the interpreter's normal argument evaluation
>    order behavior (which I suspect in many implementations is usually
>    in-order or otherwise predictable), the test execution tool could 
> run
>    N more passes of the suite using randomized evaluation order.  There
>    may be other unspecified implementation behavior for which varying
>    the actual behavior would be useful.

Chez Scheme deliberately chooses an unusual order of evaluation for 
terms in an application.  We don't.  As far as I know, the general 
mzscheme policy is that the terms in an application are always 
evaluated from left to right, and in mzscheme, you can depend on this 
behavior.  This is a difference between mzscheme and RnRS.

As an aside, One of the more unfortunate consequences of the RnRS 
approach is that it is undecidable whether a program is a correct RnRS 
program. MzScheme does not have this problem.

> 2. For educational purposes, a DrScheme "Show Tail Positions" feature,
>    akin to (or integrated with) the "Check Syntax" feature, that uses
>    syntax highlighting to indicate all tail positions that can be
>    determined statically.  (I've actually thought for awhile this would
>    be useful for students doing their first recursion homework, but
>    didn't realize I needed it myself.)

I'm not sure we're talking about the same thing when we say 'tail 
position,' in particular because I don't see how either argument to a 
cons could ever be in tail position.

For the record, I think I can concisely write down a description of 
which expressions are in tail position for core mzscheme:

DEFINE-VALUES: none
DEFINE-SYNTAXES: none
REQUIRE: none
REQUIRE-FOR-SYNTAX: none
VARREF: none (no subexpressions at all)
LAMBDA: the body of the lambda
CASE-LAMBDA: all the bodies of the case-lambdas
ONE-ARMED IF: the then clause
TWO-ARMED (regular) IF: both the then and the else clause
BEGIN: the last expression in the sequence
BEGIN0: none
LET-VALUES/LETREC-VALUES: the last body expression
SET!: none
QUOTE/QUOTE-SYNTAX: none (no subexpressions)
WITH-CONTINUATION-MARK: the body expression
APPLICATION: none
DATUM: none (no subexpressions)

Does this make sense?

john clements