Re: logical ops on arrays and hashes
Dan Sugalski wrote: > >@a = @b | @c; > > nothing short-circuits but then you don't expect it to, and that's more or > less OK. The and operation would likely return the left-hand value if both > are true, and xor would return whichever of the two were true, or undef of > both (or neither) were true. First, from a language pov, these can all be implemented on reduce. Second, I think 'and' should select the item vrom @c, not @b. -- John Porter We're building the house of the future together.
Re: $a in @b (RFC 199)
> "Garrett" == Garrett Goebel <[EMAIL PROTECTED]> writes:
Garrett> I agree... why can't a block be a block? Or put another way, instead of
Garrett> trying to shoehorn in something new, why don't we take away something old
Garrett> and treat all the blocks the same under Perl 6?
You mean this would no longer work?
while (<>) {
if ($some_condition) {
fred fred fred;
next;
}
barney barney barney;
}
Yup. Sure looks like a block to me. If "next" aborts only the "if"
block, but still executes barney barney, then it's now useless for
about 70% of my usage of "next".
Nope, I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines and map/grep
blocks) from either of those. But I'll need further time to process
your proposal to see the counterarguments now.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: types that fail to suck
Mark-Jason Dominus wrote:
>
> Maybe I should also mention that last week I had a dream in which I
> had a brilliant idea for adding strong compile-time type checking to
> Perl, but when I woke up I realized it wasn't going to work.
What do you see as the major obstructions?
eval "" isn't too bad, because you can just forget about type inference
until after all use's and BEGIN{}'s have finished and you're about to
start the final run. Then you can allow any remaining eval""'s to trash
the inference.
Symbolic references are ok for user programs, because you can punt on
inference unless they use strict 'refs'. import() is much worse; you'd
need to alter Perl to either do those before the inferencer runs or make
a built-in Exporter that the typechecker is buddies with.
$class->$method may be survivable if you can infer the possible values
of $method most of the time.
Closures are tough, but they exist in many languages that people have
written inference engines for. You have to play some tricks to avoid
infinite loops in the inferencer.
Subroutine arguments cause trouble. They're a list, and most type
systems only allow a single type in lists. But if we use a list type
like (T1, T2, T3...) meaning the first element, if it exists, is of type
T1, the second of type T2, and the third and all remaining of type T3,
then we might be able to stem the precision hemorrhaging somewhat.
References scare me.
$b = 17; # $b(0) : integer
$b++; # $b(1) : number
$b .= "fish"; # $b(2) : string
$c{1000} = $b; # %c(0) : hash{integer -> string}
$c{2000} = \%c;# %c(1) : hash{integer -> string | integer ->
ref(hash)} + %c is exposed
$c{$$}->{$b} = 42; # %c(2) : hash{nonref scalar -> scalar?}
Tying is ok as long as it can be reduced to FETCH etc. calls.
When I get some time, I'm planning on prototyping a perl5 type
inferencer that handles the easy stuff and correctly punts on the harder
stuff. I should have it done by Christmas.
Christmas 2023 sounds about right.
Re: C in RFC 31
> Have you considered adding a C example to RFC 31? Yield would add
> multiple output items per input item better IMO than the current practice
> of accumulating a list of output items and returning it at the end.
>
>%newhash = map {yield $_; transform $somehash{$_}} @keysubset;
I can see what you're attempting, and it's a cool idea. But your
semantics are a little screwy in the above example. What you want is:
%newhash = map {yield $_; transform($_)} %oldhash;
This flattens the %oldhash to a sequence of key/value pairs. Then the
first time the map block is called (i.e. on a key) it immediately
returns the key. The second time, it resumes after the C and
transforms the value. That resets the block so that for the next
iteration (another key) it returns at once, then tranforms the second
value, etc., etc.
I'll definitely add *that* in to RFC 31.
Thanks
Damian
Re: types that fail to suck
> You talked about Good Typing at YAPC, but I missed it. There's a > discussion of typing on perl6-language. Do you have notes or a > redux of your talk available to inform this debate? http://www.plover.com/~mjd/perl/yak/typing/TABLE_OF_CONTENTS.html http://www.plover.com/~mjd/perl/yak/typing/typing.html Executive summary of the talk: 1. Type checking in C and Pascal sucks. 2. Just because static type checking is a failure in C and Pascal doesn't mean you have to give up on the idea. 3. Languages like ML have powerful compile-time type checking that is successful beyond the wildest imaginings of people who suffered from Pascal. 4. It is probably impossible to get static, ML-like type checking into Perl without altering it beyond recognition. 5. However, Perl does have some type checking mechanisms, and more are coming up. Maybe I should also mention that last week I had a dream in which I had a brilliant idea for adding strong compile-time type checking to Perl, but when I woke up I realized it wasn't going to work.
Re: logical ops on arrays and hashes
Jeremy Howard wrote: > > > Of course they have reasonable meanings for arrays--element-wise operations > (RFC 82): > > http://tmtowtdi.perl.org/rfc/82.html > > Any operation you can do on a scalar you should be able to do element-wise > on a list, and certainly it's not hard to come up with situations where this > is useful for non-short-circuiting bitwise operators. Bit vectors and > associated masks may well be stored in lists, for instance. > > This discussion should probably be on -data, BTW. Wouldn't it be very useful if all of the applicable polymorphic methods of RFC 159 would be overloadable for nD arrays (arrays becoming effectively instances of array objects)? I am not sure if this has been discussed before but I could think of a whole lot of applications. Often you might want to do just that with the suggested multidim arrays. Or is that already suggested in some other way? Christian
RE: $a in @b (RFC 199)
From: Steve Fink [mailto:[EMAIL PROTECTED]]
>
> Jarkko Hietaniemi wrote:
> >
> > Allow me to repeat: instead of trying to shoehorn (or piledrive) new
> > semantics onto existing keywords/syntax, let's create something new.
> > The blocks of grep/map/... are special. They are not quite looping
> > blocks, they are not quite sub blocks, they are different. Well, to
> > be frank they are just very plain, ordinary, blocks that return
> > their last value, but if we want to introduce both flow control
>
> So, why not get rid of the specialness? Why can't all blocks return
> their last value?
Yes... why not?
> The ones that currently do not return a value would
> just be given void context. (Just because there's nowhere for
> the value to go doesn't mean they can't return a value.) And if
> that's done, then
>
> $val = 1;
> $fact = while ($n) { $val *= $n--; } || $val;
>
> might not be a horrible idea either.
>
> Then we would have sub BLOCKs and loop BLOCKs. 'return' would
> escape the nearest enclosing sub BLOCK and return a value.
> last/redo/next would escape/repeat/continue the enclosing BLOCK
> of any sort, and would be extended to specify the value
> returned. 'last $value' would be equivalent to 'return $value'
> inside a subroutine unless it were enclosed in a loop BLOCK.
I agree... why can't a block be a block? Or put another way, instead of
trying to shoehorn in something new, why don't we take away something old
and treat all the blocks the same under Perl 6? I.e, make loop, bare, and
code blocks able to C, C, C, C, and C? And
make all blocks that haven't been short-circuited to return their last
value...
That would unify bare and code blocks. They'd be like an iterative loop that
executes once and allows a return value.
But loop blocks are still different. When you use a loop control statement
(C, C, or C) in a loop block, you don't short-circuit the
loop block, you short-circuit the loop statement.
Since blocks can have labels, how about giving built-in functions and
user-defined subroutines their own name as a magic or default label? I know
labels currently can't have package qualifiers. So perhaps this will
conflict with some interals issue. Or maybe it doesn't matter. In any case,
this will leave the programmer some freedom as to whether they are
short-circuiting the block, the loop, or the user-defined function.
Combine the unification of blocks with Tom Christiansen's suggestion which
maintains DWIMish syntax (and doesn't feel like a shoehorn to me at least):
>return $true && next;
>return $false && next;
>return $true && last;
>return $false && last;
>return $true && redo;
>return $false && redo;
Bonus: I no longer have to care about the difference between "code", "loop",
and "bare" blocks...
Here's an user-defined grep subroutine using the proposed changes:
sub mygrep (&@) {
my ($block, @list, @results) = @_;
push @results, LOOP: &$block and $_ foreach (@list);
@results
}
@list = (1,2,3,2,1);
@a = mygrep { $_ <= 2 or last} @list;
@b = mygrep { $_ <= 2 or last LOOP} @list;
@c = mygrep { $_ <= 2 or last mygrep} @list;
@d = mygrep { $_ <= 2 or return $_ && last} @list;
@e = mygrep { $_ <= 2 or return $_ && last LOOP} @list;
@f = mygrep { $_ <= 2 or return $_ && last mygrep} @list;
Resulting I would hope in:
@a = (1 2 2 1)
@b = (1 2)
@c = [exception]
@d = (1 2 3 2 1)
@e = (1 2 3)
@f = (3)
> Oh yeah. do BLOCK is still a third kind, which is transparent to all
> control constructs.
The C block is really more like special anonymous subroutine that takes
no arguments and is special in the sense that it is evaluated before the
loop condition of C and C. I have no idea why it is evaluated
before the loop condition... That seems un-DWIMish.
Garrett
Re: Please take RFC 179 discussion to -data
> [EMAIL PROTECTED] wrote: > > > > Could we please take discussion of 179 to -data? I think that's where > > it should be. > > > > K. > > Personnally, I don't see any objection to this. > If everybody is ok, why not ? > > How should I process ? Submit again the proposal with a modified > mailing-list email ? > > Gael, Yes. If you do this, I suggest you take the opportunity to fill out RFC 179 with more detail. In particular: - Why you think set operations should work on arrays rather than hashes - In what way the current Set:: modules are insufficient - Why set operations should be added to the core rather than a module That way the list will be able to understand the reasoning behind the RFC better.
Re: logical ops on arrays and hashes
Dan Sugalski wrote: > ...would anyone object to the _binary_ operators being used > instead? They don't have short-circuit semantics, and generally don't have > any reasonable meanings for hashes and arrays. With that, instead of > writing the above code, you'd write: > >@a = @b | @c; > > nothing short-circuits but then you don't expect it to, and that's more or > less OK. The and operation would likely return the left-hand value if both > are true, and xor would return whichever of the two were true, or undef of > both (or neither) were true. > Of course they have reasonable meanings for arrays--element-wise operations (RFC 82): http://tmtowtdi.perl.org/rfc/82.html Any operation you can do on a scalar you should be able to do element-wise on a list, and certainly it's not hard to come up with situations where this is useful for non-short-circuiting bitwise operators. Bit vectors and associated masks may well be stored in lists, for instance. This discussion should probably be on -data, BTW.
logical ops on arrays and hashes
I hate to bring this back up, but I'm designing bits of the internal api at the moment, so this is an issue. I'd like to have some sort of support for doing things like: @a = @b || @c; where @a is as big as the biggest of @b and @c, and for any individual entry, will be the value from @b if its true, and @c if its not. Unfortunately this has some short-circuiting issues and strong feelings abound, and I'd just as soon not stir that up again. I *still* want the feature though. Given that, would anyone object to the _binary_ operators being used instead? They don't have short-circuit semantics, and generally don't have any reasonable meanings for hashes and arrays. With that, instead of writing the above code, you'd write: @a = @b | @c; nothing short-circuits but then you don't expect it to, and that's more or less OK. The and operation would likely return the left-hand value if both are true, and xor would return whichever of the two were true, or undef of both (or neither) were true. For hashes, presumably we'd run through the keys of each hash, and missing keys would translate to false values. Objections, anyone? (I don't feel that strongly about it being a visible language feature, so if folks really dislike it I'll withdraw the suggestion and quietly slip the feature in anyway where nobody can see it... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
C in RFC 31
Damian Conway wrote:
> :-)
>
> I did consider that too, but the problem is that according to RFC 31 a
> C leaves the future entry point of a block at the next statement
> after the C, whereas the block needs to start from the beginning on
> each iteration.
>
> Damian
Have you considered adding a C example to RFC 31? Yield would add
multiple output items per input item better IMO than the current practice
of accumulating a list of output items and returning it at the end.
%newhash = map {yield $_; transform $somehash{$_}} @keysubset;
isn't any better than
%newhash = map {($_,transform $somehash{$_})} @keysubset;
but you can certainly come up with a reasonable example. Listing inventories
by department, for instance. By yielding we would save the creation of the
per-iteration temporary and push directly onto the result.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=<>' ~/nsmail/Inbox
Re: $a in @b
"Randal L. Schwartz" wrote:
> how do you indicate with 'last' that you
> want a false return, or a true return? This never comes up with a do
> {} block, or a subroutine block, because while those are being
> evaluated for a value, they don't respect last/next/redo.
if "last" means, return the most recently evaluated expression as
a return value and do not re-enter the block, the various semantics
can be created with a comma.
>Your
> request to have the grep block understand 'last' was the first block
> in Perl history that would have simultaneously needed to exit early
> *with* a value. And we hadn't come around that block yet. :)
>
> We really need a clean way to distinguish those four cases:
>
> "yes" and keep going
> "no" and keep going
> "yes" and abort after this one
($FirstSmall) = grep { $_ <= 7 and last } @numbers; # already true
> "no" and abort after this one
my $count;
# minor chicanery required to force short-circuit with false result
@Smalls_in_first_five =
grep { $count++ < 5 ? ($_ <= 7) : (0,last)} @numbers;
I see C in grep/map as implicitly setting a gatekeeping variable which
would prevent the remainder of the data from being evaluated. Since this is
known, evaluation of the remainder of the data can be safely optimised away.
Using the "gatekeeper" idea without C we get these:
> "yes" and abort after this one
my $gatekeeper = 1;
($FirstSmall) = grep
{ $gatekeeper and $_ <= 7 and ($gatekeeper = 0), 1 } @numbers;
> "no" and abort after this one
my $count;
my $gk = 1;
@smalls_in_first_five = grep
{$gk and ($count++ < 5 ? ($_ <= 7) : $gk=0 )} @numbers;
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=<>' ~/nsmail/Inbox
Re: reversable foreach ()?
On Tue, 12 Sep 2000 18:46:04 GMT, Ed Mills wrote: >So what about > > (do something) foreach (some list); > >i.e. > > print foreach (@l); You really should try out one of the more recent Perls. http://www.perl.com/CPAN-local/doc/manual/html/pod/perldelta.html#C_EXPR_foreach_EXPR_is_supporte -- Bart.
Re: reversable foreach ()?
Ed Mills wrote: > > So what about > >(do something) foreach (some list); > > Just a thought.. No, it's not just a thought. % perl56 -e 'print "Item $_\n" for qw( foo bar quux )' Item foo Item bar Item quux But you're thinking along the right lines! -- John Porter
reversable foreach ()?
I really like
(do something) if (something is TRUE);
as opposed to
if (something is TRUE) {do something}
Just personal taste I guess, but to me the former is a nice Perlism.
So what about
(do something) foreach (some list);
i.e.
print foreach (@l);
as opposed to
foreach (@l) {print}
Just a thought..
-E
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
Re: $a in @b (RFC 199)
I wrote: > > I can count how many times I've wanted to -- and thought s/can/can't/. :-o -- John Porter
Re: $a in @b (RFC 199)
Steve Fink wrote:
>
> So, why not get rid of the specialness? Why can't all blocks return
> their last value?
>
> Then we would have sub BLOCKs and loop BLOCKs. 'return' would escape the
> nearest enclosing sub BLOCK and return a value. last/redo/next would
> escape/repeat/continue the enclosing BLOCK of any sort...
>
> Oh yeah. do BLOCK is still a third kind, which is transparent to all
> control constructs.
I think any block which currently can "return" a value by letting it
fall out the end should be able to return a value by using C
explicitly. I can count how many times I've wanted to -- and thought
I should be able to -- do something like the following:
@x = map {
/:/ and return( $`, $' );
/,/ and return( $`, $' );
()
} @y;
O.k., ignore the stupidness of the example. Point is, I can't
return a value "early" from the loop.
--
John Porter
We're building the house of the future together.
Re: $a in @b (RFC 199)
Jarkko Hietaniemi wrote:
>
> Allow me to repeat: instead of trying to shoehorn (or piledrive) new
> semantics onto existing keywords/syntax, let's create something new.
> The blocks of grep/map/... are special. They are not quite looping
> blocks, they are not quite sub blocks, they are different. Well, to
> be frank they are just very plain, ordinary, blocks that return their
> last value, but if we want to introduce both flow control
So, why not get rid of the specialness? Why can't all blocks return
their last value? The ones that currently do not return a value would
just be given void context. (Just because there's nowhere for the value
to go doesn't mean they can't return a value.) And if that's done, then
$val = 1;
$fact = while ($n) { $val *= $n--; } || $val;
might not be a horrible idea either.
Then we would have sub BLOCKs and loop BLOCKs. 'return' would escape the
nearest enclosing sub BLOCK and return a value. last/redo/next would
escape/repeat/continue the enclosing BLOCK of any sort, and would be
extended to specify the value returned. 'last $value' would be
equivalent to 'return $value' inside a subroutine unless it were
enclosed in a loop BLOCK.
Extension idea: just use last LABEL, $value:
last LABEL => $value
or
last => $value
(last, $value seems like it wouldn't be terribly useful otherwise,
right?)
Oh yeah. do BLOCK is still a third kind, which is transparent to all
control constructs.
What am I missing?
Re: $a in @b
At 09:37 AM 9/12/00 -0400, Jerrad Pierce wrote:
>Doh! perhaps then more like:
>
> #grep for str's beginning and ending in a digit
> grep ITEM: { /^[1-9]/; next ITEM unless /[1-9]$/ } @list;
>
>Of course there are other ways of writing this...
>Are there any cases people want this for that CANNOT be rewritten?
>Or is it purely syntactic sugar? Not that that is a bad thing,
>as I've mentioned I think a way to short-circuit/bypass/"return" from
>an otherwise undistinguished block would be nice. There have been
>many times I've wanted to do same.
I think it's fine to allow a loop label on the grep block, but it wasn't
really what I thought we were discussing; you still haven't indicated what
the value of the block should be on that iteration. undef is a reasonable
default but how to provide another? That's what my idea was, to provide a
second argument. Also, shouldn't be necessary to label a loop if you don't
have another one inside it, although if you did, it would avoid the
embarrassment of "last undef, 'foo'" that fell out of my suggestion.
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> Basically a hash with
>> only the keys, no other baggage.
TC> If you don't want but the keys, don't use but the keys.
Does that mean, that none of the other bookeeping for the values will
be done?
Is this "@hash{@keys};" valid?
Would it be possible to make push(%hash, @keys) work? Doesn't look likely
is @keys the keys, the values, or both?
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
>> 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 :-)
Doh! perhaps then more like:
#grep for str's beginning and ending in a digit
grep ITEM: { /^[1-9]/; next ITEM unless /[1-9]$/ } @list;
Of course there are other ways of writing this...
Are there any cases people want this for that CANNOT be rewritten?
Or is it purely syntactic sugar? Not that that is a bad thing,
as I've mentioned I think a way to short-circuit/bypass/"return" from
an otherwise undistinguished block would be nice. There have been
many times I've wanted to do same.
--
#!/usr/bin/perl -nl
BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;});
$_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";&{$F[0]};sub t{*t=sub{};
return if rand()<.5;$_="Vg'f abg lbhe ghea lrg, abj tb.";&{$F[0]};$_=0;}
sub v{print map sprintf('%c', 2**7-2**2),(1 .. $0);}&v;}{$_++;$_--;$_||=4;
if($_>>2||($_<<2>12)){$_="Vainyvq ragel";&{$F[0]};last;}&t;$0-=$_;$_="Lbh jva";
die(&{$F[0]}) if !($0-1);$0-=$0%2?$0>2?2:1:$0<=5?$0>2?3:1:rand>.5?1:3;
$_="V jva";die(&{$F[0]}) if !($0-1>1);}&v __END__ http://pthbb.org/
MOTD on Setting Orange, the 36th of Bureaucracy, in the YOLD 3166:
Science is a two headed beast, arthur. One head is good. It brings us advances like
aspirin. But the other head-Oh, beware the other head of science, arthur! It bites!
Re: Please take RFC 179 discussion to -data
[EMAIL PROTECTED] wrote: > > Could we please take discussion of 179 to -data? I think that's where > it should be. > > K. Personnally, I don't see any objection to this. If everybody is ok, why not ? How should I process ? Submit again the proposal with a modified mailing-list email ? Gael,
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Tom Christiansen wrote: > > >I don't want a set representation. I want set operations. And somehow > >for this having to add a use statment and who knows what overhead for > >what seems to be a simple operation is a pain. > > The overhead is not that it should be a module, but rather, > the sillily/evilly inefficient thing that *you* are doing. > Or trying to do. > > We have modules to do this. We have hashes to do this. > We have the technology. It is ignored. Ignorance of > technology is no excuse for adding strange basic types > and operations on them into the very heart of a programming > language. > > --tom I'm not an expert in technology of programming languages, but I know that such basic operations exists in other languages, and I'm sure that it can be possible to add such functions/operators in the heart of Perl without doing it with sillily/evilly inefficiency. If others languages can do it, why not Perl ? Gael,
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Tom Christiansen <[EMAIL PROTECTED]> writes: > >I don't want a set representation. I want set operations. And somehow > >for this having to add a use statment and who knows what overhead for > >what seems to be a simple operation is a pain. > > The overhead is not that it should be a module, but rather, > the sillily/evilly inefficient thing that *you* are doing. > Or trying to do. > > We have modules to do this. We have hashes to do this. > We have the technology. It is ignored. Ignorance of > technology is no excuse for adding strange basic types > and operations on them into the very heart of a programming > language. I wonder if an RFC proposing some way of allowing folks to implement named infix operators wouldn't be better than the current one proposing adding set theoretic functions? Then the set theretic stuff is just a SMOP on top of the more general 'making named infix operators' RFC. Of course, there's every chance that said RFC would get shot down in flames, but if it *were* accepted and proved possible to implement then we get a whole lot more functionality than just set munging ops. However, I'm damned if I'm writing such an RFC; I'm not even sure that the functionality would be a win. -- Piers
Check this !! messaging langage or so ...!!!
hi, REBOL is the next generation of distributed communications. By "distributed" we mean that REBOL code and data can span more than 40 platforms without modification using ten built-in Internet protocols. The pieces of a program can be distributed over many systems. By "communications" we mean that REBOL can exchange not only traditional files and text, but graphical user interface content and domain specific dialects that communicate specific meaning between systems. We define communications to include not only information exchanged between computers, but information exchange between people and computers, and information exchanged between people. REBOL accomplishes all of these. http://www.rebol.com/developer.html http://www.rebol.com/howto.html http://www.rebol.com/faq.html Q. I noticed REBOL has built-in compression. How do I use it? Q. Why doesn't REBOL have an ELSE statement? Q. What IS a series? = iVAN [EMAIL PROTECTED] =
Re: $a in @b (RFC 199)
On Mon, Sep 11, 2000 at 04:41:29PM -0500, Jarkko Hietaniemi wrote: > Allow me to repeat: instead of trying to shoehorn (or piledrive) new > semantics onto existing keywords/syntax, let's create something new. > The blocks of grep/map/... are special. They are not quite looping > blocks, they are not quite sub blocks, they are different. Well, to > be frank they are just very plain, ordinary, blocks that return their > last value, but if we want to introduce both flow control > (short-circuiting) and as a derived requirement, a return value > (was the last test a success or a failure), they definitely begin to > become not your ordinary blocks. I do not think the existing arsenal > of keywords/syntax is enough to cover all the behaviour we are after. > The 'pass' keyword someone suggested has potential (when combined with > allowing last -- and next -- to work on these mongrel blocks). Also it should be possible for someone to write thier own looping construct like map/grep as a sub and take advantage of this. Graham.
