Proposal : Vector operations for Hashes
%a ^{+} %b
the direct generalization would be as follows :
@a ^[op] @b
for @a ; @b ->
$x ; $y {
$x op $y
}
%a op %b
# find common keys
@k = keys hash{ map { { _=>1 } } *( %a.keys , %b.keys ) };
#return has
On Wed, 30 Oct 2002 [EMAIL PROTECTED] wrote:
: # find common keys
: @k = keys hash{ map { { _=>1 } } *( %a.keys , %b.keys ) };
It seems a bit odd to privilege the intersection over the union.
Larry
!! Sorry, in previos post I had a mistake
Proposal : Vector operations for Hashes
(
this is just a joke
%a ^{+} %b
)
the direct generalization would be as follows :
@a ^[op] @b
for @a ; @b ->
$x ; $y {
$x op $y
}
%a ^[op] %b
# f
So is it usefull to make sence out of these :
hash ^[op] hash
hash ^[op] array
hash ^[op] scalar
array ^[op] array
array ^[op] scalar
Actually ,
I just want to understand , why so much accent is put on vectorizing
atomic operations with arrays . It seems that hashes are at least as
freq
> hash ^[op] hash
> ...
> array ^[op] scalar
ie, generally:
term ^[op] term
> what to do if @a, @b in @a ^[op] @b have different length
> what to do if %a, %b in %a ^[op] %b have not the same set of keys
> what to do in %a ^[op] @a
>
> [what to do] resolved by hash property :
I'd exp
> "fc" == <[EMAIL PROTECTED]> writes:
fc> So is it usefull to make sence out of these :
fc> hash ^[op] hash
fc> hash ^[op] array
fc> hash ^[op] scalar
fc> array ^[op] array
fc> array ^[op] scalar
well, you can't mung the keys to a hash, just the values. so why not
just use
On Wed, 30 Oct 2002, Me wrote:
> %a ^:union[op] %b
>
> %a :foo[op]:bar %b
I think that any operators over 10 characters should be banished, and
replaced with functions.
~ John Williams
> > %a ^:union[op] %b
> >
> > %a :foo[op]:bar %b
>
> I think that any operators over 10 characters should
> be banished, and replaced with functions.
I'd agree with that. In fact probably anything over 4,
and even 4 is seriously pushing it.
I'll clarify that I am talking here about using
On 31 Oct 2002 at 0:40, John Williams wrote:
> On Wed, 30 Oct 2002, Me wrote:
>
> > %a ^:union[op] %b
> >
> > %a :foo[op]:bar %b
>
> I think that any operators over 10 characters should be banished, and
> replaced with functions.
I don't think there should be any upper limit for operator-
Uri Guttman writes:
>
> %hash1.values [+]= %hash2{%hash1.keys} ;
>
but here is exactly example analogous to
my Dog $x = new Dog .
which was discusse dand turned to
my Dog $x .= new ;
It's (almost) clear what you want when you write
%hash1 [+]= %hash2 ;
so why to screen the m
Me writes:
> > > %a ^:union[op] %b
> > >
> > > %a :foo[op]:bar %b
> >
> > I think that any operators over 10 characters should
> > be banished, and replaced with functions.
>
I agree. But I think that we can get away here with just hash
properties , just like hash behaviour in is
--- [EMAIL PROTECTED] wrote:
> I agree. But I think that we can get away here with just hash
> properties , just like hash behaviour in is controlled by
> properties .
>
> e.g.
> union:
>
> (%a,%b) ^is no_strict_keys ;
> (%a %b) ^is default_value ( 0 ) ;
> %a ^[+] %b
>
> intersection :
>
> > union:
> > intersection :
>
> How would this work for hashes with differing properties?
>
> %a ^is strict_keys;
> %b ^is no_strict_keys;
>
> What would happen?
That's one reason why I suggested control of this sort
of thing should be a property of the operation, not of
the operands.
--
ra
On Thu, 31 Oct 2002, Me wrote:
: That's one reason why I suggested control of this sort
: of thing should be a property of the operation, not of
: the operands.
I think that by and large, the operator knows whether it wants to
do union or intersection. When you're doing «+», it's obviously
union
On Thu, 31 Oct 2002, Markus Laire wrote:
: I don't think there should be any upper limit for operator-lengths.
There will never be any official limits. Perl is not about arbitrary
limits. But I will tell you that I only added <=> to Perl 5 because
I knew there would never be a <=>= operator. We
Austin Hastings writes:
>
> --- [EMAIL PROTECTED] wrote:
> > I agree. But I think that we can get away here with just hash
> > properties , just like hash behaviour in is controlled by
> > properties .
> >
> > e.g.
> > union:
> >
> > (%a,%b) ^is no_strict_keys ;
> > (%a %b) ^is de
Austin Hastings writes:
> > but I am not shure ...
>
> "sure"
>
thanks . sorry that I write so badly . I'll try to be better .
> (Unless you do this on purpose :-)
>
> Cheers,
>
> =Austin
>
> __
> Do you Yahoo!?
> HotJobs - Searc
Me writes:
> > > union:
> > > intersection :
> >
> > How would this work for hashes with differing properties?
> >
> > %a ^is strict_keys;
> > %b ^is no_strict_keys;
> >
> > What would happen?
>
in the resulting hash only ( and all ) keys of %a will be present.
because %b *admits*
Larry Wall writes:
> On Thu, 31 Oct 2002, Me wrote:
> : That's one reason why I suggested control of this sort
> : of thing should be a property of the operation, not of
> : the operands.
>
> I think that by and large, the operator knows whether it wants to
> do union or intersection. When
> On Thu, 31 Oct 2002, Me wrote:
> : That's one reason why I suggested control of this sort
> : of thing should be a property of the operation, not of
> : the operands.
>
> I think that by and large, the operator knows whether it wants to
> do union or intersection. When you're doing +, it's obvi
Me writes:
> > > > > union:
> > > > > intersection :
> > > >
> > > > %a ^is strict_keys;
> > > > %b ^is no_strict_keys;
> >
> > in the resulting hash only ( and all ) keys of %a will be present.
> > because %b *admits* unknown keys but %a does not.
>
> Yes, but the general case
> temp sub infix:^[] is force_hash_to_intersect ;
Right. A property used as you suggest is effectively
an adverb applied at op definition rather than use.
> maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of
> length 3 ;
Right. It's quite plausible that one would want to be
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, 31 Oct 2002, Markus Laire wrote:
> The really great thing about the French quotes is that they visually
> keep the user aware of the composition. «+=» is obviously a variety
> of
> +=, whereas ^+= is not obvious, though shorter. (Square bracke
23 matches
Mail list logo
