"Scott L. Burson" Scott@sympoiesis.com writes:
On Thu, Apr 24, 2014 at 7:29 PM, Steve Haflich shaflich@gmail.com wrote:
Take for example aref, which might be used to extract octets of characters or whatever from a buffer. aref makes no guarantees even in safe code that it will signal bad array bounds.
I've long thought that was an oversight, though now that you point it out, I realize I must have been mistaken.
Still, it surprises me. I don't know of any implementation that doesn't bounds-check aref under normal speed/safety settings, and clearly, users expect them to do so. It seems a little pedantic to insist that the _language_ isn't safe in this respect even when all known implementations are. (Am I wrong about that?)
The point is that ANSI Common Lisp compiler writers will have their compilers generate run-time bound checking code, while ANSI C compiler writters won't.
The point is that ANSI Common Lisp compiler writers will add extensions to the language or "standard library" to deal with sockets and network communications, while ANSI C compiler writers won't (relaying on library and OS API writers to do so).
The point is that ANSI Common Lisp compiler writers don't need to add exception handling as an extension because it's already specified in the language, while ANSI C compiler writers would have to do so, to deal non-trivially with run-time errors.
And for the record I disagree with the committee's decision. Bounds checking aref etc. _should_ be required at safety 3 (and along with that, there should be a standardized bounds-error condition type). The reasoning behind the committee's choice here eludes me.
Agreed, a programming language standard should not rely on the good sense of implementers to ensure the semantics of its programs, the more so in a dynamic language where code can be executed without being previously globally validated.
But again, AIUI, Common Lisp was specified as much as it was documenting the commonality in existing implementations, so that may explain why there are so many parts that are unspecified or implementation dependant.