[Israel.pm] Fwd: [Telux] Next Meeting: "High-Level Programming Concepts Using Perl 6" on 22-March

Shlomi Fish shlomif at iglu.org.il
Sat Mar 14 05:10:19 PDT 2009


On Saturday 14 March 2009 01:19:58 Evgeny wrote:
> First of all, you can take a look at the code I wrote right here:
> http://github.com/kesor/p5-cucumber

Maybe I will later.

> The couple of things that I think are less "dynamic" in perl vs. ruby.
> 1. I had a tough time passing regular expressions as parameters, but it
> seems that perhaps I was just using the wrong syntax. So instead of calling
> my function sm(/regexp.*/) I had to pass it as a string sm('regexp.*') and
> enclose it in a regexp later, like /$mystring/. Later I found out that I
> CAN pass it as a parameter, when I use the qr/../ notation. It does work
> like sm(qr/regexp.*/).

Yes, qr// is a valid syntax for compiling a re-usable regex object. You can 
also later use it as a part of a regex like:

my $regex = qr{...};

if ($string =~ m{Hello $regex world})

Nevertheless, constructing regexes out of strings still works and may be a 
legitimate use in some cases. See for example http://betterthangrep.com/ .

> 2. After a regular expression is matched, there is $1,$2,$3 variables one
> can use. But what if the regexp was not known, and I don't know how many
> variables there are ... in perl there is no array that holds all the $X
> parameters. It has to be done using the @- and @+ arrays, and as you can
> see in the code - it's a piece of code that I would kill people over if I
> see them write it. But unfortunately I did not find a different way to do
> it.

You can use:

my @array = ($var =~ m{...}); 

And then look at scalar(@array). Note that with temporarily setting no strict 
refs, you can do something like (untested):

my @matches = ($string, map { ${$_} } (1 .. $#-));

And then refer to it using $matches[1], etc.

I recall doing a similar trick in one of the first Perl Quizzes-of-the-Week.

> 3. There seem to be no minimal syntax for blocks, so instead of the ruby
> way of having do/end of { } I had to use anonymous functions. It's just a
> small thing, but boy does it add syntactic sugar to the DSL.

Well, I don't have a lot of experience writing Domain-Specific Languages 
directly using Perl (or Ruby) syntax, but I have written some 
interpreters/parsers/etc. using Parse::RecDescent ( 
http://search.cpan.org/dist/Parse-RecDescent/ ) and other tools.

In any case, I agree that the syntax for defining re-usable blocks/closures in 
Perl is somewhat obnoxious, especially given that you need to be more verbose 
to extract the parameters out of the closure. And sometimes you are required 
to use sub {...} instead of {...}. This example does not compile:


use strict;
use warnings;

my $sub = { my $name = shift; print "Hello $name!\n"; return; };


Sometimes the Perl interpreter will be able to tell that a { ... } is actually 
a closure (as is the case for map/grep/sort and other prototyped functions - 
like in the user-land List::Util and List::MoreUtils modules).

In Perl 6, every block will be a closure, and it will be easier to construct a 
block like Ruby. And there will be more convenient syntax for subroutine 
parameter extraction, which is also considered for perl-5.12.0.

> 4. I am not claiming that I am perl or perl-oo expert, but it seems to be
> very hard to have my %state thing handled in a class. 

What do you mean by the %state thing? Do you mean the object's instance 

> Because a class has
> to be in a separate file with a "package" for one. 

A package (to which a class normally corresponds in Perl) needs not be in a 
separate file. Any .pl or .pm file may include an arbitrary number of 
different "package" statements. And there is no artificial restriction on what 
these packages may be (so a module called Math/Matrix.pm may contain "package 
Math::Fraction;", "package Something::Completely::Different;" etc.).

What is true is that it is recommended to have a module called Math/Matrix.pm 
implement "package Math::Matrix;" so use'ing it, use base'ing it, etc. will do 
the right thing, and that a module should not define unrelated packages to 
preserve order and prevent namespace pollution. But you should free to define 
"package Math::Matrix::Utils;", "package Math::Matrix::Elem;" and other 
elements there.

> And then there is all
> kinds of magic that has to be done to get class variables, that is really
> non-trivial. 

What do you mean by class variables? Do you mean package-scope or package-
lexical variables that are global to all instances of the same class?

> And then it is even harder to "import" functions, like my "sm"
> method. 

Exporter.pm ( http://perldoc.perl.org/Exporter.html ) is not ideal, but not 
too bad either. And there's also http://search.cpan.org/dist/Sub-Exporter/ 
which is not-core, and supposed to be better.

> And then to somehow "export" stuff from a class. 

See above.

> Again, it just
> might be that I am such a lousy perl programmer -- but all the syntax for
> this (in perl5) feels like chewing hard stones.

> There are probably a couple more things that I wished I could do "like in
> ruby" while writing that small piece of code. But I just dont remember
> right now.
> Overall, you can see it in the code itself - the style of coding is very
> much more ruby-like than what a typical perl programmer would write.
> Correct me if I am wrong.

I'll have to take a look at the code later on.


	Shlomi Fish

> Regards,
> Evgeny

Shlomi Fish       http://www.shlomifish.org/
Optimizing Code for Speed - http://xrl.us/begfgk

God gave us two eyes and ten fingers so we will type five times as much as we

More information about the Perl mailing list