Re: [Chicken-users] handling the undefined value

[F. Wittenberger]

> >> 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?