Re: Look-ahead arguments in for loops
[EMAIL PROTECTED] wrote:
And that was never quite resolved. The biggest itch was with
operators that have no identity, and operators whose codomain is not
the same as the domain (like , which takes numbers but returns
bools).
Anyway, that syntax was
$sum = [+] @items;
And the more general form was:
$sum = reduce { $^a + $^b } @items;
Yes, it is called reduce, because foldl is a miserable name.
To pick some nits, reduce and fold are different concepts. By
definition, reduce doesn't take the initial value, while fold does.
So reduce using fold is something like
@items || die horribly;
foldl fn, @items[0], @items[1..]
... while fold using reduce is:
reduce fn, ($initial, @items)
I think both are useful, depending on the circumstances.
Miro
Re: Look-ahead arguments in for loops
Miroslav Silovic wrote:
[EMAIL PROTECTED] wrote:
And that was never quite resolved. The biggest itch was with
operators that have no identity, and operators whose codomain is not
the same as the domain (like , which takes numbers but returns
bools).
Anyway, that syntax was
$sum = [+] @items;
And the more general form was:
$sum = reduce { $^a + $^b } @items;
Yes, it is called reduce, because foldl is a miserable name.
To pick some nits, reduce and fold are different concepts. By
definition, reduce doesn't take the initial value, while fold does.
So reduce using fold is something like
@items || die horribly;
foldl fn, @items[0], @items[1..]
... while fold using reduce is:
reduce fn, ($initial, @items)
I think both are useful, depending on the circumstances.
Miro
Something like:
sub *reduce(func, +$initial = undef, [EMAIL PROTECTED])
{
$value = $initial;
map { $value = func($value, $_); } == @list;
return $value;
}
?
Or would this be an array method? I can see wanting to reduce list
literals, in some wierd mostly-tutorial cases, but I can also see
wanting this to be a data structure method to prevent reducing a parse
tree using an array operation...
=Austin
my $key is sensitive;
For the last couple days, I've been implementing a cryptographic cipher framework for Perl 6. (It's in the Pugs repository if you want to see it.) Dealing with this sort of algorithm has brought forward a feature that I think Perl 6 and Parrot ought to support. Basically, I'd like to be able to mark a variable as sensitive or secret. This implies that the language should overwrite the memory it uses before deallocating it, and that if possible it should tell the virtual memory system to avoid swapping it out. Moreover, it should probably do so recursively, and to any value that has ever been stored in the variable. (In essence, the *variable* marks all *values* it ever contains as sensitive.) This feature could make Perl 6 a better language for security work than any other I've seen. C and C++ could do this, but only with the programmer's assistance (by calling a wipe function or making sure a destructor is correctly called), and optimizers have been known to helpfully remove such code. Many higher-level languages, including Perl 5, make it hard to know when a piece of data is being overwritten, rather than a pointer being changed. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
