in reply to Re^2: Perl 6 <-> Perl 5 bridges (was Re^2: Capturing parenthesis and grouping square brackets)
in thread Capturing parenthesis and grouping square brackets

It's one thing to not constrain Perl6 to back compat and another to create unnecessary confusion by arbitrary operator and sigil changes. No the result is not more friendly, the result is more confusing. It's like Russian to a Czech. Yeah the languages have lots of similarities, part of the vocabulary, the declination system ... which means that Czechs use Slovak words with Russian accents in cases where the Russian word is completely different, they use word that sound similar, but mean something completely different, waste time trying to remember a word when pronouncing the Czech one in Russian accent would be correct, they decline all wrong, because while the declinations are deceptively similar they are also different etc. etc. etc.

All this doesn't matter that much when speaking to a human being (unless that being is a teacher), communication with a compiler is much less forgiving and when combined with your hailed two kindaPerl5s this just creates an insane mess.

You can use @ for arrays in the STD language of Perl 6, but you don't have to

So what's the difference between $array and @array then? Sigils are a perfect example of an absolutely pointless and confusion generating change. Imagine you are new to all this and you ask uncle Google what the heck do those $s and @s and %s mean ... you get contradicting answers!

The toolchain eventually created by this project may end up being used for something, but so far it has hurt rather then helped Perl.

Jenda
Enoch was right!
Enjoy the last years of Rome.


Comment on Re^3: Perl 6 <-> Perl 5 bridges (was Re^2: Capturing parenthesis and grouping square brackets)
Select or Download Code
Re^4: Perl 6 <-> Perl 5 bridges (was Re^2: Capturing parenthesis and grouping square brackets)
by raiph (Hermit) on Jun 21, 2013 at 11:50 UTC
    So what's the difference between $array and @array then?

    $ indicates that a variable will behave as if its content were a singular thing. That singular thing could be a number, string, routine, object, etc. -- or an array or hash. In list context its content will evaluate to be a singular thing; if it's actually plural, that singular thing will be a reference to the plural thing.

    @ indicates that a variable will behave as if its content were a plural thing. If the content is actually singular it behaves like a 1 element array.

