At 09:45 PM 9/11/00 -0400, Jerrad Pierce wrote:
> >Pardon my repetitiousness, but I'm puzzled at the total lack of response
> >AFAICS to my proposal for a second argument to next/last/redo. Was it so
> >stupendously moronic as to be beneath anyone's dignity to rebut, or
> >what? Either I'm out of it, or it looks a whole lot more appealing than a
> >new keyword.
>
>IMHO THAT (two args) would be overkill. These are operators, simple flow
>control words that also make the source very easy to read.
>i really can;t see adding a second arg because ythen you're going to have
>to do stuff like
> next undef, 1
>etc. which is wholly unappetizing.
Well, it's hard to argue matters of taste. All I'll say is that the
capability we're discussing will be so rarely used IMHO that expending a
new keyword for its sake isn't worth it. Keywords exact a high price in
namespace pollution and user brain cells. I know it's debatable whether it
uses any more brain cells than an extra argument to next, but I happen to
find it a bit more intuitive. There again, I would :-)
> The only way I myself see extending
>current words is to use some special label name. not that that is very nice...
>Only if this special name perhaps contained a character which is not valid in
>a label... (are there any? [:*] ?)
>
>I personally like the idea of somehting like feign (or whatever it's called),
>nice and generic. But if not that and not 2 arg next etc. And I may have
>missed this thread if someone hit upon it, but what's wrong with
>allowing something like
>
> grep ITEM: { /^[1-9]/ || next ITEM } @list;
Not much that I can see, but your next does not include any return value,
so what should it be? Of course, if it's false, you didn't need a next in
the first place and if it's true you didn't need a grep in the first place :-)
--
Peter Scott
Pacific Systems Design Technologies
