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<ber...@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.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
