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.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.