From: Jörg "F. Wittenberger" <[email protected]> Subject: Re: [Chicken-users] handling the undefined value Date: Mon, 29 Nov 2010 14:21:13 +0100
> Am Samstag, den 27.11.2010, 16:06 +0100 schrieb Felix: >> From: Jörg "F. Wittenberger" <[email protected]> >> Subject: Re: [Chicken-users] handling the undefined value >> Date: Fri, 26 Nov 2010 22:10:46 +0100 >> >> > >> > Well, if it was a compiler switch, off by default, it should not do >> > harm. Would it? >> > >> >> 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. > 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'. >> How about "-picky" ? > > -picky sounds good. Ok. This will probably become a "change request". > > Since -picky would enforce particular programming style(s), I'd suggest > that it would take flags right from the start like -debug does. So I > could enforce "never return/reference undefined", later maybe complain > about letrec binding to something not a procedure (zero reasons to do so > from standard Scheme point of view, but sometimes likely to fix > mistakes). More ideas might come up (which systems do still have a > command line length limit?). 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). cheers, felix _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
