First of all zzspectrez , let me say that this is an excellent example of what every post should look like. Sample code, input, output and good description. ++ for that alone.

Second of all, regarding changing the value of $". Messing with any special variable when you are not obfuscating and have a perfectly good other way to do it is a bad idea. Sometihng like assigning a new value to one of these beasties can have really strange unpredictable effects as you expand your code and, should you miss you did it somewhere else or should you call a sub that was altered for one purpose by changing one of these, you will quickly get yourself really confused. Fastolfe suggests looking into join above and I have to urge you to do the same. That would look sometihng like :

print "SUB4: 2nd way\n";
for my $x (@data){
         print join "", @$x, "\n";
}
[download]

<myExperience>
$mostLanguages = 'Designed for engineers by engineers.';
$perl          = 'Designed for people who speak by a linguist.';
</myExperience>
[download]

I didnt think of doing it that way. Thanks, that is another way. I agree. Messing with the special variables is not the best way to do it. However, I was looking for the example of what caused the introduction of the spaces when the list was printed within double quotes. Modifying $" was just for verification that it would prevent it. It was more of understanding why perl was reacting the way it was in that case then best way to prevent it.

Would not just printing the list like I did in the first example of using my_sub4() -- print @$x,"\n" -- without interpolation be better since it has the same output without the use of an additional function call?

This actually brings up another interesting realization about what perl is doing. When interpolating a list within double-quoted strings, the elements are seperated by the value of $" which default is a space. After some messing with code, it appears that when the list is used like this print @$x,"\n" the list is passed comma seperated to the print function. The output has no spaces like I was expecting. This can be seen when you modify the ouput field seperator $,= ' ' before the print and you will get the spaces back into the print. This doesnt effect your example, because the whole array is joined into a string instead of a list of ellements. Am I correct in understanding whats going on?

So it would appear that my way might be better for small lists, but I would think it might cause problem with bigger ones. Is there a limit to the number of comma seperated values you can pass to print?? Your oppinion on the the two?

Thanks for your help and suggestions.
zzSPECTREz

well...

I got the feeling you were just messing around from the example. But I wanted to stress how messy it can get when you play with special variable none the less.

Yes, your first method is probably more akin to what I would do (disclaimer: jptxs only pretends to be a programmer. he is actually a philosopher with delusions of CS). But you could probably think of ten more to benchmark if you want, like print map { join "", @{$_}, "\n" } @data; comes immediately to mind. As for additional function calls, I think it comes down to the benchmarking of the thing. Sometimes less is not better if the one function you call ends up using more resources than two trimmer ones would have for the same task. Benchmark and be happy.

Your realization about using the bare @$x as opposed to the double-quoted version is correct. Neat, eh? I love it when stuff becomes clear too : ) And you can pass as many elements to print as you like. Just be sure to start using '()' after a while if you line up a bunch of functions since it can get pretty confusing.

As for which is better, I'm a little unclear on what you mean. If you mean to say your way is the first way you did it, i.e. for my $x (@data){...; I think that's fine for any list since you need to go through every element anyway. Looping through very large lists is just something that slows down as the lists grows - no way around that really. If your way is changing the $" vaiable, then I'd have to say there are better ways to go as stated. Ultimately the creed holds true - TMTOWTDI; and how you decide to do it will be based on needs, skill, function and feeling.

I think it's super-cool to play with perl to try and understand what's up - I do so as often as I can.

<myExperience>
$mostLanguages = 'Designed for engineers by engineers.';
$perl          = 'Designed for people who speak by a linguist.';
</myExperience>
[download]

Reading through this thread, I simply cant imagine how this helps? totally superfluous join?

print "SUB4: 2nd way\n";
for my $x (@data){
         print join "", @$x, "\n";
}
[download]

Maybe its just monday crankiness

It doesn't "help". There is no problem. zzspectrez was just exploring the inner beauty of TMTOWTDI and wanted to see more of what was goiung on and how to grasp it. The reason I, and maybe Fastolfe as well, suggested join for that method was to avoid modifing $" as a matter of practice. Just an exercise. that's all : )

"A man's maturity -- consists in having found again the seriousness on
+e
had as a child, at play."                                   --Nietzsch
+e
[download]