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
Confusion in precedence with <<$foo>>[0] #6371
Comments
From @briandfoyIt seems that term precedence with << >> gets confused. I also asked this on StackOverflow: https://stackoverflow.com/q/44872419/2766176 my $string = '5+8i'; { { { |
From @jnthnOn Mon, 03 Jul 2017 05:46:46 -0700, comdog wrote:
The << >> quoting construct interpolates. The rule for interpolation of method calls, indexing, etc. after a scalar is that there may be one, but it may only end with a ], ), } or >.
When the variable is encountered inside of the interpolating quoting construct, which is being parsed by the quoting parser, it calls back into the Perl 6 main language parser. This parses a variable and optionally a postfix. The >>[0] is a valid postfix, where >> is the hyper-operator and [0] is the indexer. Therefore the $string>>[0] is taken as the thing to interpolate. It then hands back control to the quoting parser.
This is complaining that $number was used before its declaration was complete, which is indeed the case because at we are still inside of the quoting construct. I can see the potential for a human reader to be confused, but the Perl 6 parser is not in the least bit confused. There isn't any question as to what will parse the >>: if the main language parser understands it and wants it, then it gets it, because the quoting parser doesn't get a say again until the main language parser has done its bit. This is the same reason that you can do stuff like: say "Foos: @foo.join("bar")" And there isn't a bit of confusion so far as Perl 6 is concerned that the inner " is opening a new string, not closing the one we were already in. Granted it's maybe kinder to the reader to write it with single quotes inside of the string. But nestings of main language => quote parser => main language => quote parser will Just Work, each eating as much as it understands (or until seeing its terminator) before giving up control. /jnthn |
The RT System itself - Status changed from 'new' to 'open' |
@jnthn - Status changed from 'open' to 'rejected' |
From @briandfoyOn Mon, Jul 3, 2017 at 11:09 AM, jnthn@jnthn.net via RT
I think there are two improvements here: * a better explanation of interpolation and what's allowed there (such * a better explanation of the process. I wouldn't have expected * perhaps a better error message. We know we are inside a quoting |
From @geekosaurPerhaps this example should be provided somewhere as a 'gotcha'. On Mon, Jul 3, 2017 at 11:09 AM, jnthn@jnthn.net via RT <
-- |
From @AlexDanielI don't really want to start another ticket for what I'm about to suggest, therefore I'll reopen this one. Not so long ago I filed this ticket: The underlying issue is exactly the same. And it has actually happened during whateverable development, so it is not some kind of a thought exercise. Therefore, I think that we should actually try to improve the error message somehow. And here's my idea. What if the error message said something like this: ===SORRY!=== Error while compiling -e Please suggest a better way to put it, but the idea is quite simple: if we are inside another language that was started on a different line, why not say where exactly it was started? There may be cases when this additional line will not give anything useful, but generally it will make the error message Truly Awesome™. On 2017-07-03 10:59:54, allbery.b@gmail.com wrote:
|
@AlexDaniel - Status changed from 'rejected' to 'open' |
From @TimToadyWe now warn on the ambiguity of >> or » when used where it could easily be intended as either a hyper or the quotewords terminator. While we could, in theory, do some lookahead to try to suppress this warning in some cases, it will be brittle in the face of languages that mutate the postfix space, so I think it's better to just warn outright and let people disambiguate with whitespace or a suitable change to the hyper or quote delims. (As for retargeting this ticket to the more general case of multiline quote errors, please note that a runaway hyper is not a kind of quote, and that we already warning on runaway quotes that cross line boundaries. Also, the problem here is essentially independent of multi-line-ness. So I've changed the title of this bug back to the original, since that's the problem we're fixing.) |
1 similar comment
From @TimToadyWe now warn on the ambiguity of >> or » when used where it could easily be intended as either a hyper or the quotewords terminator. While we could, in theory, do some lookahead to try to suppress this warning in some cases, it will be brittle in the face of languages that mutate the postfix space, so I think it's better to just warn outright and let people disambiguate with whitespace or a suitable change to the hyper or quote delims. (As for retargeting this ticket to the more general case of multiline quote errors, please note that a runaway hyper is not a kind of quote, and that we already warning on runaway quotes that cross line boundaries. Also, the problem here is essentially independent of multi-line-ness. So I've changed the title of this bug back to the original, since that's the problem we're fixing.) |
@TimToady - Status changed from 'open' to 'resolved' |
From @zoffixznetOn Tue, 04 Jul 2017 10:29:50 -0700, larry wrote:
I moved[^1] the warning to the point when we parsed a hyper and are So now it still warns for stuff like: my $number = <<$string>>[0]; put "Type: " ~ $number; But no longer warns for cases like: my $number = <<$string>>; Which I think are far more common (e.g. `run «cal $year»`) and there's no hyper intended there, |
Migrated from rt.perl.org#131695 (status was 'resolved')
Searchable as RT131695$
The text was updated successfully, but these errors were encountered: