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

Matthias Felleisen matthias at ccs.neu.edu
Mon Feb 26 00:04:56 EST 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





More information about the r6rs-discuss mailing list