>>>>> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes:
RA> Uri Guttman <[EMAIL PROTECTED]> writes:
>> map { $_->[0] } sort { compare($a->[1], $b->[1]) } map { [$_, f($_)] } data
>> ^^^^^^^ ^^^^^^^
>> and there is only extracted key being compared to another at the same
>> level, not multiple key levels. think about sorting by state and THEN
>> town. you can't do that with $a and $b and one f().
RA> Yes. You can.
RA> Don't assume $a->[1] is a simple scalar. What prevents f() from
RA> returning an array ref?
i never assumed that. but your ST example above shows it like that. you
still have to do a ladder compare with $a and $b do make the ST work
with multiple keys. each one needs to be given the sort order and
compare op as well.
>> so you need multiple compare ops and multiple f()'s.
RA> No, you don't.
yes you do. unless you use the GRT. an ST can only compare 1 key at a
time without a ladder compare. that is its major weakness.
RA> Yes, you have to write the comparison and data manipulation
RA> function for Perl; Perl isn't going to be able to figure it out
RA> for itself. But that's true regardless of the sorting method;
RA> you're always going to have to tell Perl what the keys are and how
RA> to compare them.
that is my whole point of why putting this into the language is
silly. it is too open ended for amount of work perl would have to do
vs. the amount of coding you save. you save very little as you are doing
most of the work youself in the f() key extraction subs.
RA> You have to write slightly more code if you separate the extraction
RA> function f() from the comparison function compare() since if the key
RA> structure is complex, f() has to build a data struction that compare()
RA> takes apart. That makes the memoizing approach superior.
and how is this ladder compare built? f() can't return it. it has to be
real perl code in the callback block, not lists of things.
RA> Without creating a function to extract the key, you can't sort in
RA> Perl at all. sort { $a <=> $b } contains two functions to extract
RA> the keys.
>> huh? $a and $b are not functions but aliases the the current pair of
>> keys (at the primary key level).
RA> Is sub { $a } a function? $a is equivalent to that. One way to look at
RA> this is that Perl lets you simplify the function if all you need is the
RA> basic data unit.
that still doesn't answer the issue of the ladder compare and who
creates it.
>> i don't seen any functions in what you show there. you don't need a
>> function or even an ST to sort complex records.
RA> My point is that writing functions isn't nearly as complicated as
RA> you make it sound. Almost every time I write a sort, map, or grep
RA> in Perl, I write a function.
but you don't autogenerate the code in the block. it is your code. the
supposed goal of this hypothetical builtin ST is to make it easier to
use it. i say it is not worth the effort since you have to do almost as
much work anyway. the key extraction (and possibly the ladder compare)
is still provided by you.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
