map { $_->[0] } sort { compare($a->[1], $b->[1]) } map { [$_, f($_)] } data
Uri Guttman <[EMAIL PROTECTED]> writes:
> 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.
That's what compare() does. compare() is a Perl function. It can do
anything you want.
> 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.
The purpose served is that it's conceptually simpler to tell Perl "here's
how to extract keys and here's how to compare them; now sort this data
structure" than it is to tell Perl "convert this data structure into a
different one and then extract keys from it like follows and compare them,
then transform the structure back." The first route is closer to the way
that people are intuitively thinking. It doesn't matter to me that the
first isn't going to be that many fewer characters of Perl code than the
second. I *understand* it better.
It is true that it can be done in a module. Most things in Perl can. It
matters very little to me whether it's a standard module or built into the
language; I just think that it should be possible to tell sort to make
this sort of thing easier.
> RA> You have to write slightly more code if you separate the
> RA> extraction function f() from the comparison function compare()
> RA> since if the key structure is complex, f() has to build a data
> RA> struction that compare() takes apart. That makes the memoizing
> RA> approach superior.
> and how is this ladder compare built?
The programmer writes it.
> but you don't autogenerate the code in the block.
I haven't heard anyone talking about autogenerating everything other than
the code that wraps each element of the list in an anonymous array holding
the element and the key(s) and then extracts the key(s) for the comparison
function. That part of the code is identical in every ST that I write.
> 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.
Less mental effort is the important part, not how many characters have to
be typed. I don't want to be thinking about that extra level of arrays,
and until you've written *lots* of ST's, you can't ignore it.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
