[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] strange warning
From: |
Felix |
Subject: |
Re: [Chicken-users] strange warning |
Date: |
Sat, 25 Jun 2011 21:36:43 +0200 (CEST) |
>
> 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