$hr->{$_} = 1 for @$arr;
[download]

Though I'd probably write just

@{$hr}{ @$arr } = ();
[download]

This idea will certainly work!

I personally try to avoid using undef as an intentional value because:
a) this adds a complication about exists(), defined() later in the code,
b)If you have to export something with an "undef" value to something else other than Perl what do you use? or for that matter even it its Perl, why not 0 or 1 which is easier to parse? undef throws an extra third case into mix. Sometimes this makes sense like SQL's NULL, but why throw that in there if you don't need to?
c) it doesn't save any memory or execution time.

We are getting a bit off topic, but this is a hash slice. To get this work with the =1 idea, I think something like the below is required. There isn't foreach, but there is still a loop (except in the enumerated first case).

I personally like the $hr->{$_} = 1; syntax because it makes clear that we are de-referencing a hash reference.

A short thing about hash slice is at hash slice. My foreach loop can be replaced with this..

#foreach my $num (@$arr)
#{
   #any one of these does the same thing...
   #pick one...
   @$hr{@$arr}   = (1,1,1);
   @$hr{@$arr}   = map{1}@$arr;
   @{$hr}{@$arr} = map{1}@$arr;
#}
[download]

Oh, the map{1} generates an "@something" that has the same number of "1's" as there are elements in the input @$arr although here it is "anon", having no explicit name. Here that output of the map is used (ie, it is not a "bare" map). In this case, there is still a loop and we've just made the situation more confusing. Clarity of code is important and just because some implementation uses fewer lines doesn't mean that it is faster.

@$hr{@$arr}   = (1) x @$arr;
[download]

Jenda
Enoch was right!
Enjoy the last years of Rome.

Has there ever been an array involved? I think it's always been a list of values on the stack.

I think it's always been a list of values on the stack.

I think they (c/c++ programmers) call that an array :)

Nope. C doesn't return arrays on the stack and neither does Perl.

I recommend: "Advanced Perl Programming" by Srinivsan as a good reference for those interested about Perl internals.

I personally think that "bare maps...maps that don't use the output of the map" are not a good idea although other Monks would disagree.

I guess a few things got mixed together in this thread.

@output = map{some code}@input;
[download]

In older versions of Perl the @output will be created whether you give it a name like: @output or not. In other words there will be some @some_anon_thing for which you don't know the "name". I understand this has been fixed as of 5.10. So a version like Perl 5.6 has a "penalty" for a bare map.

On the style issue, I use map{} for short transformations where I use the output of the map{}, maybe @$aref or some such thing. If it gets hairy, I use a foreach(). I personally don't use "bare" map{}'s as a shorthand foreach(). Now doing so is completely legal and so certainly doesn't rise to the level of "hey that's wrong"! I prefer foreach in those situations partly because I have the thing we are looping over right there at the start of the statement and also that since I use map in consistent style, I can see immediately that we are going some kind of transformation, deg F to deg C or whatever. Also Perl is terse enough that I don't see the need to save a few characters by "bare" map vs foreach. Now sometimes the situation arises where I use a map{} within a foreach, like foreach (map{...}@input), but that is using the output of the map and fits with the short transformation idea.

I am sure that others have different opinions. I've tried to explain what I do and why - I hope that was understandable and appears rational and consistent. I'm not the "code police".

Coding has a lot of "art" to it. And there are all kind of exceptions for every "rule".

In older versions of Perl the @output will be created whether you give it a name like: @output or not.

Wrong. It doesn't now, and it never did. What it did was push a collection of SVs on an internal stack. But it didn't package that list into an array structure. And don't confuse what happens in the implementation with what happens on the language level.

I understand this has been fixed as of 5.10.

Off by more than 4 years. The bug was fixed¹ as of 5.8.1, which was released in Sep 2003. Oh, and BTW, 5.10 is over 2 years old - can we please stop treating 5.10 as something new and scary? Jesse is gearing up to release 5.12-RC0 very soon.

¹The fix turned out to be a one line patch. Can you imagine, for years people tried to let programmers dance to the drum of language (quite opposite of what Perl is supposed to be), while the fix was rather trivial. And now, 6.5 years down the road, people still use the argument to argue against a map in void context.²

²I think only people that always use the return value of print are allowed to whine about a map used in void context.