Beefy Boxes and Bandwidth Generously Provided by pair Networks vroom
Perl Monk, Perl Meditation
 
PerlMonks  

CPAN module fior common idioms?

by dragonchild (Archbishop)
on Jul 22, 2004 at 19:31 UTC ( #376694=perlquestion: print w/ replies, xml ) Need Help??
dragonchild has asked for the wisdom of the Perl Monks concerning the following question:

There are a lot of common idioms that are useful in a lot of places. Things like
sub unique { my %x; grep { !$x{$_}++ } @_ }

But, I hate cut'n'pasting that everywhere! Is there a module, say, Idioms::Common that would just encapsulate these for me that I could install and not worry about?

------
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

Comment on CPAN module fior common idioms?
Download Code
Re: CPAN module fior common idioms?
by gaal (Parson) on Jul 22, 2004 at 19:42 UTC
    There are just too many such 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.
Re: CPAN module fior common idioms?
by pbeckingham (Parson) on Jul 22, 2004 at 19:52 UTC

    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.

Re: CPAN module fior common idioms?
by dcvr69 (Beadle) on Jul 22, 2004 at 20:15 UTC

    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. :)

      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.

Re: CPAN module fior common idioms?
by Wassercrats on Jul 22, 2004 at 21:52 UTC
      If you get your way? We're just waiting for you to build it, Wassercrats.

      To gaal's point, I'm not saying Idioms::Common is a good idea. I'm questioning your assertion that it's a bad idea because there are too many idioms. It may be a bad idea for yet other reasons. I wasn't making that judgement =)

      My initial reaction to the idea was, "Finally, someone's going to clean up all those nested maps and greps!" If a module can do some of that, I'm delighted with it. Not because I can't (eventually) decipher them, but because I don't want to most of the time.

      What idioms would I include? Ironically, I have no examples with map or grep...

      sub retcon { return wantarray ? @_ : \@_ } # or something similar but smarter with wantarray sub deref { return $$_[0] if ref($_[0]) eq 'SCALAR'; return retcon @$_[0] if ref($_[0]) eq 'ARRAY'; return $_[0]->() if ref($_[0]) eq 'CODE'; ... }
      --Solo
      --
      You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
        I decided to turn my my auto-updating snippets idea into a SourceForge project once I create new specifications, and possibly get some of the coding done. It might be named "Version Alert and Synchronization System" (VASS) or "Modular Code Alert and Synchronization System" (MCASS). I want it to work with modules to, and be a replacement for use.

        There's no reason to create an arbitrary line between a module and shorter code, even when the shorter code is more universal in purpose and harder to define. I'd like to see all such routines, including idioms, included in a single repository, with a single but powerful search system that lets you find routines in more categories than you could possibly split the routines into manually. The only thing they should have in common is that they are useful scripts that could more or less be reused. No more distinction between non-module code libraries and modules either.

        If you want to browse routines that were described by their authors as idioms, and/or routines of a certain size or purpose, that should be made possible with a search tool that uses stats that were automatically compiled and metadata that was provided by the author.

        There are too many of even the shortest snippets/idioms to fit in a single module, and you shouldn't need to load even 100 or so together if you just want one.

        Scalar::Util contains a selection of subroutines that people have expressed would be nice to have in the perl core, but the usage would not really be high enough to warrant the use of a keyword, and the size so small such that being individual extensions would be wasteful.

        I'm not sure what's meant by "individual extensions." If that refers to individual modules, then I'm not sure I agree that very small ones are a bad idea, as long as my advanced search idea and VASS/MCASS is implemented. But if there were a single file with thousands of snippets (called a module or whatever you choose), something like Tie::File could be used. I prefer that different treatment between large and small reusable scripts be transparent to the programmer.

Re: CPAN module fior common idioms?
by BrowserUk (Pope) on Jul 23, 2004 at 00:35 UTC

    How about

    1. String::Concatenate
      sub concatenate{ $_[ 0 ] . $_[ 1 ] }
    2. Algorithm::Numerical::Addition
      sub add{ $_[ 0 ] + $_[ 1 ] }
    3. Algorithm::Loop
      sub loop (&@) { $_[ 0 ]->( $_ ) for @_ }

    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' );

    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.


    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
      Are you sure about not categorizing these under Acme::Idiomator?
Re: CPAN module fior common idioms?
by halley (Prior) on Jul 23, 2004 at 14:03 UTC
    While the snippet you showed in your example is easily packageable, many idioms are not. Idioms share a lot in common with patterns, which are essentially mental blueprints for common approaches to recurring problems. However, many idioms and patterns also share the unfortunate trait of forming a framework for other tasks, instead of forming a task in its own right.

    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.

    --
    [ e d @ h a l l e y . c c ]

      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

      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 .. $#_ ];}

      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, @_); }
      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
        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!

      ++ 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 ? $_ : () } @_ }
      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!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://376694]
Approved by Fletch
Front-paged by broquaint
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (16)
As of 2014-04-24 09:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (565 votes), past polls