Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Apocalypse 4 on

by redsquirrel (Hermit)
on Jan 18, 2002 at 07:20 UTC ( #139729=perlmeditation: print w/replies, xml ) Need Help??

In case you haven't noticed, Apocalypse 4 is available on I'm going to go read it now. I'd be interested in hearing initial reactions from other monks...

So far I'm excited about...

  • the switch statement (given, when)
  • optional parens in conditionals
  • interspersing code between when's
Still reading...


Replies are listed 'Best First'.
Re: Apocalypse 4 on
by lestrrat (Deacon) on Jan 18, 2002 at 14:09 UTC

    So far I don't understand this :

    sub attempt_closure_after_successful_candidate_file_open (&closure, @fileList) { foreach my $file (@fileList) { my $f is post { close } = try { open $file or die; CATCH { next } } &closure($f); return; } throw Exception "Can't open any file.", debug => @fileList . " tried."; }

    This is supposed to be easier to read??

    On the other hand, I like

    my $foo = BEGIN{ compute_cont() } + $foobar;

    That's cool :-) Although, I guess if you're going to do these compile-time evaluations, it would be nicer if you could do some sort of C-macro-substitution type of thing using arbitrary symbols, so that you don't have to repeat these BEGIN{} blocks.

Re: Apocalypse 4 on
by merlyn (Sage) on Jan 18, 2002 at 18:30 UTC
    Having Damian Conway and Larry Wall on the same boat certainly help speed up the release of this document. Two nights ago, I wandered by a little group watching (and perhaps helping) Larry try to decide how to do the arrow-thingy for foreach loops, with Damian kibitzing. I can see I have a lot of work ahead of me writing new books and creating new trainings for all the old Perl hackers out there.

    -- Randal L. Schwartz, Perl hacker

Re (tilly) 1: Apocalypse 4 on
by tilly (Archbishop) on Jan 19, 2002 at 02:33 UTC
    A couple of obvious observations. The first is that I think the overall switch mechanism would become remarkably clarified by seeing how Duff's device can (or can't, but I think it would) actually operate.

    The second is that if loop control gets to use labels on blocks, do other exceptions? If the answer is, "No", then we are introducing divisions again where built-ins can do things that user code cannot (easily) do. If it is, "Yes", then, well, one part of me is going, "Neato!" while another is gibbering in the corner. And the semi-rational part is left wondering what the syntax would be to break out of a nested switch to a named decision level...

Re: Apocalypse 4 on
by jmcnamara (Monsignor) on Jan 18, 2002 at 14:13 UTC

    I see that my RFC120 was rejected.

    I couldn't say that I am disappointed, however.


Re: Apocalypse 4 on
by ignatz (Vicar) on Jan 18, 2002 at 22:18 UTC
    Wow! This is going to be torture waiting for all this to get done.

    The given/when idea is very wonderful in a Perly kind of way.

    I must confess that I've never been a big fan of try catch blocks (let alone nested ones); how they seem to move the core code further and further to the right. I always like that Perl could just take problems on the end. (... or die, ... || $foo = "bar"). Still, it's very nice to have that funcitonality in there.

    I love reading Larry's respect for the humble origins of the language. Not force feeding a specific programming philosophy down peoples throats. Forcing stricter rules for modules and classes is a brilliant solution.

      I think Larry Wall is brilliant at deconstructing classic CS ideas. I think the deconstruction of classes in perl5 was really revealing to me (I was a C++ fan at that time).

      Now he is deconstructing try-throw-catch.

      I personally love exception handling. I find foo() or die() tiresome, but the alternative of not checking every return value is unthinkable.

      You said "how they seem to move the core code further and further to the right". I interpret that to mean that the error handling (which I don't see as "core code") farther away form the code it is error checking or just a case of indent-itis. Both can be ameliorated by using more fine grained use of try-throw-catch. Using these blocks more often will limit nesting and keep error handling close to the code it handles.

Re: Apocalypse 4 on
by gav^ (Curate) on Jan 18, 2002 at 19:13 UTC
    I seem to be in a state of fear about perl 6 between each apocalypse and the time it takes Damian to bring out his next exegesis.

    Perhaps they need to work together to release them at the same time :)


      Tell me about it... I'm spinning after reading only a couple of pages! I hope it starts to make sense eventually ;)

