3 ms·

> Type declarations in Common Lisp support (safety <n>) and (speed <n>) syntax To be pedantic, those aren't type declarations. More importantly, the (un)safety

> Type declarations in Common Lisp support (safety <n>) and (speed <n>) syntax To be pedantic, those aren't type declarations. More importantly, the (un)safety of a type declaration isn't predicated on any specific safety/speed settings. The mere use of a type declaration implies that the programmer certifies their accuracy inside its scope; an additional optimize declaration is not required. It bears repeating: While Common Lisp has "type declarations", they don't behave as they do in statically typed languages. The are certificates, assurances by the programmer to be exploited at will by the implementation.

lispm 8y ago
> To be pedantic, those aren't type declarations. They are values of optimization qualities and guide the compiler strategy. > More importantly, the (un)safety of type declaration isn't predicated on any specific safety/speed settings. The mere use of a type declaration implies that the programmer certifies their accuracy inside its scope; With an optimize quality 3 for SAFETY a compiler will not reduce safety, even though there are type declarations. The Common Lisp standard REQUIRES that safety at 3 causes 'safe code': http://www.lispworks.com/documentation/HyperSpec/Body/03_eaa.htm http://www.lispworks.com/documentation/HyperSpec/Body/03_eaa... Which usually means full runtime checks in interpreted and compiled code, calls, system calls, ... > an additional optimize declaration is not required. Sure you need to have the right compiler qualities set to see those effects of your type declarations. LispWorks: CL-USER 4 > (proclaim '(optimize (safety 3))) NIL CL-USER 5 > (defun foo (x) (declare (string x)) (+ x 2)) FOO CL-USER 6 > (compile 'foo) FOO NIL NIL CL-USER 7 > (foo 'bar) Error: In + of (BAR 2) arguments should be of type NUMBER. 1 (continue) Return a value to use. 2 Supply a new first argument. 3 (abort) Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 8 : 1 > Oh, the LispWorks compiler has ignored the type declaration at safety 3. The runtime checks are still there. The code has the same safety as without a type declaration.
- YouAreGreat 8y ago
  Violation of a type declaration is UB in safe code. SBCL obviously makes use of that fact when inserting assertions.
  - kazinator 8y ago
    Undefined behavior gives the implementation the freedom to insert any behavior whatsoever (like the proverbial demons flying out of the nose). An assertion isn't any behavior, it is a form of run-time error checking. Run-time error checking is what the "safety" optimization option means! From CLHS: Name Meaning compilation-speed speed of the compilation process debug ease of debugging safety run-time error checking space both code size and run-time space speed speed of the object code (optimize (safety 3)) means "greatest possible run-time error checking". Why wouldn't the implementation insert error checking based on the user's type declaration, when asked to provide the greatest possible run-time error checking?
    - YouAreGreat 8y ago
      > An assertion isn't any behavior It is. For example, a failed assertion inhibits effects that should have occurred before the "actual" type error happens. The only reason SBCL is able to insert assertions into safe code without giving up conforming implementation status is that, as you say, UB allows anything, and violating a declaration is UB even in safe code.
      - kazinator 8y ago
        There isn't necessarily an actual type error! Remember, the declaration provided by the user can be an inaccurate estimate of what the real type constraint is at that program node. The program might in fact require a string there, but the programmer's declaration says integer. So the assertion goes off when a string value occurs, when that would in fact correct in the absence of the declaration. This alteration of behavior by the assertion is not an arbitrary choice of behavior; it is a diagnostic behavior, in line with the diagnostic meaning of safety. ANSI CL does literally say under "Declarations" that "The consequences are undefined if a program violates a declaration or a proclamation". Yet, it's not reasonable to allow any behavior whatsoever if a type declaration is violated by a run-time situation, in safe code. It just makes no sense at all to allow a crash, or random bits being silently flipped, etc. Given that safe code, in the absence of declarations, catches type errors; why would declarations regress from that, in safe code.

lispm 8y ago

> To be pedantic, those aren't type declarations. They are values of optimization qualities and guide the compiler strategy. > More importantly, the (un)safety of type declaration isn't predicated on any specific safety/speed settings. The mere use of a type declaration implies that the programmer certifies their accuracy inside its scope; With an optimize quality 3 for SAFETY a compiler will not reduce safety, even though there are type declarations. The Common Lisp standard REQUIRES that safety at 3 causes 'safe code': http://www.lispworks.com/documentation/HyperSpec/Body/03_eaa.htm http://www.lispworks.com/documentation/HyperSpec/Body/03_eaa... Which usually means full runtime checks in interpreted and compiled code, calls, system calls, ... > an additional optimize declaration is not required. Sure you need to have the right compiler qualities set to see those effects of your type declarations. LispWorks: CL-USER 4 > (proclaim '(optimize (safety 3))) NIL CL-USER 5 > (defun foo (x) (declare (string x)) (+ x 2)) FOO CL-USER 6 > (compile 'foo) FOO NIL NIL CL-USER 7 > (foo 'bar) Error: In + of (BAR 2) arguments should be of type NUMBER. 1 (continue) Return a value to use. 2 Supply a new first argument. 3 (abort) Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 8 : 1 > Oh, the LispWorks compiler has ignored the type declaration at safety 3. The runtime checks are still there. The code has the same safety as without a type declaration.

YouAreGreat 8y ago
Violation of a type declaration is UB in safe code. SBCL obviously makes use of that fact when inserting assertions.
- kazinator 8y ago
  Undefined behavior gives the implementation the freedom to insert any behavior whatsoever (like the proverbial demons flying out of the nose). An assertion isn't any behavior, it is a form of run-time error checking. Run-time error checking is what the "safety" optimization option means! From CLHS: Name Meaning compilation-speed speed of the compilation process debug ease of debugging safety run-time error checking space both code size and run-time space speed speed of the object code (optimize (safety 3)) means "greatest possible run-time error checking". Why wouldn't the implementation insert error checking based on the user's type declaration, when asked to provide the greatest possible run-time error checking?
  - YouAreGreat 8y ago
    > An assertion isn't any behavior It is. For example, a failed assertion inhibits effects that should have occurred before the "actual" type error happens. The only reason SBCL is able to insert assertions into safe code without giving up conforming implementation status is that, as you say, UB allows anything, and violating a declaration is UB even in safe code.
    - kazinator 8y ago
      There isn't necessarily an actual type error! Remember, the declaration provided by the user can be an inaccurate estimate of what the real type constraint is at that program node. The program might in fact require a string there, but the programmer's declaration says integer. So the assertion goes off when a string value occurs, when that would in fact correct in the absence of the declaration. This alteration of behavior by the assertion is not an arbitrary choice of behavior; it is a diagnostic behavior, in line with the diagnostic meaning of safety. ANSI CL does literally say under "Declarations" that "The consequences are undefined if a program violates a declaration or a proclamation". Yet, it's not reasonable to allow any behavior whatsoever if a type declaration is violated by a run-time situation, in safe code. It just makes no sense at all to allow a crash, or random bits being silently flipped, etc. Given that safe code, in the absence of declarations, catches type errors; why would declarations regress from that, in safe code.