Skip to content
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

Long running unclosed quotes trigger unhelpful message #1808

Closed
p6rt opened this issue Jun 7, 2010 · 10 comments
Closed

Long running unclosed quotes trigger unhelpful message #1808

p6rt opened this issue Jun 7, 2010 · 10 comments
Labels
LTA Less Than Awesome; typically an error message that could be better

Comments

@p6rt
Copy link

p6rt commented Jun 7, 2010

Migrated from rt.perl.org#75592 (status was 'open')

Searchable as RT75592$

@p6rt
Copy link
Author

p6rt commented Jun 7, 2010

From @cognominal

I am probably a lousy programmer but I hit again and again that
unhelpful message.

How to reproduce :

eval "{\n\n\n\n\'}"

Unable to parse blockoid, couldn't find final '}' at line 1

Note that the opening quotes are many lines below the start of the
blockoid and there may be many statements between them.
So the line number in the error is unhelpful.

In the simplest case, the quote rules fails because the end of the
file has been reached. I don't see the need
to backtrack and to fail the blockoid.

In more complicated cases, the quote rule reduces but it eats way more
characters than the programmer intended
inluding '}' chars that should terminate blockoids. The result is
triggering the same message or some others. I don't know if there is a
way to detect the true problem instead of emitting spurious messages.
Probably we should indicate the
reduced quotes involving many lines as suspicious when failing to
reduce a blockoid. They are bad style anyway because
heredocs are the preferred style for many lines quoted stuff. But
heredocs are not implemented yet.

--
cognominal stef

@p6rt
Copy link
Author

p6rt commented Jun 8, 2010

From @moritz

Am 07.06.2010 23​:23, schrieb Stephane Payrard (via RT)​:

# New Ticket Created by Stephane Payrard
# Please include the string​: [perl #​75592]
# in the subject line of all future correspondence about this issue.
#<URL​: http://rt.perl.org/rt3/Ticket/Display.html?id=75592>

I am probably a lousy programmer but I hit again and again that
unhelpful message.

How to reproduce :

eval "{\n\n\n\n\'}"

Unable to parse blockoid, couldn't find final '}' at line 1

Note that the opening quotes are many lines below the start of the
blockoid and there may be many statements between them.
So the line number in the error is unhelpful.

In the simplest case, the quote rules fails because the end of the
file has been reached. I don't see the need
to backtrack and to fail the blockoid.

That's not what's happening.
The blockoid is embedded in the quote, so it fails first, and then the
quote rule fails.

If you're interested in fixing this, you might look at how STD.pm does
it. Some of its constructs are easily transferable into rakudo's
grammar, some not as easy (but need to be ported at some point anyway).

Cheers,
Moritz

@p6rt
Copy link
Author

p6rt commented Jun 8, 2010

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Jun 8, 2010

From @cognominal

Also implementing :​: will help for more precise errors reports. That one is one
pmichaud plate that is already full

On Tue, Jun 8, 2010 at 1​:36 PM, Moritz Lenz via RT
<perl6-bugs-followup@​perl.org> wrote​:

Am 07.06.2010 23​:23, schrieb Stephane Payrard (via RT)​:

# New Ticket Created by  Stephane Payrard
# Please include the string​:  [perl #​75592]
# in the subject line of all future correspondence about this issue.
#<URL​: http://rt.perl.org/rt3/Ticket/Display.html?id=75592>

I am probably a lousy programmer but I hit again and again that
unhelpful message.

How to reproduce :

eval "{\n\n\n\n\'}"

Unable to parse blockoid, couldn't find final '}' at line 1

Note that the opening quotes are many lines below the start of the
blockoid and there may be many statements between them.
So the line number in the error is unhelpful.

In the simplest case, the quote rules fails because the end of the
file has been reached. I don't see the need
to backtrack and to fail the blockoid.

That's not what's happening.
The blockoid is embedded in the quote, so it fails first, and then the
quote rule fails.

If you're interested in fixing this, you might look at how STD.pm does
it. Some of its constructs are easily transferable into rakudo's
grammar, some not as easy (but need to be ported at some point anyway).

Cheers,
Moritz

--
cognominal stef

@p6rt
Copy link
Author

p6rt commented Nov 17, 2012

From @coke

On Mon Jun 07 14​:23​:47 2010, cognominal wrote​:

I am probably a lousy programmer but I hit again and again that
unhelpful message.

How to reproduce :

eval "{\n\n\n\n\'}"

Unable to parse blockoid, couldn't find final '}' at line 1

Getting closer (I'm assuming the \n's above were meant to be newlines, but I did it both ways
below) although the given line numbers are wrong below​:

$ cat a.p6
eval "{\n\n\n\n\'}"
$ ./perl6 a.p6
===SORRY!===
Unable to parse expression in block; couldn't find final '}' at line 2, near "\\n\\n\\n\\n\\'"
$ cat b.p6
eval "{