Re: Apocalypse 4 on
by metadoktor (Hermit) on Jan 18, 2002 at 11:11 UTC
    Holy Guacamole!

    Thirty-nine pages! This is going to take forever to read. ;)

    I don't get it I checked earlier today and no Apocalypse and yet it's dated the 15th which was a few days ago. Hmmm...


    "The doktor is in."

Re: Apocalypse 4 on
by Aristotle (Chancellor) on Jan 20, 2002 at 13:54 UTC
    I liked the fundamental idea that all curlies are a sort of closure and the control flow keywords simply become funny-looking exceptions. I bet we will find ways to take advantage of this - be it some new often-used idiom or simply for golfing. :-) Overall I must say the whole deal is looking very Perlish, though pretty different. Getting used to it will be interesting.

    The only part I don't really much like is the way properties and type hints clutter up what used to be the simplest and most intuitive part in the language - the mys. We'll see how people come to deal with it. In my current state (though this may well change after a while of composing Perl 6 code) I'd hate the idea of every my under the sun having a type declaration and every other one having a half dozen properties. But we'll see how mandatory these features will feel in two years.

    Makeshifts last the longest.

Re: Apocalypse 4 on
by scott (Chaplain) on Jan 19, 2002 at 03:19 UTC

    I thought the switch statement was completely cool until I saw default. Ick. I'd like this much better:

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

    My 0.02$US.

      I know what you mean, but given (sigh) how often this'll be used, I think it's better to Huffman it. If anyone has a brilliant idea for a shorter keyword than default, I hope they'll send it in.


      They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen

        How about nothing?
        given ($foo) { when (1) {print "One";}; when (2) {print "Two";}; print "Didn't fit any case we know about"; }
        Indent to taste.

        I don't think that "normal code" will often see a difference. While I can dream up situations where I think it matters, in all of them you are doing evil, awful things that you probably shouldn't. (Like using a default to shortcircuit out of a function.)

        If anyone has a brilliant idea for a shorter keyword than default, I hope they'll send it in.
        Not shorter, but I think it's easier to read and a lot better:
        given $foo { when 1 { ... } when 2 { ... } when we have tried all other options and really have nothing left but this last resort { ... } }


        2;0 juerd@ouranos:~$ perl -e'undef christmas' Segmentation fault 2;139 juerd@ouranos:~$

        I pondered that for a bit but the best I could to was orelse. But that's even worse. :(.

      By Larry's explanation, the idea of default was to prevent given's which don't have any when's from looking funny.
      Makeshifts last the longest.

        Hmmm ...

        given EXPR { otherwise { ... } } given EXPR { default { ... } }

        default definitely looks better here. I wonder how often people write empty switch statements though? Then again, given isn't your father's switch so past coding patterns may very well not apply. about...
      given EXPR { when EXPR { } when EXPR { } ... japh { } }
      ha, ha...


      "The doktor is in."

        You are missing a colon.
        given EXPR { when EXPR { } when EXPR { } ... japh: { } }
        Happy to help,


Re: Apocalypse 4 on
by Ranna (Acolyte) on Jan 19, 2002 at 04:55 UTC
    This will definately take some getting used to. It looks like there will be a lot of really cool features, such as all variables being objects (well, still kinda mixed on this one, I like if ($var) {...} better than if (bit($var)) {...}, but I'm not sure I read that right.), and the operator: functions (obfuscation will be interesting...).

    (I like otherwise, too, even if it brings back nasty memories of pascal class. :oP )

      You are reading that both correctly and incorrectly; if ($var) {...} implies if ($var.bit) {...} (both of which are now the same as if $var {...}). Using somthing in a boolean context implies using the .bit method.

      James Mastros,
      Just Another Perl Scribe

Re: Apocalypse 4 on
by Anonymous Monk on Jan 19, 2002 at 11:44 UTC
    LOL sounds like Ada!

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://139729]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (4)
As of 2023-03-29 15:32 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (72 votes). Check out past polls.