Yes, a slang could solve that, but not Slang::Tuxic, which is about whitespace for functions and methods.

You however show that perl6 takes away a lot of artistic freedom. I completely disagree with smls that the programmer will be happy with the decisions taken. The compiler will be happy, but us poor programmers that deviate slightly from that paved road will not be. All those small annoyances will have to be weighed against the goods that perl6 brings in order too keep the programmers using perl6.

Do NOT underestimate the FUN factor. I have said that a few times before, but FUN! is way more important than functionality.

I know both smls and BrowserUK will disapprove with using whatever slang, but without slang, there will be some amongst us that would never use the language because of the missing freedom.

I know both smls and BrowserUK will disapprove with using whatever slang, but without slang, there will be some amongst us that would never use the language because of the missing freedom.

The funny thing is, I think I'm almost (but only almost) as wedded to my preferred style as you are to yours. As far a Perl6 is concerned, I'm either 'lucky' (or I've arrived at my chosen style by dint of experience and going with what works), because from what I've seen, Perl6 requires spaces pretty much everywhere I would put them anyway; and prohibits them where I wouldn't put them.

Indeed, a big part of why I've steered clear of offering patches to perl5 itself, is because I find the prevailing 'style' of the sources -- especially when combined with the hotch potch of mixed styles of later additions and amendments -- almost completely unintelligible. On those occasions when I go source diving to try resolve or understand some problem, I end up reformatting whole tranches of sources to 'correct' for the whole "let's randomly skip a level of indent or two just in case there is someone out there who is still using an AMD-3a with its 64 character line width; and other such idiocies; I'm constantly annoyed by macros that have to be called as procedures instead of functions (instead of this: MYTYPE *p = (MYTYPE*)malloc( 1024 ); you have to use:

MYTYPE *p;
...
...
...
Newxc( p, 1024, MYTYPE, (MYTYPE*));
[download]

Which is just asinine.

But I am in the position of being mostly retired. I only take work I'm interested in; only by referral, and turn down more than I take.

But if I were you, I'd be very wary of becoming so wedded to your stylistic preferences that you're unprepared to compromise them.

Were you to come to me as a prospective employee, laying down the law that you couldn't possibly use the language I've chosen for my project, because it compromises your stylistic freedoms; and I don't think it would be a very long conversation.

---

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

Could a "slang" resolve this?

For some meanings of "resolve", I guess it could.
Though again there's a reason for why things are the way they are:

Allowing infix < without preceding space would conflict with the postcircumfix < > construct which is used in Perl 6 for indexing/slicing associative data structures (like hashes) with string keys.
As in %stuff<key> but not limited to explicit hash variables, i.e. it can follow arbitrary expressions:

$ perl6
> ('xx'..'zz').classify(*.substr(1))<z>
xz yz zz
> {aa => 11, bb => 22, cc => 33, dd => 44}<cc>
33
> %(<aa bb cc dd> Z=> (11, 22 ... *))<cc>
33
> sub foo { return {bar => 42} }
> foo<bar>
42
[download]

I believe in the general case, the compiler simply replaces ...<key> with ...{'key'}, causing the { } postcircumfix operator to be dispatched on the return-value object of the preceding expression at run-time (or die with a run-time error if the operator is not defined for that object's type).

The problem with code like 1<2 is that (as far as I understand it) as soon as the parser sees the opening angle bracket sticking to the right of an expression, it assumes it found an instance of the < > postcircumfix and tries to parse the following text accordingly.
If the actual text there does not match that expectation, the parser aborts with a syntax error. In this case, the error handling code is smart enough to look at the surroundings and figure out that you probably meant to use the < infix operator (numeric comparison) there, so it prints that instead of a generic a "syntax error".

Now in theory the parser could be written so it would try both possibilities (postcircumfix < > and infix <) when it sees an angle bracket after an expression like that, and continue parsing both variants until one of them hits a syntax error down the road and can be eliminated.
But I'm pretty sure that would violate the design principle of keeping the Perl 6 grammar as deterministic and "self-clocking" as possible, which seems to be very important to Larry Wall (and for which authors of slangs/macros or of Perl 6 syntax highlighters / IDEs etc. will probably be grateful).

So if you want your slang to only change the meaning of those simple cases (< between two number literals) which the compiler's error handling code can already detect anyway, that would probably be reasonably safe, but if you also want expressions like $number<5 to be interpreted as numeric comparisons, that would likely lead to all kinds of parsing difficulties.