Make `$` sigil optional for scalar variables in 6.e

[lizmat]

When people are coming to Raku (and they don't have any Perl background), many of them are put off Raku because of sigils. Reasons:

• they hate Perl, Perl has sigils, therefore they hate Raku
• if there is not hate, then sigils are seen as line noise, rather than as helpful in understanding.

For Raku users, especially if they have a Perl background, sigils are natural. So often we (Raku users) cannot imagine sigils being an issue.

Back in 2020, Martin Tourneboeuf (tinmarino) created a slang Slang::Nogil, which never really worked and ultimately bitrotted completely. A new version of Slang::Nogil was created by yours truly, using a Rakudo grammar feature added in 2023.

In Allowing for fewer dollars I describe the reasons for making the $ sigil optional, at least in variable definitions.

The question here is: should this feature become standard in 6.e. And if so, should that include signatures as well (which it currently doesn't).

[librasteve]

I am against this proposal.

Why?

There is a conversion pain from non sigil languages like Python, sure.

But a good Raku introduction can straightforwardly explain the design. And it is consistent (more so than perl) and useful.

With this idea, however, we will have balkanisation of learning materials … some will lead with non sigils, some with sigils. Chaos.

Poor newcomers are anyway faced with a big learning curve vs the Python minimalism. This additional confusion is going to multiply that.

I get that Raku is a timtowdi space, but imho the NoSigil variant is correctly located as a slang / module

[arunvickram]

I second @librasteve's opinion.

A counter-argument to the sigils potentially hampering the further adoption of Raku would be the fact that PHP uses $ for its variables regardless of container type, and it's effectively the backbone of the internet. In Raku, I think there's even more meaning behind having $ be the prefix for scalar variables especially when considering functions like cas or atomic-*.

I think there are more systemic hurdles to Raku's adoption such as there not being a really extensive static analyzer (which is a huge undertaking I admit) that if addressed, would significantly help with bringing potentially new Raku programmers.

[jubilatious1]

I hadn't learned sigils before, but they seem fine in Raku. Much cleaner than in Perl.

Never understood why Perl (and now Raku), didn't give rise to better-looking fonts.

Here's a recently released font, Myna, which promises:

"Myna is a monospace font which aims to bring harmony to your editor by treating symbols as first-class glyphs alongside alphanumeric characters."

https://github.com/sayyadirfanali/Myna

[0rir]

Against for the reasons @librasteve gives and others. Sigils are helpful info. Sigils create namespaces.

"At least in variable definitions" has me wondering if this purification of Raku will be as seductive as hoped. And if it is, how the sigilers and the sigilless will interact.

[ohmycloud]

Make $ sigil optional for scalar variables may not be a good idea. It's a inconsistent language design:

If $foo and foo both refer to scalars, but you still require @array and %hash, you've created an arbitrary asymmetry. Why can scalars drop their sigil but collections can't? This inconsistency is harder to teach and justify than a consistent system.

[ab5tract]

@ohmycloud raises a great point. However, I think there is a way through: in this pragma, only scalar containers should be allowed.

I'm honestly on the fence about this. I do think the fragmentation concerns are very valid. However I can imagine an alternative world where there are no sigils and no scalar vs array vs hash distinction and in that world the experience of writing Raku is more or less exactly the same as it ever was.

It may be worth remembering a partial motive for sigils, though, which is that code should be easily parsed by a human in a text editor with no syntax highlighting. Of course Huffman coding and TMTOWTDI both work both for and against that goal, so it's not like the language is new to this friction -- or even that we want to hold it as a steadfast design goal going forward.

[arunvickram]

@ab5tract My opinion probably doesn't hold as much weight as lizmat's or that of another maintainer of the language, but I would generally err on the side of making a change like this a slang rather than a total language design change that is forced upon the programmer. That way, the programmer knows what tradeoffs they're making by opting in to Nogil.

I think because Raku has these sigils, it can unambiguously have operators like x for string repetition or o for function composition which would be much harder to pull off in a language like Python where lots of functions might have x or o as a function parameter or a local variable. Whereas in Raku, we can simply use $x or $o and have them coexist with x or o with little ambiguity.

I think that ironically because the sigils are set as a sort of basic ground rule for 'default' Raku, it actually allows people to do TMTOWDI much better, and I think that a slang is a great compromise.

[ab5tract]

@arunvickram Thanks for sharing your opinion. Everyone's opinion counts! To that end: I think you've swayed me to land more firmly in the "no" camp.

It could be an interesting experiment for a slang to take on, as you say. But in the end I think this should be a community module, not directly available in core.

Since my previous comment, I've been trying and failing to imagine how twigils would fit into a sigil-free Raku.

[lizmat]

FWIW, in my view if you need twigils, you need sigils.

I would like to make sigils optional for those cases where they really don't serve a lot of purpose:

sub double(i) { i * 2 } 
for @values -> i { say double i }

I bit artificial example, but I hope it makes sense :-)

Also, if the decision is to keep it as a slang, there should maybe be some changes in the Raku grammar to make this easily possible (aka, without needing to rewrite large parts of the grammar in the slang).

But @arunvickram makes good points :-) So maybe this is a bad idea after all.

[ab5tract]

Also, if the decision is to keep it as a slang, there should maybe be some changes in the Raku grammar to make this easily possible (aka, without needing to rewrite large parts of the grammar in the slang).

This seems like a fine prerogative to me. Maybe Slang::Nogil can be further developed in parallel to some other slang that would also benefit from alterations to the Raku grammar? The idea being to ensure that those alterations aren't targeted at only the needs of "nogil".

[2colours]

PHP also has $ sigil - that's not to say it's a beloved feature but it doesn't seem to be an absolute showstopper. As much as I understood, Ruby also has notations that resemble sigils. And anyway, who doesn't like a few dollars more. :P

Jokes aside, $ is really the easiest-to-grasp sigil in Raku. I don't feel strongly about it.

As a general principle, I think it's a risky idea to extinguish the Perl from Raku. There is some sort of natural divergence and that's okay - however, one of the biggest strengths of Raku (I'm sure @jubilatious1 would agree - but do correct me if I'm wrong) is still the text-processing one liners and such. In general, this is a huge language that has been developed to be Perl for too long. Removing Perlisms should be done with extra caution and imo stronger justification than "it will remind people of Perl and they don't like Perl". We could end up in a jenga situation.

[lizmat]

Closing as this definitely is not reaching consensus (other than: don't do that :-)