http://www.perlmonks.org?node_id=1035413


in reply to Re^3: Perl 6 implementation of the following Perl 5 code
in thread Perl 6 implementation of the following Perl 5 code

Way too late for the discussion, but one wonders if the removal of if condition parens is really worth the requirement to invent a concept such as "unspace".

I mean really? "unspace"! If ever there was a 'seemed like a good idea at the time' that became 'a rod for our own backs' in the making; that's gotta be it.

Especially, if most potential users are like me, and will always be using a mix of different languages at the same time.

I'm pretty sure that if I ever make any regular use of P6, I will use parens around if conditions anyway. Simply because it is easier to not go through the pain of unlearning the habit (perhaps:'unparensing'?) for just one of the languages I (potentially) use every day.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re^4: Perl 6 implementation of the following Perl 5 code

Replies are listed 'Best First'.
Re^5: Perl 6 implementation of the following Perl 5 code
by moritz (Cardinal) on May 27, 2013 at 15:32 UTC

    Fwiw the removal of condition parens isn't related to unspace at all. Rather it's related to the fact that if you allow whitespace around the method call operator, you can't infix operators beginning with a dot (for example the range operator .. comes to mind).

    In Perl 5 this is less of an issue because the method call operator is longer, so not having any infix operators beginning with -> isn't a big loss.

    Finally Perl 6 allows you to write .method as a shorthand for $_.method, and if we allow a blank before the dot, it's hard to distinguish a method call on the previous term from a method call on $_.

    That said, such long chains of method calls tend to be rare in code I write, so the unspace really isn't such a big issue in practice.

      ... such long chains of method calls tend to be rare in code I write...

      In code you write, perhaps.

      ... to distinguish a method call on the previous term from a method call on $_.

      How often does someone expect to chain methods and call a method on $_? Seems to me if you want to change the invocant from whatever the previous expression returned, you ought to make that method explicit, whether by typing it out by hand or terminating the entire statement so that it's not ambiguous at all.

      Such long chains of methods tend to be common in code I write. The more I know about Perl 6, the less I care it's not in a usable state yet. This is yet another of the decisions that make Perl 6 cryptic and unreadable.

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

Re^5: Perl 6 implementation of the following Perl 5 code
by hdb (Monsignor) on May 27, 2013 at 14:28 UTC

    But even then, you have to be very careful, as it seems that

    if( $x==5 ) { ... }

    is not an if clause anymore but will look for a function called if. (And will generate an error here.)

      Ouch!


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
Re^5: Perl 6 implementation of the following Perl 5 code
by ww (Archbishop) on May 27, 2013 at 15:23 UTC
    Well, continuing the use of parens does seem a good idea, but as an alternate, perhaps P6 could adopt an un-paren, denoted by
    a.)  )
    b.) /)   ... or
    c.) «   »

    If you didn't program your executable by toggling in binary, it wasn't really programming!

      For Fantasy and London fans I would recommend "Un Lun Dun" by China Mieville.