chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] handling the undefined value


From: F. Wittenberger
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" <address@hidden>
> 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.

Not sure that I did get that.

Do you mean that this pattern

(let ((x ...))
  (let loop (...)
    (if ...
        (loop ...))))

in tail position of a procedure would still return one "undefined"
value?

(If the compiler can prove that the result value is never bound, e.g.,
in the middle of a (begin ...), or say the procedure is only locally
visible and it#s result is never used -- then it would be ok.)

In tail position however its not quite be what I need.  -picky should
force me to write:

(let ((x ...))
  (let loop (...)
    (if ...
        (loop ...)))
  x)

Iff I want to ever bind the result anywhere.

> How about "-picky" ?

-picky sounds good.

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

/Jörg




reply via email to

[Prev in Thread] Current Thread [Next in Thread]