http://qs1969.pair.com?node_id=43358


in reply to Help with @LoL

You are interpolating an array into a string; when you do this, you get a string with the elements of the array separated by the value of the $" variable, by default a single space. e.g. -
my @array = qw(foo bar baz); my $string = "@array"; print "This is an interpolated array: $string";
Will yield: This is an interpolated array: foo bar baz
Hope this helps!

Replies are listed 'Best First'.
Re: Re: Help with @LoL
by zzspectrez (Hermit) on Nov 26, 2000 at 11:44 UTC

    Thanks!! Thats the answer. I havent run across $" special variable before. So in other words, the following code gives me the response I was expecting.

    $" = ''; print "SUB4: 3rd way\n"; for my $x (@data){ print "@$x\n"; }

    Prints the following.

    SUB4: 3rd way 123 123 123

    zzSPECTREz

      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"; }
      If you feel you must change $" then try and use local on your change so that it is really constricted to the one place you need the change to be in effect.
      <myExperience> $mostLanguages = 'Designed for engineers by engineers.'; $perl = 'Designed for people who speak by a linguist.'; </myExperience>

        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

        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"; }

        Maybe its just monday crankiness

      You may also be interested in the join function, which is specifically for bringing together different array elements in a single string. You won't have to mess with special variables.