[r6rs-discuss] Re: Allow compilers to reject obvious violations

From: Matthias Felleisen <matthias>
Date: Mon Feb 26 00:05:01 2007

On Feb 25, 2007, at 11:50 PM, Will Clinger wrote:

> If we accept that the criterion for rejecting a program
> should be the same in all implementations, then the
> criteria should be decidable. In my opinion, criteria
> that are supposed to be the same in all implementations
> should also be simple; otherwise it is hard to reason
> about the criteria, which seems like the main benefit
> we could hope to achieve by requiring the criteria to
> be the same. (I am discounting portability somewhat,
> because absolute portability is a lost cause in the
> presence of low-level macros.)


Ah, your true face is coming through.

 From what I can tell, you want a language report for compiler
writers. Put differently, you want a rough outline of a language,
with lots of freedom to implement whatever is easy or interesting,
depending on the inclinations of the compiler writer. (Okay, perhaps
"rough" is unfair, but my English is poor.)

If I were a consumer/user/Scheme programmer, I'd hate that. I would
want to make sure that

1. The specification of the semantics is the same for as much as
possible so that I can port programs. Ideally it should be simple, too.

2. The specification of the static semantics is decidable and
decipherable on a couple of pages (at most). That's why it's Scheme,
not ML. That way I am not surprised when I take a program from one
implementation to another. See the post on ((lambda () ...) (k 22)).

Indeed, if 2 held, we could post a front-end at schemers.org and
check our programs just to make sure.

3. And I would then develop where it's easy to develop and run where
it's fast, with two or three or four eyes on those cases where the
Reporters say that implementations may implement different behaviors.

Seems like Scheme programmers -- as opposed to compiler writers --
are about to get neglected one more time. Oh well. -- Matthias
Received on Mon Feb 26 2007 - 00:04:56 UTC

This archive was generated by hypermail 2.3.0 : Wed Oct 23 2024 - 09:15:01 UTC