Re: Another rule guestion.

1999-06-30 Thread Kevin Atkinson

Simon Peyton-Jones wrote:

 The way it is now, ONE rule, the fold/build rule
 deals with fusion.  The others are all there to express things
 in terms of fold and build, AND THEN to return certain common
 patterns of usage for foldr to their familiar mapList and filterList
 forms.
 
 Does that help?

Tremendously.  I was thinking that those rules were there becuase the
rule "map f (map g xs) = map (f.g) xs" would simply not work.  Now back
to my orignal question:

Why doesn't my "replaceMany (map f l) a = replaceManyMap f l" rule--as
shown in the previous email titled "Rule Question"--behave as expected.

-- 
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/



RE: Another rule guestion.

1999-06-30 Thread Simon Peyton-Jones

For someone who couldn't make head of tail of it, you are spot on.
That's just the way it works.

You ask why not have a rule for 
map f (map g xs) = map (f.g) xs

Because then we'd need one for 
map f (filter g xs)
and one for
map f (take n xs)
and so on and so on and so on.  

The way it is now, ONE rule, the fold/build rule
deals with fusion.  The others are all there to express things
in terms of fold and build, AND THEN to return certain common
patterns of usage for foldr to their familiar mapList and filterList
forms. 

Does that help?

Simon


 -Original Message-
 From: Kevin Atkinson 
 Sent: Tuesday, June 29, 1999 8:34 PM
 To: [EMAIL PROTECTED]
 Subject: Another rule guestion.
 
 
 I was looking through PrelBase.lhs and I can not make head or 
 tails out
 of the point in all the run around with build, mapFB, etc. is.
 
 As I see it the simplification of  "(map f. map g) l" would go as
 follows:
 
 (map f . map g) xs
 
 map f (map g xs)
 
 build$ \c n - foldr (mapFB c f) n (map g xs)
 
 build$ \c n - foldr (mapFB c f) n 
 (build$ \c n - foldr (mapFB c g) n xs)
 
 --with rule: foldr k z (build g) = g k z
 
 build$ \c n - 
   (\c n - foldr (mapFB c g) n xs) (mapFB c f) n
 
 build$ \c n - foldr (mapFB (mapFB c f) g) n xs
 
 -- with rule: mapFB (mapFB c f) g = mapFB c (f.g)
 
 build$ \c n - foldr (mapFB c (f.g)) n xs
 
 (\c n - foldr (mapFB c (f.g)) n xs) (:) []
 
 foldr (mapFB (:) (f.g)) [] xs
 
 -- with rule: foldr (mapFB (:) f) [] = mapList f
 
 mapList (f.g) xs
 
 which seams like a hell of a lot of work when the rule "map f 
 (map g xs)
 = map (f.g) xs" should do the trick.
 
 I am sure all this run-around is here for a good reason, but 
 what is it?
 I am also sure that understanding what all this run-around does is the
 key to understanding why the rule "replaceMany (map f l) a =
 replaceManyMap f l" is not behaving as expected.
 
 Thanks in advance for any help with this.  I can see how the rule
 rewriting mechanism can be very powerful; however, it is not 
 very useful
 if I can't figure out how it works...
 -- 
 Kevin Atkinson
 [EMAIL PROTECTED]
 http://metalab.unc.edu/kevina/
 



Another rule guestion.

1999-06-29 Thread Kevin Atkinson

I was looking through PrelBase.lhs and I can not make head or tails out
of the point in all the run around with build, mapFB, etc. is.

As I see it the simplification of  "(map f. map g) l" would go as
follows:

(map f . map g) xs

map f (map g xs)

build$ \c n - foldr (mapFB c f) n (map g xs)

build$ \c n - foldr (mapFB c f) n 
(build$ \c n - foldr (mapFB c g) n xs)

--with rule: foldr k z (build g) = g k z

build$ \c n - 
  (\c n - foldr (mapFB c g) n xs) (mapFB c f) n

build$ \c n - foldr (mapFB (mapFB c f) g) n xs

-- with rule: mapFB (mapFB c f) g = mapFB c (f.g)

build$ \c n - foldr (mapFB c (f.g)) n xs

(\c n - foldr (mapFB c (f.g)) n xs) (:) []

foldr (mapFB (:) (f.g)) [] xs

-- with rule: foldr (mapFB (:) f) [] = mapList f

mapList (f.g) xs

which seams like a hell of a lot of work when the rule "map f (map g xs)
= map (f.g) xs" should do the trick.

I am sure all this run-around is here for a good reason, but what is it?
I am also sure that understanding what all this run-around does is the
key to understanding why the rule "replaceMany (map f l) a =
replaceManyMap f l" is not behaving as expected.

Thanks in advance for any help with this.  I can see how the rule
rewriting mechanism can be very powerful; however, it is not very useful
if I can't figure out how it works...
-- 
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/