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

Zen slice on hashes: is %h{} the same as %h{*} or not? #51

Closed
lizmat opened this issue Jun 12, 2013 · 4 comments
Closed

Zen slice on hashes: is %h{} the same as %h{*} or not? #51

lizmat opened this issue Jun 12, 2013 · 4 comments

Comments

@lizmat
Copy link
Contributor

lizmat commented Jun 12, 2013

The zen slice on hashes is currently implemented as:

multi method postcircumfix:<{ }>() { self }

I think it should be implemented as:

multi method postcircumfix:<{ }>() { self.values }

to make it inline with %hash{*}. This would make it consistent with the zen slice of arrays.

And it would make it inline with S03:5161, which states: "The empty C<[]> and C<.[]> postfix operators are interpreted as a zero-dimensional subscript returning the entire array, not as a one-dimensional null slice returning no elements. Likewise for C<{}> and C<.{}> on hashes, as well as the C<< <> >>, C<< .<> >>, C<«»>, and C<.«»> constant and interpolating slice subscripting forms."

So I ran a spectest with %h{} returning the values of the hash, just as %h{*}, and the following spectests failed:

t/spec/S02-literals/hash-interpolation.t (Wstat: 0 Tests: 10 Failed: 2)
Failed tests: 5-6
t/spec/S02-literals/misc-interpolation.t (Wstat: 0 Tests: 46 Failed: 1)
Failed test: 4
t/spec/S02-literals/quoting.rakudo (Wstat: 0 Tests: 162 Failed: 1)
Failed test: 124
t/spec/S02-types/hash.t (Wstat: 256 Tests: 22 Failed: 0)
Non-zero exit status: 1
Parse errors: Bad plan. You planned 81 tests but ran 22.

The last one because it was trying to do a sort on *.value, which of course doesn't work on Ints. So from a spec testing point of view, this would be easily fixed.

However, the general feeling on #perl6 was, that the current implementation was the Right Way To Do It. Hence this issue, as the feeling on #perl6 was that the spec should be adapted, rather than the implementation. Which, by the way, is done the same (wrong) way in Niecza.

@Benabik
Copy link
Contributor

Benabik commented Jun 12, 2013

The empty [] and .[] postfix operators are interpreted as a zero-dimensional subscript returning the entire array

Simply replacing hash with array there gives "The empty {} and .{} postfix operators are interpreted as a zero-dimensional subscript returning the entire hash." I think the current behavior helps with interpolation where the {} or [] helps separate the array/hash from any following text.

@lizmat
Copy link
Contributor Author

lizmat commented Jun 12, 2013

On Jun 12, 2013, at 4:31 PM, Brian Gernhardt notifications@github.com wrote:

The empty [] and .[] postfix operators are interpreted as a zero-dimensional subscript returning the entire array

Simply replacing hash with array there gives "The empty {} and .{} postfix operators are interpreted as a zero-dimensional subscript returning the entire hash." I think the current behavior helps with interpolation where the {} or [] helps separate the array/hash from any following text.

On the other hand: @A[] could be seen as returning all .values of an array, and so could %h{}.

Liz

@masak
Copy link

masak commented Jun 12, 2013

<TimToady> on zen slices, .[] is supposed to be equivalent to @(), and .{} equivalent to %(), as a convenient contextualizer
<TimToady> .{} is specifically not the same as .{*}
* masak adds that to perl6/specs/issues

I think this issue can be closed now. lizmat?

@lizmat
Copy link
Contributor Author

lizmat commented Jun 12, 2013

Still thinks it could use some more explanation at S03:5161, but I can't think of any right now. So closing.

@lizmat lizmat closed this as completed Jun 12, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants