Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Does anybody know why he introduced those hyperoperators @c = @a ^+ @b? I could imagine something like

    @c = map({$a + $b} @a, @b)

    beeing much more backward-compatible, less line-noisy and more flexible.
    • Intriguing syntax you've introduced there.

      Does it cope well if you introduce more operands? e.g.

      @e = map ( { $d + $c } @d, map ( {$c + $b } @c, map ( {$a + $b} @a, @b ))

      My apologies if I lost track of parens. It's a bit noisy compared to:

      @e = @a ^+ @b ^+ @c ^+ @dmap {} will probably just provide more power. We'll see when he gets to Apocalypse 29 ("Functions"). That's assuming he doesn't skip any numbers =)
      --
        ---ict / Spoon
      • I don't think you need the parens here. It all depends how automatic list flattening is handled: is map {} @a,@b the same as map {} @c?? I thought of the $a and $b as similar to the ones used in sort(). Its just chance that they use the same symbols (a and b) as the argument lists.

        Your example would write:

        @e=map {$a+$b} @d, map {$a+$b} @c, map {$a+$b} @a,@b

        One could even introduce an arbitrary number of parameter lists. In that case:

        @e=map {$a+$b+$c+$d} @a,@b,@c,@d

        Of cours

    • (this is all my conjecture)

      For one, it moves away from a functional interface to an operator interface, which may be more line-noisy, but I think is cleaner. Count the line-noise symbols in your two statements.

      Two, I seem to recall reading some discussion about trying to get rid of $a and $b. (Could be wrong).

      Three, it's a different way of looking at it. with map you are doing something to a set of data. Your view of that data is abstracted through map(), which makes this less intuitive to the ne
  • Enough said ;-)

    Seriously am I the only one not looking forward to
    many of the new "features" in Perl6?

    A lot of almost seems like it's designed expressly
    to be not backward compatible (except for -MPerl5)
    and to confuse the hell out of experienced persons.

    I must say though that //= is something I've
    wanted for awhile (seemed wasteful to use ? : ). On the other hand I do use ? : (trinary) a lot;
    not just to do //=.

    PS> gripping hand :-D Niven rocks!
    --
    Were that I say, pancakes?
    • Just out of interest, and this leapt out at me while reading the Apocalypse, isn't the term "ternary" rather than "trinary"?
      --
        ---ict / Spoon
      • Nope. Trinary as in triple. Ternary would seem to be an attempt at forming a quadruple.

        It's in the perl 5 man pages as well, and elsewhere (JavaScript)
        --
        Were that I say, pancakes?
        • Nope. Trinary as in triple.

          ...is a valid, though less common, alternative to the more widely used "ternary".

          Ternary would seem to be an attempt at forming a quadruple.

          Err...not in English (or Latin):

          ternarius -- "Consisting of three"

          quaternarius -- "Consisting of four"

          "Trinary" appears to be a 15th century back-formation from "binary".
          • Huh, well okay then.

            Though *my* webster says ternary is from Middle English from Latin terni and trinary is straight from Latin trini.

            Both trini and terni meaning "three each".
            --
            Were that I say, pancakes?

          • "Trinary" appears to be a 15th century back-formation from "binary".

            So all those old mainframe guys who had to program a database using only zeros (ones having been invented rather later) are even older than we thought? Lends credence to the Ascended Masters theory of data warehousing, anyway.

            (never let the fact that 1 predated 0 in Western thought get in the way of a lame joke)

    • Seriously am I the only one not looking forward to many of the new "features" in Perl6?

      No, you're not the only one.

      Of course this is all going to be open source, so the market will choose, rather than marketing. Personally I think a fork would be a good idea here. A sort of Perl 5 with a parrot backend, but with extended syntax to make classes easier and cleaner, and maybe make XS type stuff easier (though I think that's kinda covered by Inline.pm now) and *thats all*.

      These were issues that Chip was t
      • I heard the same rhetoric about Perl 5 when people were wedded to Perl 4 ("hopefully there'll be a fork so I won't have to use this OO crap," etc.). And, indeed, there are people to this day who insist on writing Perl 4 syntax (which is why I always throw semi-hairy Perl 5 syntax at people who are interviewing for Perl positions--I don't want to deal with reading their code).

        Human language evolves. And Perl, as the most human of computer languages, will evolve too. Along that line--one of the character

        --

        --
        Trey Harris
        Secretary, The System Administrators Guild [sage.org]
        • Thing is though, 4 isn't *all* that different from
          5. I started with 4 and 5 together an the only thing I really ever had to bang my head against was the lack of lc and uc...
          --
          Were that I say, pancakes?
        • The big difference here is this isn't evolution - it's rebirth. For Perl 5 Larry added a few simple keywords (e.g. bless()), and thus was born OO perl. With Perl 6, out goes the baby with the bathwater.

          Sorry, but I support Simon Cozen's RFC (I hope I'm remembering it right) - leave perl as it is, barring some new syntax for better class support. And hopefully the parrot backend. If you look at the original plans for Topaz (cleaner internals, easier extensibility - keep the current syntax), those are simil
    • You aren't the only one based on the comments I've seen, but I for one am eagerly awaiting Perl6.

      Yes, I'll have to relearn a lot of Perl syntax. Well worth it to get a cleaner interface. (One of my dearest wishes is for a vastly improved subroutine arg-passing interface).

      Yes, it may confuse some experienced people, but remember why you came to Perl inthe first place and see if Perl6 is or is not moreso.

      • I like Perl because it doesn't tell me what to do:

            loose typing

            TMTOWTDI

            no forced scope variables...

            etc. etc. etc.

        And so much of the core things happening for Perl6
        seem to be in direct conflict with this.

        "I'm smarter than the computer (and hence language) damnit, let me do it *my* way."
        Or at least:
        "I *think* I'm smarter than the computer damnit,
        let me shoot myself in the foot if that's what I really want to do"
        AKA
        The UN*X philosophy
        --
        Were that I say, pancakes?
        • I like Perl because it doesn't tell me what to do: [...] And so much of the core things happening for Perl6 seem to be in direct conflict with this.

          I must disagree. The things unveiled so far seem to be if anything much DWIM-ier than previous Perls. For gossakes, why doesn't if ($x work?

          --

          --
          Trey Harris
          Secretary, The System Administrators Guild [sage.org]