\'}"
$ ./perl6 b.p6
===SORRY!===
Unable to parse expression in quote​:sym<apos>; couldn't find final "'" at line 7, near ""

--
Will "Coke" Coleda

1 similar comment
@p6rt
Copy link
Author

p6rt commented Nov 17, 2012

From @coke

On Mon Jun 07 14​:23​:47 2010, cognominal wrote​:

I am probably a lousy programmer but I hit again and again that
unhelpful message.

How to reproduce :

eval "{\n\n\n\n\'}"

Unable to parse blockoid, couldn't find final '}' at line 1

Getting closer (I'm assuming the \n's above were meant to be newlines, but I did it both ways
below) although the given line numbers are wrong below​:

$ cat a.p6
eval "{\n\n\n\n\'}"
$ ./perl6 a.p6
===SORRY!===
Unable to parse expression in block; couldn't find final '}' at line 2, near "\\n\\n\\n\\n\\'"
$ cat b.p6
eval "{

\'}"
$ ./perl6 b.p6
===SORRY!===
Unable to parse expression in quote​:sym<apos>; couldn't find final "'" at line 7, near ""

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Sep 14, 2015

From @coke

On Sat Nov 17 11​:40​:48 2012, coke wrote​:

On Mon Jun 07 14​:23​:47 2010, cognominal wrote​:

I am probably a lousy programmer but I hit again and again that
unhelpful message.

How to reproduce :

eval "{\n\n\n\n\'}"

Unable to parse blockoid, couldn't find final '}' at line 1

Getting closer (I'm assuming the \n's above were meant to be newlines,
but I did it both ways
below) although the given line numbers are wrong below​:

$ cat a.p6
eval "{\n\n\n\n\'}"
$ ./perl6 a.p6
===SORRY!===
Unable to parse expression in block; couldn't find final '}' at line
2, near "\\n\\n\\n\\n\\'"
$ cat b.p6
eval "{

\'}"
$ ./perl6 b.p6
===SORRY!===
Unable to parse expression in quote​:sym<apos>; couldn't find final "'"
at line 7, near ""

Slight improvements; line number in the second one is now only off by one, error messages now reference the file.

$ cat a.p6
eval "{\n\n\n\n\'}"
$ ./perl6 a.p6
===SORRY!=== Error while compiling a.p6
Confused
at a.p6​:1
------> eval "{\n\⏏n\n\n\'}"
$ cat b.p6
eval "{

\'}"
$ ./perl6 b.p6
===SORRY!=== Error while compiling b.p6
Unable to parse expression in single quotes; couldn't find final "'"
at b.p6​:6
------> <BOL>⏏<EOL>
  expecting any of​:
  single quotes
  term$ ./perl6 --version
This is perl6 version 2015.07.1-898-g3655638 built on MoarVM version 2015.08-34-g113c3b5

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Jan 25, 2019

From @AlexDaniel

I'm slightly confused by this ticket… isn't it resolved now? Nowadays you get an error message like this​:

Unable to parse expression in single quotes; couldn't find final "'" (corresponding starter was at line 2)

So while it blows up at the end of the file, it still mentions where the quote started. Sooo… fixed? I'm struggling to understand what these code samples were supposed to demonstrate.

On 2010-06-07 14​:23​:47, cognominal wrote​:

I am probably a lousy programmer but I hit again and again that
unhelpful message.

How to reproduce :

eval "{\n\n\n\n\'}"

Unable to parse blockoid, couldn't find final '}' at line 1

Note that the opening quotes are many lines below the start of the
blockoid and there may be many statements between them.
So the line number in the error is unhelpful.

In the simplest case, the quote rules fails because the end of the
file has been reached. I don't see the need
to backtrack and to fail the blockoid.

In more complicated cases, the quote rule reduces but it eats way more
characters than the programmer intended
inluding '}' chars that should terminate blockoids. The result is
triggering the same message or some others. I don't know if there is a
way to detect the true problem instead of emitting spurious messages.
Probably we should indicate the
reduced quotes involving many lines as suspicious when failing to
reduce a blockoid. They are bad style anyway because
heredocs are the preferred style for many lines quoted stuff. But
heredocs are not implemented yet.

@p6rt p6rt added the LTA Less Than Awesome; typically an error message that could be better label Jan 5, 2020
@JJ
Copy link

JJ commented May 7, 2020

From @AlexDaniel

I'm slightly confused by this ticket… isn't it resolved now? Nowadays you get an error message like this​:

Unable to parse expression in single quotes; couldn't find final "'" (corresponding starter was at line 2)

So while it blows up at the end of the file, it still mentions where the quote started. Sooo… fixed? I'm struggling to understand what these code samples were supposed to demonstrate.

Fixed, I guess. Also, eval is how EVAL.

@AlexDaniel
Copy link
Member

OK! Maybe there are other cases when it doesn't print a nice error message, in which case please file a bug report. But IIRC my fix resolved most of the issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LTA Less Than Awesome; typically an error message that could be better
Projects
None yet
Development

No branches or pull requests

3 participants