chicken-users
[Top][All Lists]
Advanced

[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



reply via email to

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