3 ms·
> At this point it is pretty clear that calling first on a number is not valid. A quick doc check will show that first is for collections I could just have the
by lispm 7y ago
> At this point it is pretty clear that calling first on a number is not valid. A quick doc check will show that first is for collections
I could just have the compiler explain the problem in the REPL, for example with SBCL:
* (defun foo (n)
(cond ((> n 40) (+ n 20))
((> n 20) (- (first n) 20))
(t 0)))
; in: DEFUN FOO
; (FIRST N)
; ==>
; (CAR N)
;
; caught WARNING:
; Derived type of N is
; (VALUES
; (OR (DOUBLE-FLOAT (20.0d0) 40.0d0) (SINGLE-FLOAT (20.0) 40.0)
; (RATIONAL (20) 40))
; &OPTIONAL),
;
; conflicting with its asserted type
; LIST.
Then there is less need for manually searching for problematic expressions in the code.
See http://sbcl.org http://sbcl.org
- bmn__ 7y agoDid you miss the premise near the beginning of the article? > I am going to throw away all the potentially useful information
- lispm 7y agoFrom the article: > read stacktraces and add instrumentation for tracing. In this blog post I am going to debug his example program without using such tooling, relying only on the rapid feedback loop provided by the REPL One does not need error reporting, stacktraces or add instrumentation, while running the code. SBCL gives the clue without any of that, before (!) the code runs. In the REPL. The incremental compiler makes some of that manually searching for type problems in the code unnecessary, while supporting REPL use.