in reply to Porting (old) code to something else

I do not like the new whitespace issues that perl6 imposes on the code. It strikes *me* as ugly and illogical.

Don't you think you may be trying a little too hard to rigidly carry along your favorite coding style and way of doing things from one language to another, rather than adpating to the new language and the ways it does things differently from what you're used to?

"ugly" is of course subjective, but I don't think it's fair to call the Perl 6 function-call whitespace rules "illogical". Different from what you may be used to, yes, but they do make sense within the context of the language:

No accidental listop/function-call ambiguity

First of all, those rules solve the function-call ambiguity that can make working with listops in Perl 5 annoying. For example, say you have a Perl 5 script that prints a short line of text like this:

say $line;

[download]

...and you are tasked with amending it so that the line is indented by a certain (variable) number of spaces. Imagine you already have the required indentation width stored in the variable $n, so you might change the code to:

say (" " x $n).$line;

[download]

...right? Wrong, because the parser now interprets say (" " x $n) as a function call and .$line as a concatenation on the return value of the function. At least newer versions of Perl will print a warning for specific (commonly written by accident) cases like this, but it's still annoying, and the work-arounds to make the code do what was intended involve extra clutter:

say "".(" " x $n).$line;
say( (" " x $n).$line );

[download]

And in Perl 6 this situation would be much worse, because every subroutine can be called both using the function-call style and the listop style, so in most cases the parser couldn't print a warning when you accidentally turn a listop into a function call because it doesn't know that it was unintentional.

So it's important to disambiguate the two in a way that doesn't lead programmers to misstate their intent by accident. Checking whether or not the very first letter after the subroutine name is a paren, works quite well in this regard in Perl 6:

# listop style:
foo;
foo "bar", $baz, 42;
foo (1, 2, 3), [1, 2, 3];  # one List, one Array
foo { $_ * 10 }, 2, 4, 6;  # one Block, three Int

# function-call style:
foo();
foo( "bar", $baz, 42 );
foo( (1, 2, 3), [1, 2, 3] );  # one List, one Array
foo( { $_ * 10 }, 2, 4, 6 );  # one Block, three Int

[download]

If you want a listop, you would never thoughtlessly write a paren immediately after the identifier.
If you want a function call, you do need to remember the "no space before the paren" rule when you write it, but it is not something you would thoughtlessly change when coming back to tweak the code later on.
So either way, you're reasonably safe.

Language consistency/integrity

The "no whitespace before the paren" rule actually cuts both ways: Whenever you see an identifier in 'term position' immediately followed by an opening paren, you know it's parsed as a function call.
For example, you could define a qq subroutine and when you write qq(42) it will call that subroutine rather than invoke the qq/.../ quoting construct. Not that you would necessarily re-use the names of built-in constructs, but imagine a case where one module adds a quoting construct and another module exports a subroutine of the same name.
It's important for the language to give programmers a way to disambiguate clearly between syntax constructs and cover all corner cases, and it's good if it can do that using a simple rule that you only need to learn once and is used across the board: in this case, "parsed as a function call if and only if the identifier is immediately followed by a left paren".

Slangs to make everyone happy?

I share BrowserUK's reservations about lexically scoped cosmetic slangs - if you end up with multiple different ones in the same project, you'll always have to be super careful to be aware of the exact slang you're currently in when you make changes, and it will likely just end up a mess.

And in this particular case (Slang::Tuxic) we're talking about one that adds ambiguity to the grammar (as its README readily admits), which is imo an additional red flag.

So yeah, if FROGGS had fun writing the slang and you have fun using it while learning Perl 6, more power to you, but I would advise against using something like this in production code.

Better to embrace the design of the programming language you're working with and try to learn and discover the most elegant ways to do things within that design, rather than bracing yourself against it and trying to force the language into the habits you carried over from other languages.

