How about

1. String::Concatenate

   sub concatenate{ $_[ 0 ] . $_[ 1 ] }
   [download]

2. Algorithm::Numerical::Addition

   sub add{ $_[ 0 ] + $_[ 1 ] }
   [download]

3. Algorithm::Loop

   sub loop (&@) { $_[ 0 ]->( $_ ) for @_ }
   [download]

Ultimately, they can all be ditched in favour of Algorithm::Just.

Synopsis:

#!/usr/bin/perl -w
use strict;
use warnings;
use diagnostics;
use Data::Dumper;
use Fatal;
use IO::All;
use Parse::RecDescent;
use Getopt::Short;
use Getopt::Standard;
use Getopt::Long;
use Config::Standard;
use Pod::Usage;
use DBI;
use Class::DBI;
use Class::MethodMaker;
use Aspect;
use Algorithm::Just;

my $config = Config::Standard->new( @ARGS );
my $program = Algorithm::Just->new( $config );
exit $program->doit( 
    instructions => 'Use what you need' 
);
[download]

Every programming problem solved, all you have to do is configure it right. Of course, now we need another module to save all that typing.

Are you sure about not categorizing these under Acme::Idiomator?

I'd say that you've hit upon one of the few idioms that could be put in a module, and if so, it would make sense to me to put unique in List::Util.

You could always make your own local modules implementations of idioms.

If you know what domain your problem is, you'll often find a module that doesn't do anything by itself but which contains many of the idioms in that domain. Examples include Scalar::Util, List::Util, Language::Functional, etc.

There are just too many such idioms.

There are too many regular expressions, too. But that does not make Regexp::Common a bad idea.

--Solo

--
You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.

What idioms would you put in such a module? Or, put another way, what modules would you include in such a module? :-)

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

I don't think it's a bad idea; just that you can't cleanly separate "idioms" from everything else in CPAN. There *are* idiom libraries out there -- I gave a few examples. But most modules solve practical problems, and solutions carry some inevitable functional (lowercase f) cruft that *is* best kept in a module.

The seminal work in recognizing and applying patterns is Design Patterns, also known as the "Gang of Four" book referring to its four authors: Gamma, E., R. Helm, R. Johnson, and J. Vlissides.

Many apprentice programmers pick up the Gang of Four and are a bit overwhelmed with the concepts introduced at first, but generally start to recognize the appropriate patterns that already exist in application code. This is an important skill to acquire: recognizing idiomatic development in existing projects.

Many journeyman programmers pick up the Gang of Four and try to write a library of code that implements the basic interfaces of each pattern. They quickly get out of their depth, trying to implement a flexible and approachable system which makes writing applications easy, yet doesn't hinder the application from doing obvious special work on top of the basic pattern.

In my observations, so-called master programmers generally don't rely on idiom libraries or pattern classes. They rely on data structures libraries, surely, but idiom is meant to be flexible in ways that libraries can rarely deliver. For example, how do you write a Perl5 library to handle the Schwartzian Transform? Every programmer cuts and pastes this approach, or types from memory, to speed up their critical and complex sorts. But writing a library to handle the obvious alterations would be heavier than the perceived value of having such a library.

Instead, where appropriate, melt the powerful idioms into the language itself: Java absorbs assert(), and Perl 6's sort will do internal optimizations akin to the Schwartzian Transform.

There will always be inappropriate or inconveniently persistent idioms that resist packaging: unique() and slurp() come to mind. Should they be a library? Or should they be one-liners that you can type from memory?

The reason they resist packaging: how do you handle the special cases, the empty lists, the degenerate worst-case work, the nonstandard separators, the already-sorted, the deep data structures? Each time you type these idioms, these issues raise their heads and you adapt your idiomatic solutions to cover them. It's my expectation that those special cases are exactly why they haven't been absorbed into the language already.

++ for a good post.

I too wouldn't care much for a Idioms::Common module, but I sometimes would like to see libraries that performs the function the idiom does, if abstractable.

As I see it, we talk about two different idioms: functional idioms and patterns (the distiction may be a bit fuzzy). Below I will talk about functional idioms only.

I would like to bring up some of your point and elaborate a bit.

For example, how do you write a Perl5 library to handle the Schwartzian Transform? / ... / But writing a library to handle the obvious alterations would be heavier than the perceived value of having such a library.

You raise a good point, but I think you take a too black and white look and the situation. You don't have to write a library to handle any alternation. I realize that ST was just an example, but let's continue on that example. Just a plain ugly ST may do fine in many cases, and then the library version could be used (and it's easy to abstract the vanilla version). Having a library that handles one common way to do ST doesn't stop you from using your own ST.

An example of this is File::Slurp which is one of my favourite modules. It uses plain and simple routines, but often I need those plain and simple routines. When I need something more controlled I do it myself.

Another example is grep, which is a special map.

    grep BLOCK LIST
    map { do BLOCK ? $_ : () } @_ }
[download]

And we agree grep is a good addition to Perl. And like above: I need a more sophisticated grep I use map, but grep is still nice to have for all those cases where I just want a simple grep.

