Tomasz Zielonka | 17 Jan 09:04 2005
Picon

Re: cvs commit: fptools/libraries/base package.conf.in fptools/libraries/base/Data IntMap.hs IntSet.hs Map.hs FiniteMap.hs Set.hs

On Mon, Jan 17, 2005 at 08:38:12AM +0100, Ketil Malde wrote:
> Sven Panne <Sven.Panne <at> aedion.de> writes:
> 
> > I must admit that I didn't follow the data structure discussion in every
> > detail, but I find something confusing: In Data.FiniteMap.addListToFM_C,
> > the combining function gets the old value as the 1st argument and the new
> > value as the 2nd one. In Data.Map.insertWithKey (and friends), this seems
> > to be the other way round, which is undocumented and *very* confusing when
> > trying to port things from FiniteMap to Map. Is there a deep reason for this?
> 
> Hmmm...I have perhaps a rather shallow reason.  When using a FiniteMap
> to collect lists of values, I think it will be more efficient to use
> (flip (++)), prepending instead of appending each new element. 

If (flip (++)) is efficient for one interface, shouldn't (++) be as efficient
for the other?

Why not use efficient catenable sequences or a ShowS trick, like here:

    groupFM :: Ord a => [(a, b)] -> FiniteMap a [b]
    groupFM l =
        mapFM (\_ -> ($ [])) $
            addListToFM_C (.) emptyFM [ (a, (b:)) | (a, b) <- l ]

PS. If anyone asks, I am strongly against introducing such artificial
    differences in library interfaces.

Best regards,
Tomasz
(Continue reading)

Ketil Malde | 17 Jan 09:48 2005
Picon
Picon

Re: cvs commit: fptools/libraries/base package.conf.in fptools/libraries/base/Data IntMap.hs IntSet.hs Map.hs FiniteMap.hs Set.hs

Tomasz Zielonka <tomasz.zielonka <at> gmail.com> writes:

>> Hmmm...I have perhaps a rather shallow reason.  When using a FiniteMap
>> to collect lists of values, I think it will be more efficient to use
>> (flip (++)), prepending instead of appending each new element. 

> If (flip (++)) is efficient for one interface, shouldn't (++) be as efficient
> for the other?

Yes.  Sorry if that wasn't clear; my point was that the new interface
saves you the 'flip' -- or alternatively, the naive user not
considering these issues will likely just use (++), which may be more
efficient for the new interface. 

> Why not use efficient catenable sequences or a ShowS trick, like here:

>     groupFM :: Ord a => [(a, b)] -> FiniteMap a [b]
>     groupFM l =
>         mapFM (\_ -> ($ [])) $
>             addListToFM_C (.) emptyFM [ (a, (b:)) | (a, b) <- l ]

Because it is more complex?  It's a neat trick, but it does takes me a
minute or two to see what's going on.  Perhaps groupFM should be part
of (Finite)Map?

-kzm
--

-- 
If I haven't seen further, it is by standing in the footprints of giants
Simon Marlow | 17 Jan 11:30 2005
Picon

RE: cvs commit: fptools/ghc/compiler/cmm CLabel.hs fptools/ghc/compiler/nativeGen AsmCodeGen.lhs MachInstrs.hs PositionIndependentCode.hs PprMach.hs RegAllocInfo.hs

On 16 January 2005 05:32, Wolfgang Thaller wrote:

>   b) A volunteer to improve the NCG to the point where it can compile
>      the RTS (so we won't need point a).

I'll add a task to the task list for this one.  It's a good project for
someone with back-end knowledge.  Basically it amounts to extending the
NCG with support for loops, and I think most of the work would be in the
register allocator.  It doesn't need to do a fantastic job, just a
half-decent one.

Cheers,
	Simon
Ketil Malde | 17 Jan 09:48 2005
Picon
Picon

Re: cvs commit: fptools/libraries/base package.conf.in fptools/libraries/base/Data IntMap.hs IntSet.hs Map.hs FiniteMap.hs Set.hs

Tomasz Zielonka <tomasz.zielonka <at> gmail.com> writes:

>> Hmmm...I have perhaps a rather shallow reason.  When using a FiniteMap
>> to collect lists of values, I think it will be more efficient to use
>> (flip (++)), prepending instead of appending each new element. 

> If (flip (++)) is efficient for one interface, shouldn't (++) be as efficient
> for the other?

Yes.  Sorry if that wasn't clear; my point was that the new interface
saves you the 'flip' -- or alternatively, the naive user not
considering these issues will likely just use (++), which may be more
efficient for the new interface. 

> Why not use efficient catenable sequences or a ShowS trick, like here:

>     groupFM :: Ord a => [(a, b)] -> FiniteMap a [b]
>     groupFM l =
>         mapFM (\_ -> ($ [])) $
>             addListToFM_C (.) emptyFM [ (a, (b:)) | (a, b) <- l ]

Because it is more complex?  It's a neat trick, but it does takes me a
minute or two to see what's going on.  Perhaps groupFM should be part
of (Finite)Map?

-kzm
--

-- 
If I haven't seen further, it is by standing in the footprints of giants

Gmane