Replies are listed 'Best First'.
Re^2: Porting (old) code to something else [Perl 6 whitespace rules are annoying!]
by Tux (Canon) on Feb 18, 2015 at 19:45 UTC
    And in this particular case (Slang::Tuxic) we're talking about one that adds ambiguity to the grammar (as its README readily admits), which is imo an additional red flag.

    If not doing any dangerous things that cross the (thin) line, I don't see a problem (other than having others maintain the code later).

    So yeah, if FROGGS had fun writing the slang and you have fun using it while learning Perl 6, more power to you, but I would advise against using something like this in production code.

    I have full confidence that slangs are implemented safe enough to not leak into userland. IMHO perl6 is not yet ready for "production code" in the coming few months, but it is going there fast!

    <vlockquote>Better to embrace the design of the programming language you're working with and try to learn and discover the most elegant ways to do things within that design, rather than bracing yourself against it and trying to force the language into the habits you carried over from other languages.

    If I percieve this "elegance" as illogical and ugly, I won't use the language at all. at all. As said, part of programming is having FUN! And if if I amm annoyed on every line I write in whatever programming language, I will not have FUN and I will stop using that language (unless payed for by a factor many multiplies of my current sallary).

    You also use the word "habits". If you have taken the time to read my reasoning (and I do not expect you to agree), you will at least see that it meets a logic. Maybe not your logic, but it is consistent. I took a lot of time to think this over, together with my fellow students.

    You probably underrate the influence of the flexibility of how a programming language can match the train of thoughts of a programmer. Perl5 is EXCELLENT in supporting this. Perl6 matches this in programming rules and flexibility in the language, but NOT in the flexibility in style. That has put me off. So much that it tool Slang::Tuxic to bring me back.

    You say it is important for the language to give programmers a way to disambiguate clearly between syntax constructs. I disagree. It is not important for the programmer, but for the language interpreter/compiler. The programmer writes it the way he or she understands the problem. It is his/her task to write it in a way the interpreter/compiler will do what the programmer intended the code to do. IMHO it is very counterproductive to write in a way that your mind doesn't understand, just to match the language rules.

    The no whitespace before paren rule is likely to work for the majority of (fresh) programmer who learned it like that, but you will have to accept the fact that it also works opposite to other programmers (like me), who do NOT recognize it the way you see it, but only see "ugly code" and are annoyed.


    Enjoy, Have FUN! H.Merijn
[reply]
Re^2: Porting (old) code to something else [Perl 6 whitespace rules are not illogical!]
by salva (Canon) on Feb 18, 2015 at 18:10 UTC
    For me, this space-matters-in-some-situations thing is probably the one I dislike the most in Perl 6.

    The difference is too subtle and no other language with C-like-syntax does it. I know that I am going to bump into it, over and over.

[reply]
      For me, this space-matters-in-some-situations thing is probably the one I dislike the most in Perl 6.

      Isn't it the other way around?

      Currently, space-matters-in-some-situations in Perl 5; and this is the antidote to it. No space allowed between a function name and it opening paren. Sorted.

      (Is it any different to requiring that there be no space between '=' & '~' in the regex operator?)

      It's correcting a problem (in Perl5) rather than creating a new one.

      'cept maybe for those who dogmatically believe that the close presence of a ( makes this: func (); suddenly become invisible: func( );. I can still see it.

      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". I'm with torvalds on this
      In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
[reply]
[d/l]
[select]
      I know that I am going to bump into it, over and over.

      I don't experience it that way personally. (I've started using Perl 6 for some of my private scripting needs a few months ago, which doesn't give me a huge amount of experience with it, but at least a general feeling for the language.)

      Once you internalize the rule that the paren has to immediately follow the identifier, you start looking at them differently – almost like they form a single token. And you really only need to think about it when writing a new function call, which is exactly when your brain is most likely to remind you of the syntax rules for function calls... ;)

      OTOH the Perl 5 ambiguity that I demonstrated by example in my above answer, is something that I still run into every now and then even after many years of using Perl. Because at the time when you add the parens in such a situation, you're probably not thinking about function calls, but rather about the Perl features involved in extending the expression you're editing: in the example of extending $line to (" " x $n).$line, that would be the repetition operator and string concatenation.
      It takes discipline to consciously pay attention to the fact that the expression which you're editing there is actually the first argument to a listop, and thus requires special care with parens – and if you're a human programmer, you're bound to sometimes overlook such things, resulting in a compiler warning in the best case, and an unnoticed bug in the worst.

      That's my experience, at least... Other people's brains may work differently. :)

[reply]
[d/l]
[select]
Re^2: Porting (old) code to something else [Perl 6 whitespace rules are not illogical!]
by Anonymous Monk on Feb 18, 2015 at 18:58 UTC
    "production code" -- oh, good. The perl-6 nags have started their coding standard bludgeonings based on some hypothetical production-ready status.

    You do know that Larry only announced his hope to make a real announcement something this year, perhaps, maybe, right?

[reply]

In Section Meditations