If grep wasn't built-in though, I still would've enjoyed having it ready through a library.

Instead, where appropriate, melt the powerful idioms into the language itself.

Indeed, and this is what Perl 6 is about, partly. But in the mean-time, I don't see any wrong in abstracting abstractable idioms into libraries. But there's also another side to it. Some idioms may be appropriate for you to melt into the language, but someone else might want another set of idioms into the language. The Perl 6 RFCs shows good examples of this. Or perhaps I'm twisting the meaning of idiom now and if something isn't overall applyable, then perhaps it isn't an idiom after all.

There will always be inappropriate or inconveniently persistent idioms that resist packaging: unique() and slurp() come to mind. Should they be a library? Or should they be one-liners that you can type from memory?

As it turns out, slurp() is available as &File::Slurp::read_file. It's not written idiomatic, and I'm in fact not arguing with your main point. This has nothing to do with idioms, and as I said at the very top: I don't see any reason to put the idiom in a library, but the function the idiom does.

In my observations, so-called master programmers generally don't rely on idiom libraries or pattern classes.

I believe there are a couple of factors for that:

• False laziness: they can do it them selves and it doesn't take much time each time (but summed up it's a lot) whereas it'll take a while to understand and get started with the library/pattern class.
• Don't agree with the pattern: They want a different way to do the same thing, and everyone has their own idea of how to do it. Since Perl lets you do things your way, they do it their way.
• Experimental: Many pattern classes are experimental and give the feeling of proof-of-concept modules rather than something to be used in production.
• Dependancy: You don't want to depend on something experimental for your productions.
Now, if we were to write a rigid actively maintained module and managed to make it almost a part of the language (like CGI.pm is for Perl CGI programming), I think things can work out well.

Just my thoughts,
ihb

Read argumentation in its context!

I keep hearing about the tons of idioms, but i can seem to think of many. I put together a small list that i know is incomplete.

Idioms:
Tye + Juerd in id=204874
sub slurp {  local( *ARGV, $/ ); @ARGV = shift; <> };

dragonchild id=376694
sub unique { my %x; grep { !$x{$_}++ } @_ }

broquaint id=374287
sub in_list {return !!grep { $_ eq $_[0] } @_[ 1 .. $#_ ];}
[download]

These represent in no way a complete list, they are just a collection of idioms I found while searching perlmonks. Could we start a list or a document that would hold perl idioms and maybe a short explanation of them? If you wanna help just add it as a reply here or should i start a meditation on the matter? Well for now reply here, I can always post a revised list to meditation for comment/correction and addition.


___________
Eric Hodges

I agree with you, but you got me thinking. How about this:

#usage: @result = st_complex sub { complex comparison }, sub { transfo
+rm }, LIST 
sub st_complex (&&@) {
    my $compare = shift;
    my $transform = shift;
    map { $_->[-1] }
    sort $compare
    map { [ $transform->(), $_ ] } @_;
}

#usage: @result = st_simple sub { transform }, LIST 
#note: comparison is string wise.
sub st_simple (&@) {
    my $transform = shift;
    &st_complex(sub { $a->[0] cmp $b->[0] }, $transform, @_);
}
[download]

The only shortcomings I can find are that sub NAME (&&@) won't allow you to call NAME { CODE } { CODE } LIST, only the first code block can be a bare block, and I can't thing of an effective way to combine the two into a single function like sort.

I thought about this too, when writing my reply to Re: CPAN module fior common idioms?. But I did three distict different design choices. My sort call looks like this:

    my @foo = qw/
        a3
        b2
        r4
        s1
    /;

    print for STsort(
        sub { /(\d+)$/ },
        sub { $_[0][1] <=> $_[1][1] },
        @foo
    );

    __END__
    s1
    b2
    a3
    r4
[download]

The differences are:
• Order of the subs: I feel it's more natural to first see the transformation and then how that transformation should be sorted, as the sort sub means nothing if you haven't seen the transformation sub. An inlined ST is read backwards.
• $_[0] instead of $a: &STsort can't, without voodoo AFAIK, in every case realize which $a and $b to use.
• Original at index 0: I put the original value at the beginning of the array instead of at the end. I feel this is nicer when I don't know the length of the result of the transformation.

ihb

Read argumentation in its context!

Brilliantly stated++

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

There's Effective Perl Programming

Only slightly dated, but chock full if idioms. I'd love to hear if it has anything in it that's fallen out of favor, or might be considered harmful.

Edit: s/Efficient/Effective/ -- Um, right. Sorry. I swear a google search on efficient turned up that exact title. I always get that wrong. :)

There's Efficient Perl Programming

Or even Effective Perl Programming, if you're talking about the book that Joseph Hall did, with a little help from me.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

If there's a bunch of neat snippets in a book, why aren't those snippets in some set of CPAN modules? That's my point.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Er, because it's such a good idea and so useful, that they'd be crazy not to publish it instead of giving it away for free?

Seriously though, you're right, it would be very nice to have such a CPAN entry. I mentioned it mostly for those who didn't know about it since it is such a good read.