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

LTA error message when passing to a typed slurpy array parameter in Rakudo #2811

Closed
p6rt opened this issue Jul 3, 2012 · 13 comments
Closed
Labels

Comments

@p6rt
Copy link

p6rt commented Jul 3, 2012

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

Searchable as RT113964$

@p6rt
Copy link
Author

p6rt commented Jul 3, 2012

From @masak

<seldon> Can slurpy parameters not be typed? I'm having trouble with
sub foo(Int *@​numbers) { }; Rakudo tells me "Nominal type check failed
for parameter '@​numbers'; expected Positional but got Array instead"
<masak> hm.
<jnthn> I believe they cannot be.
<masak> r​: sub foo(Int *@​numbers) {}; foo(5, 42)
<p6eval> rakudo ee8ca1​: OUTPUT«Nominal type check failed for parameter
'@​numbers'; expected Positional but got Array instead [...]
<masak> in any case, that's a crappy error message.
<masak> r​: say Array ~~ Positional
<p6eval> rakudo ee8ca1​: OUTPUT«True␤»
<masak> was gonna say.
* masak submits LTA rakudobug
<jnthn> It's missing the type info for some reason.
<jnthn> We should perhaps just forbid the type on slurpies at all though
<jnthn> As in, catch it much earlier at compile time and say "this won't work"
<masak> aye.
<masak> that's the conservative thing to do.

@p6rt
Copy link
Author

p6rt commented Oct 16, 2012

From @edwinst

$ ./perl6 -e 'sub foo(Int *@​ints) { say @​ints }; foo(1)'
Nominal type check failed for parameter '@​ints'; expected Positional but got Array instead
  in sub foo at -e​:1
  in block at -e​:1

$ ./perl6 --version
This is perl6 version 2012.09.1-30-g8230aef built on parrot 4.4.0 revision RELEASE_4_4_0

@p6rt
Copy link
Author

p6rt commented Oct 16, 2012

From sohtil@gmail.com

I just noticed this duplicates RT #​113964. Please merge.

@p6rt
Copy link
Author

p6rt commented Oct 16, 2012

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

@p6rt
Copy link
Author

p6rt commented Oct 16, 2012

From sohtil@gmail.com

Note that typed slurpy arrays are used in the spec in several places (see below).
For what it's worth, they seem very useful to me.

$ ack -a '\w\s+\*@​' # slightly edited

S06-routines.pod
1626​: sub limited_Dog_grep ($count, &block​:(Dog), Dog *@​list) {...}
1630​: sub limited_Dog_grep ($count, &block​:(Dog --> Bool), Dog *@​list) {...}

S29-functions.pod
314​: multi sub chrs( Int *@​grid --> Str )

S32-setting-library/Containers.pod
678​: multi method rotate ( @​array is copy​: Int $n = 1, Int *@​n --> Array ) is export

S32-setting-library/IO.pod
633​: method to(Str *@​command, *%opts --> Bool)
642​: method from(Str *@​command, *%opts --> Bool)

specs at​:
commit 1d76a26c7ea3b08c4faffcafd7a6d4ff344be8a3

@p6rt
Copy link
Author

p6rt commented Oct 16, 2012

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

@p6rt
Copy link
Author

p6rt commented Oct 16, 2012

From sohtil@gmail.com

RT #​115312 duplicates this bug.

@p6rt
Copy link
Author

p6rt commented Oct 8, 2014

From @usev6

The error message looks adequate now​:

$ perl6 -e 'sub foo(Int *@​ints) {}'
===SORRY!=== Error while compiling -e
Slurpy positionals with type constraints are not supported.
at -e​:1
------> sub foo(Int *@​ints⏏) {}
  expecting any of​:
  formal parameter
  constraint

But as it was pointed out above typed slurpy arrays are used in the spec in several places.

There are several skipped tests for typed slurpy params in S06-signature/slurpy-params.t. Should this ticket be closed (with a test for the current error message)?

1 similar comment
@p6rt
Copy link
Author

p6rt commented Oct 8, 2014

From @usev6

The error message looks adequate now​:

$ perl6 -e 'sub foo(Int *@​ints) {}'
===SORRY!=== Error while compiling -e
Slurpy positionals with type constraints are not supported.
at -e​:1
------> sub foo(Int *@​ints⏏) {}
  expecting any of​:
  formal parameter
  constraint

But as it was pointed out above typed slurpy arrays are used in the spec in several places.

There are several skipped tests for typed slurpy params in S06-signature/slurpy-params.t. Should this ticket be closed (with a test for the current error message)?

@p6rt
Copy link
Author

p6rt commented Jul 1, 2015

From @usev6

I found this Pull Request for rakudo, which implemented the error message "Slurpy positionals with type constraints are not supported"​:

rakudo/rakudo#160

So I guess, the skipped tests for slurpy positionals in S06-signature/slurpy-params.t should be replaced and the examples in the design documents should be removed as well. Any opinions?

1 similar comment
@p6rt
Copy link
Author

p6rt commented Jul 1, 2015

From @usev6

I found this Pull Request for rakudo, which implemented the error message "Slurpy positionals with type constraints are not supported"​:

rakudo/rakudo#160

So I guess, the skipped tests for slurpy positionals in S06-signature/slurpy-params.t should be replaced and the examples in the design documents should be removed as well. Any opinions?

@p6rt
Copy link
Author

p6rt commented Oct 27, 2015

From @jnthn

On Wed Oct 08 12​:36​:34 2014, bartolin@​gmx.de wrote​:

The error message looks adequate now​:

$ perl6 -e 'sub foo(Int *@​ints) {}'
===SORRY!=== Error while compiling -e
Slurpy positionals with type constraints are not supported.
at -e​:1
------> sub foo(Int *@​ints⏏) {}
expecting any of​:
formal parameter
constraint

But as it was pointed out above typed slurpy arrays are used in the
spec in several places.

There are several skipped tests for typed slurpy params in S06-
signature/slurpy-params.t. Should this ticket be closed (with a test
for the current error message)?

In Perl 6.christmas, we won't support typed slurpies. I've updated S06 to note they are a conjectural feature, and updated the tests to reflect this (and also to check for the typed exception the compiler throws in this case).

@p6rt
Copy link
Author

p6rt commented Oct 27, 2015

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

@p6rt p6rt closed this as completed Oct 27, 2015
@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