Re: Pre-RFC: undef =~ s/def/initialize/
Randal L. Schwartz wrote: > > uninit looks like a typo for "unit". > > Maybe we need "denit" for "de-nitialize" :)... Yuck. I dislike "de-" anything. "un-" is far more often the correct prefix. Anyway, the counterpart of "init" should be, I think, "exit". But seriously, the opposite of "initio" is "ultimo", right? -- John Porter We're building the house of the future together.
Re: Beefier prototypes (was Re: Multiple for loop variables)
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>> for ($x,$y,$z) (@a1,@a2,4..12,@a4) { ... }
>>
>> Probably we'll have to say that the user must explicitly zip if that
>> is what is desired.
PS> Yes, please. I view the flattening of lists as a feature, not a bug, and
PS> it has made Perl a lot easier to understand IMHO.
I view it as a mis-feature. One is unable to return multiple arrays,
or to pass through multiple arrays without resorting to messy extra
punctuation characters.
It makes it 'necessary' to explode items onto the stack to operate properly.
(Yes, this can be optomized away, but retrofiting iterators and other
handling is probably a mess.)
The special case where the number of loop variables and the number of
supplied lists are equal should be either made explicit or optomized
if zip/merge/whatever is used.
Or
for ($x,$y,$z) ( (@x,@y,@z) )
an extra set of parenthesis could do the flattening. (only one list
is 'visible' as the argument to the for.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Beefier prototypes (was Re: Multiple for loop variables)
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> my_while { pred() } { # don't gimme no Tcl flac.
>> ...
>> } # no semicolon needed here!
DC> Just added to the RFC :-)
How would the parser handle this? Some '}' would need ';' some don't.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 52 (v2) List context return from filesystem functions
Would returning the array of status be sufficient? @foo = chmod 755, "bar", "baz", "quux"; # @foo == (0, 2, 0); How to convert them to error messages would be a challenge. Unless passing them through $! would do the trick. Hmm, perl -wle '$!=3; print $!' No such process Yup, works. > "PS" == Peter Scott <[EMAIL PROTECTED]> writes: PS> At 06:40 AM 8/30/00 -0600, Tom Christiansen wrote: >> >>My worry is that it seems like this would return >> >>an empty list on success, so: >> >> >> >> @foo = chmod 755, "bar", "baz", "quux" >> >> or die "Whoops, died on success!"; >> >> >> >> >> >>This seems to me to go contrary to the way perl tends to work... are >> >>there any other functions (beside system) that do this? Am I >> >>misunderstanding this? >> >> >No, you've hit on the biggest flaw of the RFC. I am less enamored of it >> >now than I once was. I'd still like to get those individual failure >> >reasons but I am beginning to think it is not worth the cost. Anyone got a >> >brainwave on how to have the cake and eat it too? >> >> I'm also concerned about all the separate errnos for each of those failures. PS> where PerlLIO_chmod is defined as chmod on most righteous systems. So it PS> would be a matter of squirreling away the errno for each bad result. PS> I just can't get over the result in the successful case being an empty PS> list, though. And conversely. Maybe this isn't itching enough to be worth PS> scratching this hard, but it seemed like a good direction :-( Anyone got PS> any brilliant ideas before I withdraw it? -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 52 (v2) List context return from filesystem functions
At 01:26 AM 9/10/00 -0400, Chaim Frenkel wrote: >Would returning the array of status be sufficient? > > @foo = chmod 755, "bar", "baz", "quux"; > # @foo == (0, 2, 0); > >How to convert them to error messages would be a challenge. >Unless passing them through $! would do the trick. > >Hmm, perl -wle '$!=3; print $!' >No such process > >Yup, works. But you still can't say @foo = chmod 755, "bar", "baz", "quux" or die ... because the function will now always return true in a list context. This is only slightly better than returning false iff the function failed. > > > > "PS" == Peter Scott <[EMAIL PROTECTED]> writes: > >PS> At 06:40 AM 8/30/00 -0600, Tom Christiansen wrote: > >> >>My worry is that it seems like this would return > >> >>an empty list on success, so: > >> >> > >> >> @foo = chmod 755, "bar", "baz", "quux" > >> >> or die "Whoops, died on success!"; > >> >> > >> >> > >> >>This seems to me to go contrary to the way perl tends to work... are > >> >>there any other functions (beside system) that do this? Am I > >> >>misunderstanding this? > >> > >> >No, you've hit on the biggest flaw of the RFC. I am less enamored of it > >> >now than I once was. I'd still like to get those individual failure > >> >reasons but I am beginning to think it is not worth the cost. Anyone > got a > >> >brainwave on how to have the cake and eat it too? > >> > >> I'm also concerned about all the separate errnos for each of those > failures. > >PS> where PerlLIO_chmod is defined as chmod on most righteous systems. So it >PS> would be a matter of squirreling away the errno for each bad result. > >PS> I just can't get over the result in the successful case being an empty >PS> list, though. And conversely. Maybe this isn't itching enough to be >worth >PS> scratching this hard, but it seemed like a good direction :-( Anyone got >PS> any brilliant ideas before I withdraw it? > >-- >Chaim FrenkelNonlinear Knowledge, Inc. >[EMAIL PROTECTED] >+1-718-236-0183 -- Peter Scott Pacific Systems Design Technologies
