Darren Duncan wrote:
As an addendum to what I said before ...
...
I would want the set operations for tuples to be like that, but the
example code that Luke and I expressed already, with maps and greps etc,
seems to smack too much of telling Perl how to do the job.
I don't want to have to use maps or greps or whatever, to express the
various relational operations.
I think you're reading too many semantics into C<map> and C<grep>: they
don't tell perl *how* to implement the search, any more than
C<sql:where> would. The example was:
INSERT INTO NEWREL SELECT FROM EMP WHERE DNO = 'D2';
Vs
my $NEWREL = $EMP.grep:{ $.DNO eq 'D2' };
The implementation of $EMP.grep depends very much on the class of $EMP.
If this is an array-ref, then it is reasonable to think that the grep
method would iterate the array in-order. However, if the class is
"unordered set", then there is no such expectation on the implementation.
The deeper problem is probably the use of the "eq" operator in the test.
Without knowing a-priori what operations (greps) will be performed on
the relation, it is not possible to optimize the data structure for
those specific operations. For example, if we knew that $EMP should
store its data based on the {$.DNO eq 'D2'} equivalence class then this
grep would have high performance (possibly at the expense of its creation).
In theory, a sufficiently magical module could examine the parse tree
(post type-inference), and find all the calls to C<grep> on everything
that's a tuple -- and use that to attempt optimizations of a few special
cases (e.g. a code block that contains just an "eq" test against an
attribute). I'm not sure how practical this would be, but I don't see
how a different syntax (e.g. s/grep/where/) would be more more
declarative in a way that makes this task any easier.
