[r6rs-discuss] [Formal] Allow compilers to reject obvious
pc at p-cos.net
Mon Feb 26 17:31:10 EST 2007
On 26 Feb 2007, at 21:39, Arthur A. Gleckler wrote:
> On Feb 26, 2007, at 11:48 AM, Pascal Costanza wrote:
>> By your accounting, I am in that list. I don't regard myself in
>> that list, so I am sorry if I have given the wrong impression
>> here. I'll try to clarify: Implementations should be given
>> discretion to both run parts of programs even if other parts
>> appear to be incorrect, as well as to completely reject running
>> programs that are provably incorrect. I regard this a quality
>> feature of an implementation, and it should be left to the
>> "market" which approach "wins." It shouldn't be part of a language
>> specification, IMHO.
> Just to be clear, do you mean "...as well as to completely reject
> running [entire] programs that [contain parts that] are provably
Yes. I don't like that personally, but I understand that other people
want that, and who am I to tell them they're wrong.
> That's the distinction I'm worried about.
> I don't mind if this program can't run:
> I just want to be able to test FACTORIAL in this program without
> having to fix FOO:
> (define (factorial n) (if (< n 2) 1 (* n (factorial (- n 1)))))
> (define (foo) (factorial))
> Of course, this is a contrived example. This problem only becomes
> important when FOO is a large body of code, not just a one-liner.
If I use the WonderScheme implementation that forces me to fix each
and every part that it can prove wrong before I am allowed to execute
anything, and I don't like that, I will just switch to the
SuperScheme implementation that focuses on giving me a pleasing
interactive development environment that even attempts to execute
syntactically erroneous programs. Other people who need more bondage
& discipline can just continue to use WonderScheme.
That's what I mean with leaving it to the market. A language
specification shouldn't proscribe either one option or the other.
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium
More information about the r6rs-discuss