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

Bill Richter wrote:
> Bradd, everything you say is fine, except I did make sense here:

>     But I bet MF would say just that, and it sounds reasonable: "My
>     interpreter isn't gonna let people assert things that my
>     interpreter (static or no) can't enforce."

Bradd wrote:
>> That doesn't make sense: The interpreter is just one tool for testing
>> correctness, and it's not even the most important tool. 

> OK, but the interpreter isn't just a tool to testing for correctness.
> It's the definition of the programming language.

That isn't true. A programming language is a notation for algorithms and
data, a way to describe a machine. The interpreter does not define the
language; it's merely a tool that understands the language well enough
to follow a program's instructions.

If your goal is to follow instructions encoded in a programming
language, an interpreter is a good tool. However, it's not the only way
to process the language. You might want to translate the instructions
into another language that's easier to analyze or interpret. You might
want to reorganize the instructions into a more efficient form. You
might want to analyze the instructions for correctness, maintainability,
robustness, etc.

Interpreters are poorly suited for most of these other tasks. Instead,
you use compilers, optimizers, debuggers, delinters, code reviews, test
suites, and other tools. Some of these tasks require human inspection.

It's unwise to design a programming language such that its interpreter
defines the language. For one thing, that makes interpreter bugs part of
the language definition, which probably isn't what you want. More
importantly, if you restrict the language to what the interpreter
understands, you eliminate constructs that are useful in other tasks,
like human inspection and automated testing.

> 2) And I was shocked that R5RS Scheme has ambiguous semantics (about
>    eval order).  That's perfectly obvious, but I missed it somehow.

The semantics aren't "ambiguous" unless you arbitrary limit the context
to interpreters. That might be reasonable if program interpretation were
the only significant programming task, but it isn't.

> 3) And I decided I like definite semantics, i.e. an algorithm for the
>    interpreter, and even like left->right eval order, for LC reasons.
>    It sounds right up MF's alley: we can reason about an algorithm.

If you do that, you make some tasks easier at the cost of making other
tasks harder.

>    One benefit is that a class of bugs has been eliminated, the
>    moving-target-compiler bug.  It's no longer necessary to prove that
>    your program works for this wide variation of compiler ....

The ability to interpret a program in more than one way is not a bug;
it's a feature. Scheme gives programmers the ability to explicitly state
where sequentiality matters. That makes some tasks easier. It tells
human reviewers and testing tools (like BrBackwards) where to look for
sequentiality bugs. It tells maintainers and optimizers where to look
for re-ordering and re-factoring opportunities. It can make it easier to
implement an interpreter, by giving you the freedom to execute code in a
more convenient order.

It does make certain kinds of program analysis more difficult, but
that's not a bug; it's a cost.

> 5) But I'm not convinced that anyone's made a suggestion that would
>    really improve matters.

First, you should establish that the situation needs improving. Why
would I want to "improve" Scheme when I'm already happy with the ability
to make my sequentiality requirements explicit?
-- 
Bradd W. Szonye
http://www.szonye.com/bradd