New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

You can have colonpairs in identifiers. What's the justification? #1753

Closed
AlexDaniel opened this Issue Feb 2, 2018 · 7 comments

Comments

Projects
None yet
5 participants
@AlexDaniel
Member

AlexDaniel commented Feb 2, 2018

From the docs:

Identifiers can contain colon pairs. The entire colon pair becomes part of the name of the identifier.

Here is a nicer example of that:

my $foo:bar<2> = 5;
say $foo:bar(1+1) # OUTPUT: «5␤»

… but why?

This is probably some material for faq-why (“Why things are the way they are in Perl 6”).

@AlexDaniel AlexDaniel added the docs label Feb 2, 2018

@JJ

This comment has been minimized.

Contributor

JJ commented Feb 3, 2018

@zoffixznet

This comment has been minimized.

Member

zoffixznet commented Feb 4, 2018

… but why?

We already have two reasons in core:

  1. sub infix:<+> uses the main name as a category of the op and the colonpair as the symbol for the op.
  2. In grammars, we have proto regexes. token foo:sym<bar> is one of the variations of foo token and the value of :sym colonpair can be used inside of it for matching that string.

Since colonpairs are allowed in identifiers for the above cases, it naturally extends to $foo also having them allowed.

The Slang-writers can get all the QASTs for colonpairs in <colonpair> token part of the <longname>

@AlexDaniel

This comment has been minimized.

Member

AlexDaniel commented Feb 4, 2018

Why they must be pairs? Or why do the use colons at all?

Why is this allowed at all. FWIW, there are many things I wish we had written justification for, but I was unsure if this should be included in the docs. Now I learned that there were plans for this, so perhaps more tickets to come :)

Anyway, Zoffix++, this explanation is short and very clear, I like it.

@TimToady

This comment has been minimized.

Member

TimToady commented Feb 4, 2018

For many aspects of the design, we asked ourselves if there was any generalization that we could achieve without adding cognitive stress to the user. When you already need to be able to name operators uniquely, you can go one of a number of ways: you can force everyone to give things an extra name that fits into the alphanumerics and provide some out-of-band way of mapping them to actual operators, or you can do the Lisp thing and define anything space-delimited as a name, or you can take the custom (read: non-extensible) approach that languages like C++ do. Or, you can come up with a general mechanism to allow quoting or string mapping within special names. We already had the colon pair mechanism available, so it was a no-brainer to use that to extend any name that needs to be able to quote uniquefying but non-standard characters (or other other information with a unique stringification to such characters). The operator names and parsing names mentioned by Zoffix++ are just two special reserved cases of that much huger namespace of names that are extended by one or more pairs. We don't really know how such names will be used in the future, but I guarantee you someone will think of more use cases for names that most naturally identify something uniquely through the use of non-alphanumerics.

@skids

This comment has been minimized.

Contributor

skids commented Feb 12, 2018

To add to the list of established usages of this, module versioning is one, per S11.

Open question: in module versioning the order of the adverbs does not matter. So should
this be the same variable, or is that behavior peculiar to module names?

$ perl6 -e 'my $bar:f<1>:g<2> = 42; say $bar:g<2>:f<1>;'
===SORRY!=== Error while compiling -e
Variable '$bar:g<2>:f<1>' is not declared. Did you mean '$bar:f<1>:g<2>'?
at -e:1
------> my $bar:f<1>:g<2> = 42; say ⏏$bar:g<2>:f<1>;
@JJ

This comment has been minimized.

Contributor

JJ commented Feb 26, 2018

Should we make a synopsis of what's been said here to the documentation?

@JJ JJ self-assigned this Feb 26, 2018

@AlexDaniel

This comment has been minimized.

Member

AlexDaniel commented Feb 26, 2018

@JJ there was an idea on #114 that there should be a faq-why page that would explain some things about the language design. We can start the page with this, yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment