strictness of unused arguments

[Roman Beslik]

Thanks for the answer. Sorry, I can not follow all of your thoughts 
because my knowledge of strictness analysis and GHC optimizations are 
very basic. :( I looked into GHC code once several years ago. BTW there 
are a lot of papers about strictness analysis, but I do not know which 
is relevant for GHC. Can you suggest something?

On 11.03.10 23:33, Max Bolingbroke wrote:
> On 11 March 2010 12:50, Roman Beslik<beroal at ukr.net>  wrote:
>    
>> I also can force the analyzer to think that "x1" and "x0" are strict by
>> eta-expanding "f3":
>>      
> There seem to be two issues here.
>
> 1) GHC only figures out and records strictness information on lambdas
> that are syntactically together. I'm not sure how hard it would be to
> change this, but probably not totally straightforward
>    
So GHC records strictness information for lambda-abstractions, not for 
function types? Eta-expansion changes strictness because it adds 
lambda-abstractions.
> 2) GHC does not seem to be eta-expanding as much as it could get away
> with. Generally eta expansion has the following effects
>    
I think it is better to go without eta-expansion. Eta-expansion (if not 
optimized when compiled) do absolutely useless job. I discovered its 
effect by an accident.
> Out of curiosity, did you spot this in a real program?
>    
It may be a real program. :) From the higher-level point of view: A list 
of Int-s is replaced by seed+coalgebra and a coalgebra is an automaton. 
The program generates lists and folds them, or in other words the 
program is a sequence of automata which feeds each other. The special 
feature is that states of all automata lay in stack, the program *does 
not allocate in the heap*. Of course, if it uses boxed Int-s, the very 
goal is missed. :( However, for now I can compose automata only by hand 
:( , I did not figured out a (.) function.

-- 
Best regards,
   Roman Beslik.