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

rakudo silently ignores remaining code after unmatched pod #1002

Closed
p6rt opened this issue May 19, 2009 · 7 comments
Closed

rakudo silently ignores remaining code after unmatched pod #1002

p6rt opened this issue May 19, 2009 · 7 comments
Labels

Comments

@p6rt
Copy link

p6rt commented May 19, 2009

Migrated from rt.perl.org#65782 (status was 'resolved')

Searchable as RT65782$

@p6rt
Copy link
Author

p6rt commented May 19, 2009

From @azawawi

Given the following​:

"1".say;
=begin pod
=end pod1
"2".say;

The output is only "1" but should be "1\n2" or at least a runtime
error message for unmatched POD.

Regards,
Ahmad M. Zawawi

@p6rt
Copy link
Author

p6rt commented May 19, 2009

From @pmichaud

On Tue, May 19, 2009 at 12​:30​:53AM -0700, Ahmad Zawawi wrote​:

Given the following​:

"1".say;
=begin pod
=end pod1
"2".say;

The output is only "1" but should be "1\n2" or at least a runtime
error message for unmatched POD.

Rakudo is simply following STD.pm here, and STD.pm (r26884) allows
any pod identifier to go to the end of the file.

S02​:3319 seems to indicate that the "=begin END" form is special,
which implies to me that the non-END forms should indeed have
the required closing marker. If we can get confirmation that
only the "=begin END" is special, then I'll adjust Rakudo's
grammar to follow that (and possibly STD.pm as well).

Thanks!

Pm

@p6rt
Copy link
Author

p6rt commented May 19, 2009

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

@p6rt
Copy link
Author

p6rt commented May 19, 2009

From @masak

Patrick (>), Ahmad (>>)​:

Given the following​:

"1".say;
=begin pod
=end pod1
"2".say;

The output is only "1" but should be "1\n2" or at least a runtime
error message for unmatched POD.

Rakudo is simply following STD.pm here, and STD.pm (r26884) allows
any pod identifier to go to the end of the file.

S02​:3319 seems to indicate that the "=begin END" form is special,
which implies to me that the non-END forms should indeed have
the required closing marker. If we can get confirmation that
only the "=begin END" is special, then I'll adjust Rakudo's
grammar to follow that (and possibly STD.pm as well).

Even if the pod-identifier-going-to-the-end-of-the-file behaviour is
correct, isn't it a problem in itself that an '=end' directive without a
corresponding '=begin' directive goes unnoticed, both by Rakudo and STD?
S26 seems to assume that '=begin'/'=end' directives always match up
(again with the exception of '=begin END').

My point is that there are two things that are unmatched here, the
'=begin pod' and the '=end pod1'. I think both should give fatal errors.

@p6rt
Copy link
Author

p6rt commented May 19, 2009

From @TimToady

On Tue, May 19, 2009 at 10​:24​:41AM -0500, Patrick R. Michaud wrote​:
: On Tue, May 19, 2009 at 12​:30​:53AM -0700, Ahmad Zawawi wrote​:
: > Given the following​:
: >
: > "1".say;
: > =begin pod
: > =end pod1
: > "2".say;
: >
: > The output is only "1" but should be "1\n2" or at least a runtime
: > error message for unmatched POD.
:
: Rakudo is simply following STD.pm here, and STD.pm (r26884) allows
: any pod identifier to go to the end of the file.
:
: S02​:3319 seems to indicate that the "=begin END" form is special,
: which implies to me that the non-END forms should indeed have
: the required closing marker. If we can get confirmation that
: only the "=begin END" is special, then I'll adjust Rakudo's
: grammar to follow that (and possibly STD.pm as well).

STD.pm is now adjusted. :)

Larry

@p6rt
Copy link
Author

p6rt commented Jun 3, 2009

From @pmichaud

Rakudo now mostly matches STD.pm; at least to the extent of resolving
the issue identified in this ticket.

Closing ticket, thanks!

Pm

@p6rt
Copy link
Author

p6rt commented Jun 3, 2009

@pmichaud - Status changed from 'open' to 'resolved'

@p6rt p6rt closed this as completed Jun 3, 2009
@p6rt p6rt added the spec label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant