> > 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.
Yes, I understand. I had a similar case before. Unfortunately optimizations make this very hard. > > > 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? Some macros simply expand into such code, like anaphoric conditionals or "and-let*". Or do you mean something else with this question? > * 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). Can you give an example of this? > > 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. True. And it would be so easy to optimize. Noted. > 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. You won't even notice. > 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. Chances are that you wouldn't even notice that. But if you show me your trickery and what you want as the result, I can help you to achieve that. > > There is just one hope left: chicken is fast enough that way too. Of course it is. You can go to sleep relaxed. cheers, felix _______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
