I would definitely love to have a native given expression today. It does not mean that I believe it's likely, but certainly it's highly desirable.

given EXPR {
    when EXPR { ... }
    when EXPR { ... }
    ...
}

my sub get_data ($data) {
    given $data {
      when /^\d+$/    { return %var{""} = $_ }
      when 'previous' { return %var{""} // fail NoData }
      when %var       { return %var{""} = %var{$_} }
      default         { die Err::BadData : msg=>"Don't understand $_" 
+}
  }  
}
[download]

See Apocalypse 4 and Exegesis 4

 _  _ _  _  
(_|| | |(_|><
 _|   

I would definitely love to have a native given expression today. It does not mean that I believe it's likely, but certainly it's highly desirable.

The real power is not in given/when but in the smart match operator, ~~. I see no reason why it couldn't be implemented in current Perl, as infix ~~ doesn't clash with any existing operator. Obviously, the negated version (!~) can't exist, but not/! fixes that easily, and we could use even opt to use !~~ for the time being.

All we need is a volunteer to patch perl. :)

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

I see no reason why it couldn't be implemented in current Perl, as infix ~~ doesn't clash with any existing operator.

There isn't a technical reason why it couldn't be implemented. I think the main reason it won't get implemented is that the people really wanting it aren't going to write the patch, and the few that do write large patches for perl5 have other priorities.

Write a solid patch that does implement binary ~~, addressing all possible backwards compatability issues, and you'll have a decent chance of getting the operator in Perl.

And that's true for all Perl6 features people want find its way into Perl5. Wishing for it won't get it implemented. Voting for them won't get them implemented. Discussing here how useful the features would be won't get them implemented.

The basic rule for adding new features to perl5 has been for several years: write a patch that adds the feature. Discussing the idea on p5p first might not be a bad idea, (if only to avoid doing work for something that won't get accepted). But unless you write the patch, or find someone to write it, it's unlikely to be added.

The Perl5 module Switch gives that to us today. There are a lot of other things that we have today, and Scott Walter's new book, Perl 6 Now, talks about a lot of them. :)

Update: Yep, it's a source filter and it's not native, but it is there :)

--
brian d foy <bdfoy@cpan.org>

Switch is hardly comparable to a native implementation.

From the docs:

BUGS
There are undoubtedly serious bugs lurking somewhere in code this funky :-) Bug reports and other feedback are most welcome.

LIMITATIONS
Due to the heuristic nature of Switch.pm's source parsing, the presence of regexes specified with raw ?...? delimiters may cause mysterious errors. The workaround is to use m?...? instead.
Due to the way source filters work in Perl, you can't use Switch inside an string eval.
If your source file is longer then 1 million characters and you have a switch statement that crosses the 1 million (or 2 million, etc.) character boundary you will get mysterious errors. The workaround is to use smaller source files.

Not the kind of things you'd like to deal with when you are coding in a hurry ...

To use Switch; is definitly a bad idea. I just don't get it why such a wiggly thing is in the core.


holli, /regexed monk/

Object attributes done right

Where right is some weird kind of right that includes source filtering :)

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

That's true, but until perl6 shows up, I don't think there's another way of making inside-out objects that convenient.
"What should it profit a man, if he should win a flame war, yet lose his cool?"

Ever benchmark inside out objects? It can't be good

Hmmm.....

#!/usr/local/bin/perl -w
use strict;

package CA;
use base 'Class::Accessor';

__PACKAGE__->mk_accessors(qw(a b c));

package LA;

use Lexical::Attributes;

sub new {bless [] => shift}

has $.a is rw;
has $.b is rw;
has $.c is rw;


package main;

use Benchmark;

my %methods = map {
    my $name = $_;
    $_ => sub {
        my $object = $name->new;
        $object->a(1);
        $object->b(2);
        $object->c(3);
    }
} qw(CA LA);

timethese (500000, \%methods);

__END__
Benchmark: timing 500000 iterations of CA, LA...
        CA: 10 wallclock secs (10.25 usr +  0.02 sys = 10.27 CPU) @ 48
+685.49/s (n=500000)
        LA:  7 wallclock secs ( 5.98 usr +  0.00 sys =  5.98 CPU) @ 83
+612.04/s (n=500000)
[download]

Doesn't look too shabby to me.
"What should it profit a man, if he should win a flame war, yet lose his cool?"

If I had the push, I would put coroutines or at least iterators into the Perl 5 core, like Coro provides them already (in a less portable, more restricted way). With at least iterators, you can easily avoid the "inversion of control" problem that arises as soon as you have or use a framework that either provides callbacks or provides call-in hooks, and you don't need to maintain state yourself (see the push/pull examples below).

Painless iterators:

sub i_produce {
  my ($start, $count) = @_;
  for my $i ($start..$start+$count) {
    yield $i;
  };
};

sub i_two_columns {
  while (defined (my $i = produce)) {
    print $i;
    if (defined (my $j = produce)) {
      print "\t$j";
    };
    print "\n";
  };
};
[download]

Perl way (push):

sub p_produce {
  my ($consumer, $start, $count) = @_;

  for my $i ($start..$start+$count) {
    $consumer->($i);
  };
};

{
  my $odd;

sub p_two_columns {
  # aieeee - need to maintain state
  $odd = ($odd + 1)%2;
};
};
[download]

Perl way (pull):

