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

Returning Failure from failed P6-level .parse #6450

Open
p6rt opened this issue Aug 17, 2017 · 11 comments
Open

Returning Failure from failed P6-level .parse #6450

p6rt opened this issue Aug 17, 2017 · 11 comments
Labels
RFC Request For Comments

Comments

@p6rt
Copy link

p6rt commented Aug 17, 2017

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

Searchable as RT131919$

@p6rt
Copy link
Author

p6rt commented Aug 17, 2017

From @AlexDaniel

See this commit​: rakudo/rakudo@9501eda

These roast commits​:
* Raku/roast@1fb68c4
* Raku/roast@b53616f

And this justification​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994

This blog post noticing the breakage due to the change​:
* https://gfldex.wordpress.com/2017/08/17/parsing-nothing/

And these thoughts about postponing it to v6.d​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160

I am confident that we will not be able to process this change and all potential breakage associated with it in ≈3 days before the release, so the revert is coming.

Personally, I don't mind rereverting it afterwards for inclusion in 2017.09, assuming we make sure to fix all modules that were relying on Nils being returned. However, I do see the point for postponing it till v6.d.

So should we feel adventurous and push this change as early as we can (in 2017.09, aftear at least one month)? Or is it better to be safe and wait for v6.d? Please discuss.

@p6rt
Copy link
Author

p6rt commented Aug 17, 2017

From @zoffixznet

On Thu, 17 Aug 2017 08​:50​:48 -0700, alex.jakimenko@​gmail.com wrote​:

See this...

See also timotimo++'s comment that TimToady cleared a revert if there were fallout​:
<timotimo> raschipi, gfldex, timtoady already said he'd retract the commit if there's ecosystem fallout, which you just demonstrated

https://irclog.perlgeek.de/perl6/2017-08-17#i_15031866

Personally, I don't mind rereverting it afterwards for inclusion in
2017.09

To me, it looks like a clear case for 6.d material. We made a promise to users that we won't make changes that break 6.c-errata changes and IMO the 6.c-errata roast changes due to this feature break that promise.

@p6rt
Copy link
Author

p6rt commented Aug 17, 2017

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

@p6rt
Copy link
Author

p6rt commented Aug 17, 2017

From @zoffixznet

On Thu, 17 Aug 2017 09​:11​:21 -0700, cpan@​zoffix.com wrote​:

To me, it looks like a clear case for 6.d material. We made a promise
to users that we won't make changes that break 6.c-errata changes and
IMO the 6.c-errata roast changes due to this feature break that
promise.

Though, since it's a method, we get the whole "can't easily change behaviour of a method between languages" problem...

@p6rt
Copy link
Author

p6rt commented Aug 17, 2017

From @lizmat

