[% setvar title hash slicing %]

This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/


hash slicing


  Maintainer: David Nicol <perl6rfc@davidnicol.com>
  Date: 7 Sep 2000
  Mailing List: perl6-language-data@perl.org
  Number: 201
  Version: 1
  Status: Developing


a more concise syntax for producing subsets of hashes.



Instead of

	%subhash = map { f($_) ? ($_, $hash{$_}) : () } keys %hash;	# lengthy

one may now write

	%subhash = %hash{f($_)};	# code block f($_) will be evaluated for Truth over all the keys

syntactically identifiable degenerate cases

Additionally, these special cases are recognized:

	%subhash2 = %hash{@a};		# %subhash2 = map {($_, $hash{$_})} @a
	%subhash3 = %hash{$s};		# $subhash3{$s} = $hash{$2}

Otherwise, %subhash2 and %subhash3 would become either empty or simple copies, depending on the Truth of @a and $s, which would be misleading.

the function may be evaluated "with" the hash as well as "with" the key

In addition to the default scalar $_ being set to each key in the hash being sliced, the "default hash" %_ may also be lexically aliased to the hash being sliced. In the event that a "with" keyword is adopted which has a different effect, that effect will occur so that the element selection function is evaluated for truth for each key, with the hash.

this means that

	%subhash = map { $hash{$_} =~ /string/ ? ($_, $hash{$_}) : () } keys %hash;

can be generalized to

	%subhash = %hash{ $_{$_} =~ /string/ };

which is more general. All on the same line it looks unnecessary, but if the filtering function was a big hairy monster and you wanted to create a dozen subhashes all with different names it would same a lot of copying.

	%subhashA = %hashA{ Criteria };
	%subhashB = %hashB{ Criteria };
	%subhashC = %hashC{ Criteria };
	%subhashD = %hashD{ Criteria };


When I suggested a syntax extension that used

	%hash_name{something in here}

it was roundly misread as a data access. Adoption of this proposal will fill the curious apparent hole left by the validity of the other slicing operations in what I hope is a reasonable way.


The rewrites suggested above suffice as a reference implementation; optimizations may be possible due to disappearance of various intermediate temporary storages.

a framework for providing visibility of the magic $_ and %_ inside the filtering functions (in threaded environments) will be required.