Re^2: Porting (old) code to something else

[Tux]

Of course I can :)

In perl6 the opening paren (() of a function cannot be separated from the function by whitespace:

Legal in perl5:

 my $foo = foo( 1 );          # A
 my $foo = foo(1);            # B
 my $foo = foo (1);           # C
 my $foo = foo      (    1    # D
           );

For reasons I explain in my style guide MY preference is C. Perl6 only supports A and B.

This is only an example. The syntax rules go deeper than that, causing the dot (.) to be special too, so that

my $foo = $object->method (1)
                 ->method (2)
                 ->method (3);

chaining as allowed in perl5 (break to a newline wherever you like), would NOT translate to

my $foo = $object.method(1)
                 .method(2)
                 .method(3);

This is bad (IMHO), see:

$ cat t.pl
use v6;

class C {
   has Int $.x is rw = 0;

   method foo (Int $i) { $!x += $i; return self; }
   method bar (Int $i) { $!x -= $i; return self; }
   }

C.new().foo(1).bar(2).say;
$ perl6 t.pl
C.new(x => -1)
$ cat t.pluse v6;

class C {
   has Int $.x is rw = 0;

   method foo (Int $i) { $!x += $i; return self; }
   method bar (Int $i) { $!x -= $i; return self; }
   }

C.new()
 .foo(1)
 .bar(2)
 .say;
$ perl6 t.pl
===SORRY!=== Error while compiling t.pl
Two terms in a row
at t.pl:11
------>  ⏏.foo(1)
    expecting any of:
        infix stopper
        infix or meta-infix
        statement end
        statement modifier
        statement modifier loop

This is because a leading dot (after whitespace) will see the next word as method on the current topic ($_) instead of as a method on the previvious "thing". As the previous line has no trailing semi-colon, I would prefer the default to be different. The perl6 core dev people state it is possible with a backslash:

cat t.pl
use v6;

class C {
   has Int $.x is rw = 0;

   method foo (Int $i) { $!x += $i; return self; }
   method bar (Int $i) { $!x -= $i; return self; }
   }

C.new()\
 .foo(1)\
 .bar(2)\
 .say;
$ perl6 t.pl
C.new(x => -1)

But do you want your code to look ugly like that? I do not!

[BrowserUk]

For reasons I explain in my style guide MY preference is C.

Ah! Okay.

No further rational discussion is possible (for me) here because I find your preferred style utterly abhorrent :)

[BrowserUk]

I did think of one serious -- and hopefully non-controversial -- question regarding your use of Slang for your module.

If at some point in the (hopefully far) future, it becomes necessary for someone else to take over your module -- someone who doesn't share your stylistic preferences -- how hard will it be for them to undo your use of Slang?

I'm not expecting an answer; but it's something to think about.

[Tux]

You'll get an answer, as this is a (very) good question to consider.

It there would not have been this slang (for me), this module - as it currently is - would not have happened at all. So what is better/worse?

My annoyance of having to write - what I consider - ugly code is so that I refuse to do so. Having this slang causes me to produce perl6 code - be it in a deviating style - with fun.

Conversation with many of the perl6 dev people have already proven this to be useful. I found several bugs in the core and have - together with perl6 people - also made some amendments.

The person(s) I am working with already concurred to use my style/slang. At least it is (very) consistent. The only thing I have to think about to make them happy is to not use tabs as leading whitespace (which already caused my Makefile to break a couple of times).

Warning: the vortex that'll draw you into perl6 development is strong. If you cannot handle the force, do not get near :)

[BrowserUk]

It there would not have been this slang (for me), this module - as it currently is - would not have happened at all. So what is better/worse?

Years ago I took a contract in the IT dept. of a very large, UK retailer renowned for doing things "their way". The code was in C; the platform OS/2 and their coding standards, whilst not extreme; slowed me down and frustrated me enough to seek a solution. (For more details and an amusing story see one of my earliest posts here.)

The upshot of which is that I used a C-beautifier and some editor macros to convert the house style to my preference when loading a source file; and back to the house style when saving.

This simple expedient allowed me to type my code utilising muscle memory; and more importantly to read code in the style to which I was accustomed; thus maintaining my productivity and avoiding a lot of frustration.

I fear that by building the stylistic adaption into the language, rather than providing an external tool to 'port' styles through a common set of choices, the result will be that a few years down the road when modules have passed through the hands and brains of many maintainers, it will end up being a hotch potch of different styles on a block-by-block basis enabled through the use of lexical pragmas.

That's a world of pain that I have no desire to have to maintain.