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
incorrect?"
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
--
Pascal Costanza, mailto:[EMAIL PROTECTED], http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
