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

Calling a token 'any' calls for trouble #2083

Open
p6rt opened this issue Aug 21, 2010 · 8 comments
Open

Calling a token 'any' calls for trouble #2083

p6rt opened this issue Aug 21, 2010 · 8 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Aug 21, 2010

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

Searchable as RT77350$

@p6rt
Copy link
Author

p6rt commented Aug 21, 2010

From @moritz

22​:39 < moritz_> rakudo​: grammar A { token TOP { <any> }; token any {
'foo' | 'bar' } }; say A.parse('foo')
22​:39 <+p6eval> rakudo d1015f​: OUTPUT«Too many positional parameters
passed; got 2 but expected 1␤ in 'Any​::any' at line 1361​:CORE.setting␤
in 'A​::any' at line 22​:/tmp/PUiWn8O0Uy␤ in 'A​::TOP' at line
22​:/tmp/PUiWn8O0Uy␤ in 'Grammar​::parse' at line 5864​:CORE.setting␤ in
main program body at line
22​:39 <+p6eval> ..22​:/tmp/PUiWn8O0Uy␤»
22​:40 < moritz_> that's a bug, right?
22​:40 < pmichaud> well, the grammar is overriding the .any method
22​:41 < moritz_> pmichaud​: but it's not the overridden .any method that
is called, right?
22​:41 < pmichaud> moritz_​: I'm still trying to figure out what's
happening there.

@p6rt
Copy link
Author

p6rt commented Oct 22, 2011

From @coke

No change in the past year.

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Oct 22, 2011

@coke - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Oct 18, 2012

From @moritz

The problem is that the $*ACTIONS contextual is set to a type object
(used to be Any, now Mu), so $*ACTIONS.any existed, but caused an error.

commit 0973612366de17d6eab26e975663e63170e5d1d5 eased some of the pain
by switching it from Any to Mu, but the underlying problem is still there.

@p6rt
Copy link
Author

p6rt commented Apr 14, 2014

From @Mouq

On Thu Oct 18 02​:13​:15 2012, moritz wrote​:

The problem is that the $*ACTIONS contextual is set to a type object
(used to be Any, now Mu), so $*ACTIONS.any existed, but caused an error.

commit 0973612366de17d6eab26e975663e63170e5d1d5 eased some of the pain
by switching it from Any to Mu, but the underlying problem is still there.

00​:11 <Mouq> r​: grammar A { token TOP { <any> }; token any { 'foo' | 'bar' } }; say A.parse('foo')
00​:11 <camelia> rakudo-parrot 79167a, rakudo-jvm 79167a, rakudo-moar 79167a​: OUTPUT«「foo」␤ any => 「foo」␤␤»

Closeable with tests

@p6rt
Copy link
Author

p6rt commented Apr 14, 2014

From @moritz

On 04/14/2014 06​:11 AM, Alexander Moquin via RT wrote​:

On Thu Oct 18 02​:13​:15 2012, moritz wrote​:

The problem is that the $*ACTIONS contextual is set to a type object
(used to be Any, now Mu), so $*ACTIONS.any existed, but caused an error.

commit 0973612366de17d6eab26e975663e63170e5d1d5 eased some of the pain
by switching it from Any to Mu, but the underlying problem is still there.

00​:11 <Mouq> r​: grammar A { token TOP { <any> }; token any { 'foo' | 'bar' } }; say A.parse('foo')
00​:11 <camelia> rakudo-parrot 79167a, rakudo-jvm 79167a, rakudo-moar 79167a​: OUTPUT«「foo」␤ any => 「foo」␤␤»

Closeable with tests

The problem can still be reproduced with method names from class Mu, for
example 'so'​:

<moritz> m​: grammar A { token TOP { <so> }; token so { 'foo' | 'bar' }
  }; say A.parse('foo')
<camelia> rakudo-moar 07dcb2​: OUTPUT«Too many positional parameters
  passed; got 2 but expected 1␤ in method so at
  src/gen/m-CORE.setting​:834␤ in any !reduce at
  gen/moar/stage2/QRegex.nqp​:759␤ in any !cursor_pass at
  gen/moar/stage2/QRegex.nqp​:721␤ in regex so at
  /tmp/4Fzij7cVZH​:1…»

@p6rt
Copy link
Author

p6rt commented May 11, 2015

From @jdv

I added a test in S05-grammar/inheritance.t but I'm unsure if
this is a valid bug. If the default actions dispatch off the Mu
type object then this is expected behavior. Maybe they can be
sidestepped as a special case for grammar actions? Or at least
a better error message could be spit out.

@p6rt
Copy link
Author

p6rt commented Mar 12, 2016

From @moritz

The correct solution would be to track the presence or absence of an action class by an out-of-bounds mechanism, like a separate variable.

I just don't know how to do that without making parsing significantly slower.

@p6rt p6rt added the Bug 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