Darren Duncan wrote:
1. What we *should* be doing with the Prelude, like with STD.pm, is
write under the assumption that the implementation is also written in
Perl 6.
We should write the Prelude in as declarative a manner as possible,
saying *what* we want to happen rather than how, such as you do when
writing in a functional language.
We should make use of Perl's higher-level tools like hyper-operators and
reduce-operators etc and write in a fashion that is developer focused,
same as writing normal Perl 6.
I do agree that a prelude.pm should be written atas higher level as
possible, but I would not that Perl6 is not a "declarative" language.
Using the most powerful operators available (I'd like to see more of
them) is about the best you can do: as soon at you start using
codeblocks to define things, you get beyond the realm where compile-time
analysis is possible in a dynamic language.
Lets imagine I want to define a "sqrt($x)" function in a declarative
style in perl6 (and lets image we've defined a Real type with
Real::Epsilon being the precision of the representation). The
declarative version of sqrt must say to find a value within the set of
Real numbers that, when squared, is closest to $x:
sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
(0..$x/2 :by(Real::Epsilon)).min: { abs $x - $^candidate ** 2 }
}
(This assumes that Array::min will one day accept a code-block, just
like grep, to define the property of the input list to be minimized).
The code would give a correct answer (the positive sqrt), and is written
as a fairly direct implementation of the declarative formulation. What
I'm not so sure of is that it would be a good way to write prelude.pm:
running the test suite would probably take quite a while.
So do you really mean "as declarative a manner as possible"? Or would
you consider this example to go beyond "possible"?
