Re: [Chicken-users] strange warning

[Jörg F . Wittenberger]

On Jun 24 2011, Felix wrote:

> > I just upgraded to the chicken trunk from version 4.6.5.
> >
> > Now I get a can full of warnings like:
> >
> > Warning: (in k9353) constant-folding expression results in error: "bad
> > argument type - not a proper list": (reverse (quote #f))
> >
> > Warning: (in k9436) constant-folding expression results in error: "bad
> > argument type - not a proper list": (reverse (quote #f))
> >
> > Warning: (in k10634) constant-folding expression results in error:
> > "bad argument type - not a proper list": (reverse (quote #f))
> >
> >
> > I don't like it when compiling my code gives warnings, if you see what
> > I mean.
> >
> > So how would I get rid of them?  (No tricks, I want to track the case
> > down,
> > no "csc prog.scm 2>/dev/null"-equivalents please. ;-)
>
> These warnings indicate that optimizations transform your code in such
> a way (through inlining for example), that some execution paths contain
> calls to procedures with arguments evaluated at compile-time. It would be
> interesting to see where this occurs. If you are interested, compile
> with "-debug 7" and wade through the thicket of CPS calls.
>
> If this gets too annoying I might throw the warning out again. Currently
> it hasn't been overly helpful.

Not overly helpful - agreed.  ;-)

Simply throwing it out, that would be the '''"csc prog.scm 
2>/dev/null"-equivalent''' I meant to rule out beforehand.

It looks to me as if my first intuition was correct: the macro trickery of 
mine caused the warning. (No magic: about a Schock full [Schock: German, 
60] of source files, not even a hand full of files generating warnings. 
Just those with the same macro trick, which produced warnings before.)



What would have been overly helpful (for me learning about the warning
at the first place): if there was a better trace back to the origin
expression.  I had to spot the 'guilty' macro definition using binary search
withing about 4x60k of source code.


Moreover as you mentioned later on:
> where some bindings are statically known to be true,
> but still the runtime code contains tests.

Why does it?

So since the details are not too interesting, let me give a recipe
to produce those and-let*-type of code:


* There is a procedure "A" taking N arguments.

* I want to be alerted of missue on compile time.

- Therefore I define some syntax "call-A" which will do some argument 
checks
  and dispatch.
 (I my case just a simple dispatch on the second argument, which either
  a symbol known to the syntax expander or any other symbol or a string.)

- Expand the syntax to some very low level code for the known symbols.

- Call "A" with pre-checked arguments. (Case 3)

- Handle the case that the whole syntax is expanded with the dispatcher
  parameter (the second in my case) passed as statically unknown type.
  (Which will expand into case 3 above.)


The idea of the whole (pretty messy) trickery was to try to expand as
much as statically known before the compiler generates any code for
facts statically known to the programmer but not encoded in the programm
(and furthermore create a hook where I could attach more compiletime
checks in the future).

So at least one thing I learned so far: I failed.  As and-let* does.

:-(  Whatever I do, the compiler will generate runtime code for statically
knwon facts.

:-(

;->

Too bad that I used this trickery to try to speed up some heavily used
idiom, which is subject to experiments based on the dispatch wrt. this
second argument.  Now I see that I better expect a higher constant
execution time per invocation due to the needless check.

Unfortunately I did start (and stop because of those warnings a 'la
"expected value of type boolean in conditional but were given a value"
pretty soon, though long ago) to optimise those spots, which are
used recursively in multiple dimensions.

So, I don't know what this runtime expanded code is.  But the code
I expected the syntax to produce would be something as simple a "##sys#slot"
.  I don't dare to imagine whats going to happen to the execution time
of my programms when there really is some pointless check I carefully
failed to prevent.

There is just one hope left: chicken is fast enough that way too.

good night

/Jörg

> > The warning by itself is not very helpful. But maybe it's related to a
> > long standing warning I keep getting? (which I happen to accept as the
> > cost of macro trickery of mine):
> >
> > Warning: in local unknown procedure,
> >  in toplevel procedure `dispatch#make-askemos-public-user':
> >  expected value of type boolean in conditional but were given a value
> >  of
> > type `list' which is always true:
>
> This is usually not too critical and appears for example in code that
> uses "and-let*", where some bindings are statically known to be true,
> but still the runtime code contains tests.
>
>
> cheers,
> f