{
sub p_produce {
  my ($consumer, $_start, $_count) = @_;
  # aieee - need to maintain state:
  my $pos = $start;
  return sub {
    $pos < $start+$count ? $pos++ : undef
  };
};
};

sub i_two_columns {
  my ($produce) = p_produce(2,10);
  while (defined (my $i = $produce->())) {
    print $i;
    if (defined (my $j = $produce->())) {
      print "\t$j";
    };
    print "\n";
  };
};
[download]

Macros.

B::Generate already has most (all?) of the nouce required to make macros available in Perl 5 right now. I wish I could pursuade it to build on win32.

As a very loose spec, something like this ought to work.

use Macro 
    'min( $x, $y )' => q[ ( $x < $y ? $x : $y ) ],
    'max( $x, $y )' => q[ ( $x > $y ? $x : $y ) ],
;

...
my( $p, $q, $r ) = ( 1, 2, 3);
my $i = min( $p, $q );
my $j = max( $q, $r );
[download]

This can be almost done now by evaling the strings and storing a coderef in a hash, and declaring an empty sub with the macro name. Then at INIT{} time, walk the codetree looking for calls to the subs and substitute the code generated earlier for the subcalls.

Macros.

Now that you mention them it occurs to me that another desirable feature could be the possibility of creating user defined (infix, postfix, postcircumfix, etc.) operators. But I doubt that even hypothetically this could be doable without anything close to Perl6's powerful prototyping.

I'd like that ability too, but I seriously doubt it is possible.

Having (just) managed to work my way through the process of adding a new keyword, I have a new (but still basic) understanding of the process involved in toke.c.

I cannot imagine that it would be an easy task to allow the addition on new operators on the fly.

If the macro facility was added, then you might be able to define a few catchall keywords that would act as placeholders in the syntax. Say uniop() and binop() and then wrap those in macros to define an new operator. Not sure about that.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

I know Damian proposed an RFC about it, I just have no clue what Apocalypse it's supposed to be discussed in.

update: got it

In general it'd probably be better to direct people to the most recent version at dev.perl.org, since it includes "Update" sections that say how things have changed since the original Apocalypse came out.

Well, that makes a big assumption. The assumption being that there will actually be a Perl5 release before Perl6. It's been almost a year since 5.9.1 was released, with no 5.9.2 appearing at the horizon.

In the now almost 5 years perl6 has been discussed, only one feature has appeared in the 5.9.x track: the defined or. And that's something that has been requested for years before the perl6 project started.

Other than a few modules that use tricks like source filtering or overloading I don't think much of perl6 will trickly into perl5. Perl5 development, slow as it goes, seems to mainly focus on improving existing features (threads, Unicode, regexes), and then mostly below the surface (removal of bugs, better performance, reentrance). I get the impression (correct me if I'm wrong) that perl developers either work on perl6 or on perl5, and that only a few work on both.

So, for various reasons, I think it's unlikely much of the perl6 goodies will get implemented into perl5. Which is a pity.

Well, that makes a big assumption. The assumption being that there will actually be a Perl5 release before Perl6. It's been almost a year since 5.9.1 was released, with no 5.9.2 appearing at the horizon.

Well, but then even if I'm not involved into anything having even remotely to do with p5p, it's hard to believe that 5.9 won't make into 5.10 which is a "next major release".

So, for various reasons, I think it's unlikely much of the perl6 goodies will get implemented into perl5. Which is a pity.

Hmmm this sort of things are hard to predict, longterm. And Perl6 development is guaranteed to take quite a while. Just the other day Larry wrote in p6l:

Me too.  If it's any comfort, just think of the design of Perl 6 as
a genetic algorithm running on a set of distributed wetware CPUs.
We'll just keep mutating our ideas till they prove themselves adaptive.

(this is now one of my .sigs!)

The say command.

package Perl6::say; use base 'Exporter'; @EXPORT = 'say';
sub say { print @_, "\n"; } 1
__END__
=head1 NAME

Perl6::say - Perl extension to get say in Perl 5

=head1 DESCRIPTION

DWYM :)

=head2 Exported list operators

=head3 say

C<print>s its arguments and "\n";

=head1 CAVEATS

Does not support printing to filehandles that are not currently C<sele
+ct>ed (one arg).

=head1 SEE ALSO

L<perlfunc/print>
[download]

:)

I've tried Perl6::Say, but found it wanting.

The list of caveats regarding the type of filehandles it will work with is annoying. I tend to store file handles in hash elements quite frequently, and use indirect object notation print { $fhs{INPUT} } $stuff;, and that doesn't work with P6::Say.

I'm not ready to give up the simplicity of that notation and move to $fhs{INPUT}->say .... If filehandles were truely OO constructs, complete with independant settings for $/, $\, $=, $., $^ etc. etc., then it would be a different matter...but they aren't.

If say were implemented within the language, it would be barely any code at all. Just a stub sub, pp_say, that localised $\ and set it to "\n", and then calls pp_print() would probably be all was required, but it would 'Just work'.

I think it would be a very useful addition to Perl5--but then I'm biased against having to add zillions of ."\n"s :)

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

Isn't say just as simple as adding 'say' as a keyword to keywords.pl in the Perl source, recompiling, then doing:

*CORE::GLOBAL::say = sub { print @_, $/ };
[download]

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Not quite. For a start, $/ may not be set, or could be set to \42 or ...

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.