first, a suggestion - why don't you put around your end result map, so we can easily chain multimaps.

In part because I didn't think of doing that. But now you've made me think about it, I think that I would leave it as it is. Adding it internally would make the user that wants the the list rather than a LoL have to wrap the call in @{ multimap [ ... ] } to get at it.

As is, to get the LoL, you do [ multimap [ ...] ].

In the former I would be creating a list only for the user to discard it. In the latter, he creates it if he needs it. Which I think is a good reason to leave it as is?

'multimap' may not be the best name for that function..

I just went with the OPs name, but I agree that it may not best capture the semantics. I'd favour something shorter. 'map' is well understood in Perl circles so I think that should be in there somewhere.

• 'mmap' -- sounds like a memory thing.
• 'mapn' -- I have one called that that passes n elements at a time from a single list
• 'maps' -- Hmm.Not quite.
• 'mapreduce' -- A Southern Mother's ill-feelings?
• Shame we can't use single quotes in function names like Haskell -- map'm -- Too cute?
• 'mapm'?
• 'mapall'?
• 'decons' or should that be 'discons'?
• 'heads' -- Kinda fits, but ...?

What is Data::Dumper::SLC?

It's my Just_a_Dumper dumper. No attempt at making the output evallable. No attempt to fold self-referrencial structures (though it does economically detect and flag them). It streams on-the-fly (avoiding accumlating anything in memory) to STDOUT (or an option filehandle) and wraps at 80 or a specifyable limit. It writes as compact a representation as is comensurate with being readable.

When I asked here if anyone knew of such an animal, the basic respose was that nobody except myself ever needed such a thing, so I never got around to documenting or packaging it.