Proposal: easier syntax for multiple param aliases

[AlexDaniel]

See Raku/doc#1696.

Wouldn't it be better if instead of:

sub ordinated( :st(:nd(:rd(:th($num))))=-1 ) {

it was possible to write:

sub ordinated( :st:nd:rd:th($num)=-1 ) {

The current version is hard to read and hard to write, and the proposed variant is a syntax error anyway.

Grammar code in question:

rakudo/src/Perl6/Grammar.nqp

Lines 3097 to 3107 in 4fca947

	token named_param {
	:my $*GOAL := ')';
	:dba('named parameter')
	':'
	[
	| <name=.identifier> '('
	<.ws> [ <named_param> | <param_var> ] <.ws>
	[ ')' || <.panic: 'Unable to parse named parameter; couldn\'t find right parenthesis'> ]
	| <param_var>
	]
	}

[zoffixznet]

👎 from me: YAGNI. I don't see this as something that has much benefit to being slightly easier to write and we yet might need the suggested syntax for some other feature.

[treyharris]

@zoffixznet I just grepped all the .p6 I've ever written and it seems that when I define an alias, I'm more likely than not to define more than one. So either styles differ or I'm generally doing it wrong. 😛

Your comment on the syntax, though, is a point well-taken. Seems like a @TimToady waterbed-squashing problem?

[zoffixznet]

So either styles differ or I'm generally doing it wrong. 😛

IMO adding many ways to do the exact same thing is a sure way to make your documentation huge, burdening your users with a lot of information they don't have to learn. I know some like to throw around TIMTOWTDI as a justification for just that, but I think many overdo it and often don't consider long-term consequences.

People ask all the time what's the difference between .foo() and .foo:. They'll be asking the same for :foo(:bar($ber)) and :foo:bar($ber) and the answer will be that we thought of a cleaner syntax later on but had to keep old syntax too since people were using it already, so now we support and you have to learn both.

I know I naysay on these proposals a lot, but it just feels like people are ignoring the fact that we're into our third year of claiming to be a stable language. They still attempt to re-design cornerstone features and syntax and, to avoid spectest breakage, they pile their re-designs onto existing design and then throw in a TIMTOWTDI as a justification for their Frankenstein.

What will be the state of the language in 10 years? It will have warts, but I rather the warts be the fact that you have to type extra parentheses in places rather than learn 5 different syntaxes and worry they don't clash.

[jnthn]

I know I naysay on these proposals a lot

But thanks for doing so, so I don't feel like it's just me. :-)

but it just feels like people are ignoring the fact that we're into our third year of claiming to be a stable language

I think stability is more about being careful not to break user's existing code, though, which isn't what's being proposed here - it was suggested as additive. That said, every addition we make means there's:

• More to document
• More to teach
• More code in the compiler to maintain
• More spectests
• Potentially, something new to consider for optmization

So it had better pull its weight. I'm not personally convinced the change proposed here does that. I say "personally" because it just doesn't show up much at all in Perl 6 code I've written, but as @treyharris notes, styles differ. So the question for me is if there's much demand for this, such that it justifies all of the above.

Also, an implementation aside: named parameter aliases are a bit of a pain for compilation/optimization. We do special-case a single alias (that is, 2 names); 2 aliases (3 names) or more and you are thrown back to the slow-path binder and pay a huge overhead for them. For the case of just 2, the specializer doesn't yet handle them, meaning it's not as bad as the slow-path binder, but using aliases still prevents a bunch of optimizations. So we'd be introducing a shorter syntax that is only applicable in cases that are going to tank performance.

[vendethiel]

Is aliased params a feature used often enough that we need syntax for such cases?

[tisonkun]

Less is more. By the way, we have let and temp which are so similar. What's more, I don't see even they are so common that should be listed as spec(in fact we don't have one..). However, it happened and we have to keep backward compatibility.

I don't mean it's not worthy. But is it worthy to be as language core?

A language can become an unmaintainable mess if it includes every feature that yields marginally more concise code. -- Core Java 10th

[AlexDaniel]

This ticket is more suitable for the problem-solving repo but I'm no longer interested in the original proposal, so I think we can just close this.