Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!jpl-devvax!lwall From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) Newsgroups: comp.lang.perl Subject: Re: null? or not null? Message-ID: <11125@jpl-devvax.JPL.NASA.GOV> Date: 20 Jan 91 01:58:51 GMT References: Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) Organization: Jet Propulsion Laboratory, Pasadena, CA Lines: 70 In article rm55+@andrew.cmu.edu (Rudolph T. Maceyko) writes: : flee@cs.psu.edu (Felix Lee) writes: : > > print 2 if ($a,$b) = undef; # prints 2 -- why? : > : > "undef" is not a null list. "()" is a null list. "undef" is the same : > as "(undef)". If you try : : That's true, and I see why the assignment of "undef" to the list : returns true, but I still would like the the following while loop to : terminate if the function returns "()" (not "undef," as I stated : previously) instead of iterating indefinitely. : : while (($a,$b) = (&function())[7,8]) { : ... : } : : I understand that "mentioning" non-existent array elements causes : their creation, but is that entirely necessary when the array is empty : and only referred to? But it's not true that mentioning non-existent array elements causes their creation. That's not what's going on here. : Unless it causes trouble that I don't forsee, I would consider : "ignoring" such array slices of "()" both a feature and an : optimization. It's a feature because it makes my scripts work ;-> and : an optimization because creating new elements for the null list in : this case accomplishes nothing. What it accomplishes is to prevent even greater confusion. See below. : References to arrays (shift, pop) apparently always ignore null : elements (while references to lists [for, grep] do not), I don't think this is true either. If you shift an undefined element out of an array, you get an undefined value. Can you give an example of what you mean? : and conditionality is apparently processed as a list (in an "array" : context). Here we begin to get to the root of the problem. Conditions are not evaluated in an array context, but a scalar context. The array assignment in a scalar context returns the number of elements that were available on the right-hand side of the assignment. And the ()[] operator always produces the number of values that you gave as subscripts. What you seem to be asking for is for the ()[] operator to automatically squish out any undefined values. But that would be very confusing. Suppose you reversed the subscripts and said ($a,$b) = (&function)[8,7] Suppose further that &function returned (0..7). The ()[] constructs a two element list, the FIRST of which is undefined, and the second of which is 7. If we allow automatic squishing by ()[], $a gets the value intended for $b, and $b gets the undefined value. This would be highly counterintuitive, especially as the list gets longer. Neither ()[] nor ordinary array slices should produce lists of indeterminate length, because the position of the elements may be important unless you explicitly feed to a function that doesn't care, like grep. But the slice can't tell that. Even if I made it so that it could tell, it would think that assignment to ($a,$b) cared about positions, so that would be no help to you. If slices did autosquishing, and %bar contained undefined values, then @foo{@keylist} = @bar{@keylist}; wouldn't work. It might just be possible to make slices discard any *trailing* undefined elements, but that might cause other surprises. I'd have to think about that a lot. Alternately, it might be possible to make array assignment in a scalar context not count any trailing undefined values on the RHS, but again, that's a very dangerous kind of semantic change. An undefined scalar value has two distinct functions as a placeholder in a list. The first is to keep subsequent defined values at the correct position. The second is as a trailing value to make sure the list stays the length that is expected. The question is whether we can sacrifice the second function, and how much it gains us. I'm not convinced. Larry