Re^4: Perl 6 <-> Perl 5 bridges (was Re^2: Capturing parenthesis and grouping square brackets)
by raiph (Hermit) on Jun 28, 2013 at 02:23 UTC
    No the result is not more friendly

    Perhaps you did not understand that my "more friendly" comment was about P5ers learning P6 versus learning lisp, haskell or scala. Or perhaps I just need to be more concrete.

    Consider a dissatisfied or adventurous P5er who is considering learning lisp or haskell to better solve a problem or advance their skills or career. To facilitate comparison, here's a simple example task, the Same Fringe task on Rosettacode:

    Write a routine that will compare the leaves ("fringe") of two binary trees to determine whether they are the same list of leaves when visited left-to-right ... an elegant solution is one that can perform the minimum amount of work to falsify the equivalence of the fringes when they differ somewhere in the middle, short-circuiting the unnecessary additional traversals and comparisons.

    Rosettacode solutions in lisp (racket), haskell, and Perl 6:

    === lisp (racket) === #lang racket (require racket/control) (define (make-fringe-getter tree) (&#955; () (let loop ([tree tree]) (match tree [(cons a d) (loop a) (loop d)] ['() (void)] [else (fcontrol tree)])) (fcontrol 'done))) (define (same-fringe? tree1 tree2) (let loop ([get-fringe1 (make-fringe-getter tree1)] [get-fringe2 (make-fringe-getter tree2)]) (% (get-fringe1) (&#955; (fringe1 get-fringe1) (% (get-fringe2) (&#955; (fringe2 get-fringe2) (and (equal? fringe1 fringe2) (or (eq? fringe1 'done) (loop get-fringe1 get-fringe2))))))))) === haskell === data Tree a = Leaf a | Node (Tree a) (Tree a) deriving (Show, Eq) fringe :: Tree a -> [a] fringe (Leaf x) = [x] fringe (Node n1 n2) = fringe n1 ++ fringe n2 sameFringe :: (Eq a) => Tree a -> Tree a -> Bool sameFringe t1 t2 = fringe t1 == fringe t2 === Perl 6 === sub fringe ($tree) { multi sub fringey (Pair $node) { fringey $_ for $node.kv; } multi sub fringey ( Any $leaf) { take $leaf; } (gather fringey $tree), Cool; } sub samefringe ($a, $b) { all fringe($a) Z=== fringe($b) }

    The P6 solution invisibly incorporates lazy processing (stolen from haskell) and parallel processing (the all "junction") and visibly incorporates multi subs (stolen from lisp).

    Of the three solutions, I think the P6 one will look by far the most approachable and be by far the easiest to explain to an average P5er.


    The P6 design takes in to account bridging to P5 in many more ways than just providing more syntactic and semantic continuity than most non-Perl langs (imo). For example, it supports inline mixing of langs (and does so with way more underlying cleanliness and power than P5's equivalents):

    use v5; # start with p5 code if ( $^O eq 'MSWin32' ) { # more p5 code } elsif ( $^O eq 'Android' ) { use 6.0.0; # switch to p6 code say "On $*OS"; # $*OS is p6 equivalent to $^O multi sub foo(*@args) { ... } } say "Back to Perl 5 on $^O"

    I agree that there are heavy downsides to mixing langs like this. I don't agree that those downsides are so great that it never makes sense to mix langs inline, even ones that are closely related. YMMV.

      No, I don't think Perl5ers would find the last example most approachable. Even with those superficial similarities like sigils and the sub keyword. They will go all what-the-fuck. I would find the Haskell version much easier to explain.

      Regarding the mixing of languages: it's exactly the other way around! It does make sense to mix languages inline IF (and almost only if) they are NOT closely related. It makes sense if 1) they serve a different purpose and 2) can be (almost) immediately told apart! If you have to scroll up to see whether that thing you are looking at is Perl6, Perl5 using some feature you were not aware of or Perl5 with a source filter or some clever prototype hackery, then you are wasting everyone's time and introducing bugs. Bugs coming from subtle differences of the languages, from misunderstanding, from reading the wrong documentation, ...

      Jenda
      Enoch was right!
      Enjoy the last years of Rome.

        (deleted and moved here for better code formatting)
        It does make sense to mix languages inline IF (and almost only if) they are NOT closely related.

        It seems plausible that the most sensible use, especially long term, for the P6 language mixing capabilities, will be to use noticeably dissimilar langs and DSLs.

        Note that this can be P5 and other langs just as it can be P6 and other langs. In other words, one way to treat P6 is as a framework for P5. This way you get the non-lang benefits of P6, such as the fact that its P5 will (presumably) soon run on Android, and has a really nice debugger, etc. without the distraction of P6 syntax.

        The principle that different things should look different is associated with Larry Wall, a linguist, the guy who designed P5 (and P6). In other words, yes, he's very sensitive to this issue of confusing similarities (and I reckon hundreds of others that relate to human and computer languages).

        When I said "there are heavy downsides to mixing langs like this" I specifically meant P5 and P6 and the issue that their similarity can be confusing. But I also said "I don't agree that those downsides are so great that it never makes sense to mix langs inline, even ones that are closely related" by which I specifically meant P5 and P6, on occasion (which perhaps agrees with your "almost" qualification in "almost only if"?).

        It totally makes sense for folk to avoid inline mixing of P5 and P6 (or one of these and PHP or whatever other similar looking langs are available for inlining) if they can get the job done another way. But, imo, having the option available to mix them if one is in a tight corner time/skills/resource wise, during the years of transitioning from using just P5 to using a mix of P5 and other langs, is a valuable one, one that makes P6 more valuable for P5ers, not less.