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:

  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.

Reply via email to