Re: Semantics of vector operations
This is still raging. I was going to let it slide. I hate the mechanics
behind squeeky wheels. Makes it harder to evaluate arguments for their
merits by clogging the filters. Okey, enough metaphores.
On 0, Luke Palmer <[EMAIL PROTECTED]> wrote:
>
> > Agreed. Cryptic, but in a different way than usual. I'd rather see
> > plain old keywords as long as I'm typing things out or making that
> > many key-strokes.
> >
> > sub each (*);
> >
> > each @arr += 3;
> >
> > each @arr += each @foo;
>
> That would be a hard macro to write. Not impossible, of course :-)
>
> I'm not sure it's a good idea to change the syntax just because Unicode
> is unavailable. There was a definite reason for bundling the "each"
> modifiers near the operator, and we'd be changing that. You also get
> ambiguities regarding to which operator the C applies if there is
> more than one.
>
> On the other hand, it does read quite wonderfully, unlike the seeming
> alternative:
>
> @arr each += each @foo;
>
> What about just a function?
>
> each(&infix:+= , @arr, @foo)
>
> Such that the Unicode is the only way to get at the syntactic shortcut?
> We've done a lot to make functions readable in a lot of ways. Indeed,
> there are many ways the function could work. A function that operates
> on alternating arguments may not be unhandy either:
I really like this too. It is like Lisp's special forms: "apply operator to data
in interesting way". It opens the door for numerous other operations in
a generic system. Maybe Damian will champion this for us =)
Taken to an ugly extreme, it could look like the correlation I wrote for
AI::FuzzyLogic, where sets permutate, correlate, or aggregate. Creating a framework
where this can exist outside of core prevents something horrid from being
suggested for core =)
>
> each(&infix:+= , zip(@arr, @foo))
>
> But that's getting pretty far away from what the operators originally
> intended.
This isn't very far away from map when used on built-ins.
@foo = map &infix:*, zip(@foo, @bar);
map -> $a is rw, $b { $a *= $b }, zip @foo, @bar; # except that zip would copy in
all probability
each() as a map type operator that applies operators (and other closures), modifying
the LHS, covers what people want to do with vectorized operators and covers
gaps in map.
So, in summary, I really like Luke's proposal.
-scott
>
> > Larry Wall suggested reading >> and << as "each".
> >
> > This would require a small comprimise on the p5 each. Or else it could be
> > named "vector". Shouldn't be a problem with %hash.keys, %hash.values,
> > %hash.each anyway.
>
> Perl5 C is going away anyway, in favor of the new construct:
>
> for %hash.kv -> $k, $v {
> ...
> }
>
> > This wouldn't implement as an operator very well, admittedly, but more like
> > a control keyword. It would seem closely related to foreach, though.
>
> Which is also going away :-)
>
> > What happens when there are a bunch of the puppies? Vectorizing operators
> > do the right thing, working according to the rules of precedence. "each"
> > would have to just share one iterator per statement, or else do ugly things
> > to the rest of the statement. It would be very difficult to do something like:
> >
> > (each @foo + each @bar) + (each @baz + each @baz)
>
> Don't worry about implementation. That's not our job.
>
> It would probably be implemented as a macro that just put it back into
> the Unicode notation.
>
> > This would lend itself a P5 backport that did overload on its argument, too. If
> > it found that the thing on the right hand side was also overloaded into the
> > same class, it is could use a single iterator on both sides, otherwise it would
> > treat the 2nd argument as a scalar. This would solve the "single iterator
> > per line" problem for p5 atleast. It would work correctly. Any number of
> > vectorized arrays could be floating around in an expression, each interacting
> > with each other correctly.
>
> Of course you mean "損interacting with束 other correctly." :-)
>
> > Would it be possible to subclass things on the fly, returning a specialized
> > object representing the argument that knew how to vectorize when asked to add?
> > Aren't add, substract, multiply, and so on, implemented as class methods in
> > Perl 6, much like Perl 5's overload module?
>
> No! And I couldn't be happier! They're multimethods, dispatching based
> on I their arguments, not just the left one.
>
> Luke
The Problem Roles Try To Solve
On Fri, 2004-02-13 at 11:02, Aaron Sherman wrote: > On Thu, 2004-02-12 at 14:03, chromatic wrote: > > The easy answer is that interfaces completely suck while traits don't. > > :) > Ok, so what you're saying is that they're solving for exactly the same > thing, but you don't like the Java implementation. Yes and no. I don't think Java interfaces actually solve anything except "let's not change the bytecode spec *again*". At least they acknowledge that single-inheritance isn't the be-all end-all of objects, but the second wrongest way to improve polymorphism is to add a second type of polymorphism with a separate implementation, philosophy, and syntax. The first, of course, is just to ignore the problem. The right way to improve polymorphism is to find common ground between inheritance, delegation, composition, aggregation, and reimplementation, make that your baseline, and support those techniques equally well. That has implications for the type system, the core libraries, and method dispatch, so it's much harder than copying an existing language and throwing out the parts you don't like. Then again, many things that are difficult are worth doing. -- c
Re: Traits: to renew OO inheritance in a hacker style discussion
On Thu, 2004-02-12 at 14:03, chromatic wrote: > On Thu, 2004-02-12 at 05:52, Aaron Sherman wrote: > > > Perhaps I'm slow, but I don't see the difference between a trait and a > > Java interface other than the fact that traits appear to be more of a > > run-time construct. > > The easy answer is that interfaces completely suck while traits don't. > :) Ok, so what you're saying is that they're solving for exactly the same thing, but you don't like the Java implementation. Cool, I just wanted to see if I understood what a trait was. Interfaces are a great feature, IMHO, and if Perl 6 can implement them (as Larry suggests) in an even more flexible and well integrated way (via roles), I'm all for it. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: The Sort Problem
On Thu, 2004-02-12 at 18:50, Uri Guttman wrote:
> there are only a short list of key comparisons possible, int, string,
> float and maybe unicode. i separate int from float since they do have
> different internals in the GRT. it is one area where you do expose
> stuff. otherwise you could just use number.
And comparing in a particular language (as Dan pointed out in his Parrot
talk); comparing sets (e.g. numeric comparison, but odds and evens are
separate); ordering by string length; ordering by string-to-numeric
value with esoteric exceptions (software versions); etc.
Comparison is essentially always numeric, but only if you reduce your
inputs to numbers, and that's often not terribly efficent (e.g. you can
reduce any ascii string to:
chr(substr($s,0,1))+chr(substr($s,1,1))*128+...
and then comparing. The only limitation is that you'll have to use
Math::BigInt to do the comparison.
> simple. pick almost any language char set other than US ascii. many have
> special collating sequences. i am not anything close to a unicode expert
> but i have seen this issue. in fact setting the LANG (or some other)
> environment variable will affect many programs by changing the collating
> order.
Ok, yes. This was Dan's example, and is EXACTLY why I think you want to
use map once for key extraction and then sort's expression for
comparison.
> that is scary. do you realize that the sort block will be called for
> each comparison?
Yes why would it not be? How do you compare, say, IPv6 addresses if
not by performing a logically-ored comparison between each octet? I
certainly don't want to instantiate a Math::BigInt just to compare two
128-bit values.
> AS> @new1 = sortpairs {$_[0] <=> $_[1]} map {[$_,$_]} @old1;
>
> AS> @new2 = sortpairs {$_[0] <=> $_[1] || $_[4] cmp $_[3]} map
> AS> {[getkeys($_),$_]} @old2;
>
> where is getkeys defined?
It was an example. It's whatever you like. In some cases, that might
just be:
sub getkeys {
my $object = shift;
return @{$object->keys};
}
or perhaps:
sub getkeys {
my $string = shift;
return(length($string),$string); # Order by length and then ascii order
}
It was just an example. sortpairs was the interesting part.
> how do you know what indexes to use for each
> comparison? what happened to $_[2]? your call to $comp is passed 2
> arguments but the second example accesses 4 arguments.
You missed a layer of extraction there. $comp is passed each parameter
PAIR.
So if your input is [1,2,3,4,"moo"], then you are comparing the keys 1,
2, 3 and 4 and your value is "moo".
> AS> The second example really illustrates the point that you can swap the
> AS> direction of key order and mechanism to compare them at your whim.
>
> AS> Now, you just need to call sortpairs with any array of arrays of keys
> AS> (with trailing value).
>
> add a third key to that. quickly!
ok, easy:
@new2 = sortpairs {$_[0] <=> $_[1] || $_[4] cmp $_[3] ||
ACME::Compare::Thingulas->compare($_[5],$_[6])} map {[getkeys($_),$_]} @old2;
Please notice that the ONLY change is in the way I call it, not in
sortpairs. sortpairs still works just fine.
> a more straightforward api (which is close to what i will do in
> Sort::GRT) is (p5 code)
>
> my $sort = Sort::GRT->new(
>
> keys=> [
> { descending => 1,
> type => float,
> extract => '$_->{amount},
> },
> { extract => 'substr( $_->{date}, 0, 4)' },
> ]
> ) ;
The value of extract should be a subref, not a string (thus having
closure status, and therefore access to context).
I think you and I are in violent agreement. I just look at this as a
problem that doesn't need solving because Schwartzian Transforms do all
the work for me. You look at it as something needing encapsulation.
That's cool, but sematically, we're doing the same work.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: The Sort Problem (was: well, The Sort Problem)
Friday 13 February 2004 15:02, Dan Sugalski wrote: > > If you're *really* looking to get fancy, why not just allow the > sort specification to be done with SQL? Comfortable, > well-understood, already has a decade or so of stupid things welded > into it [...] > > Heck, you could even unify map, grep, and sort [...] > That would be postmodern indeed. -angel
Re: The Sort Problem (was: well, The Sort Problem)
At 11:52 PM -0700 2/12/04, Luke Palmer wrote: But it needs some major syntax work so it can feel more like it's a part of the language instead of a library function. Not, mind, that I think Perl's syntax needs to be changed at all to accommodate. Since everyone's well past mad here and deep into drug-induced brain damage territory... If you're *really* looking to get fancy, why not just allow the sort specification to be done with SQL? Comfortable, well-understood, already has a decade or so of stupid things welded into it (so everyone can stop trying to think up new stupid things to weld in), and there are several grammars for it so it'd be no work to speak of for me. Heck, you could even unify map, grep, and sort and, if you fed in a list of pair lists or hashes, return parts of each record^Wlist element rather than the whole thing. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Traits: to renew OO inheritance in a hacker style discussion
Larry Wall wrote: Yes, that's a very good paper, which is why Perl 6 now has something called Roles, which are intended to degenerate either to Traits or Interfaces. My take on it is that Roles' most important, er, role will be to abstract out the decision to compose or delegate. But we'd like them to function as interfaces when the Role is "abstract", and we'd like them to function as Traits when you don't happen to specify any state attributes. But for hiding the delegation decision, you at least have to allow the amount of state that lets you remember the object you're delegating to. Of course, the Traits paper didn't go into traits with state, though it did mention it as a future research topic. We're just doing that future research for them. :-) Perfect ! My stupid question still apply. Will it be possible to have 'Exclusion' which forms a new trait|Role by removing a method from an existing trait|Role ? or should I read some docs on Roles to be smarter ? Thanks. -Dmitry By the way, we distinguish Traits from traits (which are compile-time properties applied by "is". To apply a Role we use "does". Larry
Re: The Sort Problem
> "RA" == Rod Adams <[EMAIL PROTECTED]> writes:
RA> Here's my stab at a sort syntax, pulling syntax over from REs:
RA> @out
RA> <== sort key:ri($_->[2]), key:s($_->[4])
RA> <== @in;
RA> Basicly, you have a list of RE syntax like C values, whilch take
RA> various modifiers to say how to play with that key, and then an expr
RA> on how to generate the key given element $_.
RA> Possible modifiers: (verbose versions welcome)
RA> :rreverse/descending
RA> :n force numeric comparisons
RA> :s force string comparisons (default)
RA> :u unicode (implies :s)
RA> :i case insensitive (implies :s)
RA> :l localized collation order
RA> :x call custom compare sub (a la P5)
i would support longer modifier names as aliases like rules do.
also numeric comparisons can be float or int. semantically they are the
same but it does affect internal stuff if you do a GRT implementation. i
hate to see this exposure of internals but if we want speed here it
needs to be shown.
RA> This allows:
RA> @out = sort keys %hash; # everything gets defaulted
RA> @out = sort key:x{myfunc($a) cmp myfunc($b)}(), @in; # handy for P5
RA> migration, but not much else
RA> @out = sort key(myfunc($_)), @in; # same as above, but much better.
RA> @out = sort key(%lookup{$_->{remotekey}}), key:ir($_->{priority}),
RA> @in; # complex in P5, easy here.
overall i like it.
RA> Advantages:
RA> - Uses syntax idioms used elsewhere in P6.
RA> - Common cases are easy
RA> - Decent huffman coding.
huffman isn't needed here IMO. sort isn't called so often so longer
modifier names are not a hinderance. rules will be called way more often
so short modifier aliases are useful huffman there. a good syntax that
handles multiple keys and is easy to remember and read is more important
than brevity. and you can spread keys out over multiple lines:
@out = sort
key( %lookup{ .{remotekey} } ),
key:insensitive:descending:locale( 'somewhere' )( .{priority} ),
key:float ( substr( 0, 10 ) ),
key:integer ( /foo(\d+)bar/ ),
key:compare( { ^$a <=> ^$b } )( /(\d+)$/ ),
key:compare( \&my_compare_sub ) ( /(\d+)$/ ),
@in ;
i think the . replaces $_->. in fact IIRC -> isn't used anymore for
deref.
do we need , between keys? sort basically will expect a list (without
commas?) of keys and then a list of data.
note that the code in key needs to be called in a list context so
grabbing (which i did perl5 style there. gotta get perl6::rules from
damian!) will work. maybe rules can deal with that in a better way than
i can think of.
note that i passed an argument to the locale modifier.
note that the custome compare callbacks can be a block or a sub
name/ref. the callback sub would be passed 2 args as usual.
do we need the ==> or <== stuff anywhere?
RA> Disadvantages:
RA> - Do we really want things that look like REs that are not REs?
other than the short names, it doesn't look like rule stuff.
RA> - If we do this, are we setting ourselves up to create other RE-like
RA> creatures for grep, for, etc, to the point
RA> where people will start wanting to roll their own in modules?
well, with the long names that isn't a problem.
RA> Thoughts?
drop the short names. but i like it. let's see if it passes larry's
muster.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: The Sort Problem
Am Freitag, 13. Februar 2004 01:40 schrieb Larry Wall:
> On Thu, Feb 12, 2004 at 04:29:58PM -0500, Uri Guttman wrote:
> : again, confusing. why should the order of a binary operator mean so
> : much? the order of a sort key is either ascending or descending. that is
> : what coders want to specify. translating that to the correct operator
> : (cmp or <=>) and the correct binary order is not the same as specifying
> : the key sort order and key type (int, string, float).
>
> Uri is dead on with this one, guys.
As I listen to this mails, I get the feeling that something like this is
wanted:
Key generation:
@unsorted_temp = map {
$k1=$_.func1('a');# ASC
$k2=$_.func2('we'); # DESC
[ $_, $k1, $k2 ];
} @unsorted;
Now we've got an array with keys and the objects.
Sorting:
@sorted = sort {
$a->[1] cmp $b->[1] ||
$b->[2] <=> $a->[2] ||
} @unsorted_temp;
These things would have to be said in P6.
So approx.:
@sorted = @unsorted.sort(
keys => [ { $_.func1('a'); },
{ $_.func2('we'); } ],
cmp => [ cmp, <=> ],
order => [ "asc", "desc"],
key_generation => "lazy",
);
That would explain what I want.
Maybe we could turn the parts around:
@sorted = @unsorted.sort(
1 => [ { $_.func1('a'); }, cmp, "asc"],
2 => [ { $_.func2('we'); }, <=>, "desc"],
);
or maybe use a hash instead of an array:
@sorted = @unsorted.sort(
1 => [ key => { $_.func1('a'); }, op => cmp, order => "asc"],
2 => [ key => { $_.func2('we'); }, op => <=>, order => "desc"],
);
If that's too verbose? I don't think so; I've stumbled often enough on $a <=>
$b vs. $b <=> $a and similar, and the above just tells what should be done.
Regards,
Phil
Re: The Sort Problem (was: well, The Sort Problem)
Here's my stab at a sort syntax, pulling syntax over from REs:
@out
<== sort key:ri($_->[2]), key:s($_->[4])
<== @in;
Basicly, you have a list of RE syntax like C values, whilch take
various modifiers to say how to play with that key, and then an expr on
how to generate the key given element $_.
Possible modifiers: (verbose versions welcome)
:rreverse/descending
:n force numeric comparisons
:s force string comparisons (default)
:u unicode (implies :s)
:i case insensitive (implies :s)
:l localized collation order
:x call custom compare sub (a la P5)
This allows:
@out = sort keys %hash; # everything gets defaulted
@out = sort key:x{myfunc($a) cmp myfunc($b)}(), @in; # handy for P5
migration, but not much else
@out = sort key(myfunc($_)), @in; # same as above, but much better.
@out = sort key(%lookup{$_->{remotekey}}), key:ir($_->{priority}), @in;
# complex in P5, easy here.
Advantages:
- Uses syntax idioms used elsewhere in P6.
- Common cases are easy
- Decent huffman coding.
Disadvantages:
- Do we really want things that look like REs that are not REs?
- If we do this, are we setting ourselves up to create other RE-like
creatures for grep, for, etc, to the point
where people will start wanting to roll their own in modules?
Thoughts?
-- Rod
