Hyperoperators and the Each role
Christopher Jeris
Hash: SHA1
[Beware, here be newbie -- possible nonsense ahead.]
I have a couple of questions about what S03 says about hyperoperators
applying recursively to any object which matches the 'Each' role:
[from S03]
Seq(3,8,[2,Seq(9,3)],8) >>-<< (1,1,2,1); # Seq(2,7,[0,Seq(7,1)],7)
1. What determines the concrete type of the result of a binary
hyperoperator which is applied to objects of two different sequence types?
Does the example mean that binary hyperoperators are not symmetric (in
type) even when their underlying operator is symmetric?
2. Will the 'Each' role require objects implementing it to be, not only
destructurable, but constructible - as the hyperoperator in the example
constructs a fresh Seq? Does this mean that hyperoperators won't apply to,
say, database result sets?
- --
Chris Jeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEvAn85ICCNV0oGWARAsZPAJ9rgSbbF228bLz1QnFi0cwo8kQMJwCfZM6n
bEwMXANHlIe5dRV4GkXxd9g=
=D/a5
-----END PGP SIGNATURE-----
Darren Duncan
>I have a couple of questions about what S03 says about hyperoperators
>applying recursively to any object which matches the 'Each' role:
>
>[from S03]
>Seq(3,8,[2,Seq(9,3)],8) >>-<< (1,1,2,1); # Seq(2,7,[0,Seq(7,1)],7)
>
>1. What determines the concrete type of the result of a binary
>hyperoperator which is applied to objects of two different sequence types?
> Does the example mean that binary hyperoperators are not symmetric (in
>type) even when their underlying operator is symmetric?
>
>2. Will the 'Each' role require objects implementing it to be, not only
>destructurable, but constructible - as the hyperoperator in the example
>constructs a fresh Seq? Does this mean that hyperoperators won't apply to,
>say, database result sets?
My understanding of binary hyper-operators is that they only work
with iterating over ordinal types, like the Seq or Array, where their
elements have an inherent order that can be used when determine how
to pair up the elements of the 2 arguments.
If you have a non-ordinal collection like a Set or Mapping or Hash,
you can not use a hyperoperator with it unless you convert it to an
ordinal type first, and presumably sort it in the process.
Practically speaking, often you won't be storing data in a
non-ordinal collection if you intend to use hyper-operators with it,
but more likely you would mean to use either set operators, which map
arguments to each other by their values, or reduce operators, as is
the case.
As for relational database result sets, in the general case these are
just as unordered as a Set and so similar caveats apply, unless it is
a sorted result set that is stored in a Seq or Array.
I should also point out that my in-progress Set::Relation module,
whose operators are a proper super-set of those that the Set type
has, is designed to make operations with unordered database result
sets easy that are analagous to what you might use hyper-operators
for, juch as performing a relational join, which maps corresponding
result elements and produces derived ones.
-- Darren Duncan
Larry Wall
: I have a couple of questions about what S03 says about hyperoperators
: applying recursively to any object which matches the 'Each' role:
:
: [from S03]
: Seq(3,8,[2,Seq(9,3)],8) >>-<< (1,1,2,1); # Seq(2,7,[0,Seq(7,1)],7)
:
: 1. What determines the concrete type of the result of a binary
: hyperoperator which is applied to objects of two different sequence types?
: Does the example mean that binary hyperoperators are not symmetric (in
: type) even when their underlying operator is symmetric?
Good question. We'll have to come up with a strategy for that. Obviously
if the two sides are the same container type, we'd like to keep that.
If they differ, then there are several approaches to finding a common
container type, I imagine. Doubtless it will end up coming down to
some kind of hidden MMD dispatch on container types.
: 2. Will the 'Each' role require objects implementing it to be, not only
: destructurable, but constructible - as the hyperoperator in the example
: constructs a fresh Seq? Does this mean that hyperoperators won't apply to,
: say, database result sets?
I would say that constructable is too strong--it merely needs to be clonable
as a container and fillable with the results, assuming the container in
question is able to contain the result type in question. That might entail
an each variant that mutates the type of the cloned container's elements.
But I'll leave that up to the implementors. :)
Larry