> >> Yes, I'll do that. I could also least remove the warning for the > >> (common) case of a conditional performing a self-tailcall. > > > > Do you mean that this pattern > > > > (let ((x ...)) > > (let loop (...) > > (if ... > > (loop ...)))) > > > > in tail position of a procedure would still return one "undefined" > > value? > > Yes, it would. This particular case is detected now, though.
good > > In tail position however its not quite be what I need. -picky should > > force me to write: > > > > (let ((x ...)) > > (let loop (...) > > (if ... > > (loop ...))) > > x) > > You get loops like the above in internal code, like the expansion > of the (internal) compiler macro for `for-each'. But only in tail position. And that's where I want to catch them given -picky anyway. > Control over warnings has been requested already. I have to think more about > this, since it would be nice to keep things simple, yet provide some sort > of control over warnings (both statically and dynamically). How about a warnings database? Pseudo code (define-syntax chicken-warning (syntax-rules () ((_ number comment-text argument ...) (complain (lookup number comment-text) arguments ...)))) Double check consistency: "comment-text" is supposed to explain the warning's meaning to the compiler source editor. The lookup will use "number" to find the message, check that (equal? comment-text db-comment). "number" is strictly increasing, allocated during development. Any kind of "ignore those" logic could be distributed as a database. Might take some more seconds to structure the database, than given here so far. comments? _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