On 17 Aug 2017, at 17​:50, Aleks-Daniel Jakimenko-Aleksejev (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string​: [perl #​131919]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=131919 >

See this commit​: rakudo/rakudo@9501eda

These roast commits​:
* Raku/roast@1fb68c4
* Raku/roast@b53616f

And this justification​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994

This blog post noticing the breakage due to the change​:
* https://gfldex.wordpress.com/2017/08/17/parsing-nothing/

And these thoughts about postponing it to v6.d​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160

I am confident that we will not be able to process this change and all potential breakage associated with it in ≈3 days before the release, so the revert is coming.

Personally, I don't mind rereverting it afterwards for inclusion in 2017.09, assuming we make sure to fix all modules that were relying on Nils being returned. However, I do see the point for postponing it till v6.d.

So should we feel adventurous and push this change as early as we can (in 2017.09, aftear at least one month)? Or is it better to be safe and wait for v6.d? Please discuss.

My feeling is to put this towards 6.d. And possibly have that coincide with 2017.09.

The reason? This feature, like other features such as “is default” working on attributes, can *still* not be used on any module in the ecosystem, because one cannot be sure it won’t get run by a version of 6.c that does not have that feature already​: case in point, not gaining about 5% in performance in Text​::CSV because we cannot use “has $!foo is default()”.

I think we’ve collected so many incompatible features by now that we need a 6.d earlier rather than later. At least from the API point of view. AKA, make things work for 6.d, then start optimizing again :-)

@p6rt
Copy link
Author

p6rt commented Aug 17, 2017

From @lizmat

On 17 Aug 2017, at 18​:11, Zoffix Znet via RT <perl6-bugs-followup@​perl.org> wrote​:

On Thu, 17 Aug 2017 08​:50​:48 -0700, alex.jakimenko@​gmail.com wrote​:

See this...

See also timotimo++'s comment that TimToady cleared a revert if there were fallout​:
<timotimo> raschipi, gfldex, timtoady already said he'd retract the commit if there's ecosystem fallout, which you just demonstrated

https://irclog.perlgeek.de/perl6/2017-08-17#i_15031866

Personally, I don't mind rereverting it afterwards for inclusion in
2017.09

To me, it looks like a clear case for 6.d material. We made a promise to users that we won't make changes that break 6.c-errata changes and IMO the 6.c-errata roast changes due to this feature break that promise.

Hear hear!

@p6rt
Copy link
Author

p6rt commented Aug 19, 2017

From @AlexDaniel

The change was moved to v6.d in this commit​: rakudo/rakudo@d2278b4

On 2017-08-17 08​:50​:48, alex.jakimenko@​gmail.com wrote​:

See this commit​:
rakudo/rakudo@9501eda

These roast commits​:
*
Raku/roast@1fb68c4
*
Raku/roast@b53616f

And this justification​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994

This blog post noticing the breakage due to the change​:
* https://gfldex.wordpress.com/2017/08/17/parsing-nothing/

And these thoughts about postponing it to v6.d​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160

I am confident that we will not be able to process this change and all
potential breakage associated with it in ≈3 days before the release,
so the revert is coming.

Personally, I don't mind rereverting it afterwards for inclusion in
2017.09, assuming we make sure to fix all modules that were relying on
Nils being returned. However, I do see the point for postponing it
till v6.d.

So should we feel adventurous and push this change as early as we can
(in 2017.09, aftear at least one month)? Or is it better to be safe
and wait for v6.d? Please discuss.

@p6rt
Copy link
Author

p6rt commented Aug 19, 2017

From @AlexDaniel

I had to revert one of the nqp commits related to .parse​: Raku/nqp@d4d77b6

Here's a ticket for the module that was affected by the change​: css-raku/CSS-Module-raku#10

Most certainly we want this change back ASAP, but it had to be reverted for the release.

On 2017-08-19 05​:36​:36, alex.jakimenko@​gmail.com wrote​:

The change was moved to v6.d in this commit​:
rakudo/rakudo@d2278b4

On 2017-08-17 08​:50​:48, alex.jakimenko@​gmail.com wrote​:

See this commit​:

rakudo/rakudo@9501eda

These roast commits​:
*

Raku/roast@1fb68c4

*

Raku/roast@b53616f

And this justification​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994

This blog post noticing the breakage due to the change​:
* https://gfldex.wordpress.com/2017/08/17/parsing-nothing/

And these thoughts about postponing it to v6.d​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160

I am confident that we will not be able to process this change and
all
potential breakage associated with it in ≈3 days before the release,
so the revert is coming.

Personally, I don't mind rereverting it afterwards for inclusion in
2017.09, assuming we make sure to fix all modules that were relying
on
Nils being returned. However, I do see the point for postponing it
till v6.d.

So should we feel adventurous and push this change as early as we can
(in 2017.09, aftear at least one month)? Or is it better to be safe
and wait for v6.d? Please discuss.

@p6rt
Copy link
Author

p6rt commented Aug 21, 2017

From @AlexDaniel

It was removed completely for 2017.08 release.

Rakudo commit​: rakudo/rakudo@465d91a
Discussion​:  https://irclog.perlgeek.de/perl6-dev/2017-08-21#i_15048995
On 2017-08-19 15​:31​:01, alex.jakimenko@​gmail.com wrote​:

I had to revert one of the nqp commits related to .parse​:
Raku/nqp@d4d77b6

Here's a ticket for the module that was affected by the change​:
css-raku/CSS-Module-raku#10

Most certainly we want this change back ASAP, but it had to be
reverted for the
release.

On 2017-08-19 05​:36​:36, alex.jakimenko@​gmail.com wrote​:

The change was moved to v6.d in this commit​:

rakudo/rakudo@d2278b4

On 2017-08-17 08​:50​:48, alex.jakimenko@​gmail.com wrote​:

See this commit​:

rakudo/rakudo@9501eda

These roast commits​:
*

Raku/roast@1fb68c4

*

Raku/roast@b53616f

And this justification​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994

This blog post noticing the breakage due to the change​:
* https://gfldex.wordpress.com/2017/08/17/parsing-nothing/

And these thoughts about postponing it to v6.d​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160

I am confident that we will not be able to process this change and
all
potential breakage associated with it in ≈3 days before the
release,
so the revert is coming.

Personally, I don't mind rereverting it afterwards for inclusion in
2017.09, assuming we make sure to fix all modules that were relying
on
Nils being returned. However, I do see the point for postponing it
till v6.d.

So should we feel adventurous and push this change as early as we
can
(in 2017.09, aftear at least one month)? Or is it better to be safe
and wait for v6.d? Please discuss.

@p6rt
Copy link
Author

p6rt commented Aug 6, 2018

From @dwarring

On Mon, 21 Aug 2017 07​:38​:56 -0700, alex.jakimenko@​gmail.com wrote​:

It was removed completely for 2017.08 release.

Rakudo commit​:
rakudo/rakudo@465d91a
Discussion​: https://irclog.perlgeek.de/perl6-dev/2017-08-21#i_15048995
On 2017-08-19 15​:31​:01, alex.jakimenko@​gmail.com wrote​:

I had to revert one of the nqp commits related to .parse​:
Raku/nqp@d4d77b6

Here's a ticket for the module that was affected by the change​:
css-raku/CSS-Module-raku#10

Most certainly we want this change back ASAP, but it had to be
reverted for the
release.

On 2017-08-19 05​:36​:36, alex.jakimenko@​gmail.com wrote​:

The change was moved to v6.d in this commit​:

rakudo/rakudo@d2278b4

On 2017-08-17 08​:50​:48, alex.jakimenko@​gmail.com wrote​:

See this commit​:

rakudo/rakudo@9501eda

These roast commits​:
*

Raku/roast@1fb68c4

*

Raku/roast@b53616f

And this justification​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994

This blog post noticing the breakage due to the change​:
* https://gfldex.wordpress.com/2017/08/17/parsing-nothing/

And these thoughts about postponing it to v6.d​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160

I am confident that we will not be able to process this change
and
all
potential breakage associated with it in ≈3 days before the
release,
so the revert is coming.

Personally, I don't mind rereverting it afterwards for inclusion
in
2017.09, assuming we make sure to fix all modules that were
relying
on
Nils being returned. However, I do see the point for postponing
it
till v6.d.

So should we feel adventurous and push this change as early as we
can
(in 2017.09, aftear at least one month)? Or is it better to be
safe
and wait for v6.d? Please discuss.

I've had a chance to golf this (somewhat) from CSS​::Module. The following fails to parse if I revert Raku/nqp@d4d77b6

grammar Tst {
  rule local {​:i('local')'(' [ \'<ident>\' ] ')'}
  rule declaration-list { <test-prop> * }
  rule declarations {
  '{' <declaration-list> '}'
  }
  rule test-prop { (src) '​:' <local> +% ',' }
  }
say Tst.parse('{ src​: local(\'Gentium\') }', :rule<declarations> )

1 similar comment
@p6rt
Copy link
Author

p6rt commented Aug 6, 2018

From @dwarring

On Mon, 21 Aug 2017 07​:38​:56 -0700, alex.jakimenko@​gmail.com wrote​:

It was removed completely for 2017.08 release.

Rakudo commit​:
rakudo/rakudo@465d91a
Discussion​: https://irclog.perlgeek.de/perl6-dev/2017-08-21#i_15048995
On 2017-08-19 15​:31​:01, alex.jakimenko@​gmail.com wrote​:

I had to revert one of the nqp commits related to .parse​:
Raku/nqp@d4d77b6

Here's a ticket for the module that was affected by the change​:
css-raku/CSS-Module-raku#10

Most certainly we want this change back ASAP, but it had to be
reverted for the
release.

On 2017-08-19 05​:36​:36, alex.jakimenko@​gmail.com wrote​:

The change was moved to v6.d in this commit​:

rakudo/rakudo@d2278b4

On 2017-08-17 08​:50​:48, alex.jakimenko@​gmail.com wrote​:

See this commit​:

rakudo/rakudo@9501eda

These roast commits​:
*

Raku/roast@1fb68c4

*

Raku/roast@b53616f

And this justification​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994

This blog post noticing the breakage due to the change​:
* https://gfldex.wordpress.com/2017/08/17/parsing-nothing/

And these thoughts about postponing it to v6.d​:
* https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160

I am confident that we will not be able to process this change
and
all
potential breakage associated with it in ≈3 days before the
release,
so the revert is coming.

Personally, I don't mind rereverting it afterwards for inclusion
in
2017.09, assuming we make sure to fix all modules that were
relying
on
Nils being returned. However, I do see the point for postponing
it
till v6.d.

So should we feel adventurous and push this change as early as we
can
(in 2017.09, aftear at least one month)? Or is it better to be
safe
and wait for v6.d? Please discuss.

I've had a chance to golf this (somewhat) from CSS​::Module. The following fails to parse if I revert Raku/nqp@d4d77b6

grammar Tst {
  rule local {​:i('local')'(' [ \'<ident>\' ] ')'}
  rule declaration-list { <test-prop> * }
  rule declarations {
  '{' <declaration-list> '}'
  }
  rule test-prop { (src) '​:' <local> +% ',' }
  }
say Tst.parse('{ src​: local(\'Gentium\') }', :rule<declarations> )

@p6rt p6rt added the RFC Request For Comments label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Request For Comments
Projects
None yet
Development

No branches or pull requests

1 participant