On Mon, Mar 26, 2001 at 04:34:22PM -0600, Jarkko Hietaniemi wrote:
> > Of course. So how is the ST justified when you simply want to
> > sort by length? I.e., why is this not sufficient:
>
> Those of the School of Maniacal Optimization may prefer calling
> length() only O(N) times, instead of O
James Mastros wrote:
> This runs afoul of the halting problem real quick.
That would be taking the entirely wrong approach.
All you'd need to do is check the return values from multiple
calls with the same arguments. As long as they appear
idempotent, that's all you care about.
> My intuitio
On Wed, Mar 28, 2001 at 09:38:59AM -0500, John Porter wrote:
> Mark-Jason Dominus wrote:
> > I have to agree with whoever followed up that this is a really dumb idea.
> Yahbut... (See last paragraph, below).
OK, I'm agreeing with MJD on this one, and it was my idea. There is no easy
way to che
On Wed, Mar 28, 2001 at 09:13:01AM -0500, Mark-Jason Dominus wrote:
>
> > So you can say
> >
> > use Memoize;
> > # ...
> > memoize 'f';
> > @sorted = sort { my_compare(f($a),f($b)) } @unsorted
> >
> > to get a lot of the effect of the S word.
>
> Yes, and of course the inline version
Mark-Jason Dominus wrote:
>
> > I'd think /perl/ should complain if your comparison function isn't
> > idempotent (if warnings on, of course). If nothing else, it's probably an
> > indicator that you should be using that schwartz thang.
>
> I have to agree with whoever followed up that this is
> So you can say
>
> use Memoize;
> # ...
> memoize 'f';
> @sorted = sort { my_compare(f($a),f($b)) } @unsorted
>
> to get a lot of the effect of the S word.
Yes, and of course the inline version of this technique is also
common:
@sorted = sort { my $ac = $cache{$a} ||= f($a);
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 09:26 AM 3/27/2001 -0800, Peter Buckingham wrote:
> >Dan Sugalski wrote:
> > >
> > > At 09:50 PM 3/26/2001 -0500, James Mastros wrote:
> >
> >[..]
> >
> > > >I'd think /perl/ should complain if your comparison function isn't
> > > >idempotent (if warn
Simon Cozens wrote:
> On Mon, Mar 26, 2001 at 04:36:35PM -0500, Uri Guttman wrote:
>
>> SC> Do you see any ESP there? Do you see any parsing of arbitrary
>> SC> pieces of code? No, me neither.
>>
>> and even creating a function to extract the key is not for beginners in
>> many case. most o
please ignore my previous message. i think that my mind was trapped in an
alternate dimension :)
peter
Peter Buckingham wrote:
>
> James Mastros wrote:
> >
> [..]
> >
> > f("+123,456")=123456
> > f(f("+123,456))=123456
> >
> > The functon is not idempotent. Even if you checked f(x)==x (functio
James Mastros wrote:
>
[..]
>
> f("+123,456")=123456
> f(f("+123,456))=123456
>
> The functon is not idempotent. Even if you checked f(x)==x (function is the
> identity), an input of "123456" would work.
just a comment on this, we are talking about sorting which would generally
mean that the
John Porter wrote:
> And I don't like the name ":constant", it smacks too much
> of OO. I'd hope we would come up with a better name.
:function ? :pure ?
--
John Porter
Peter Buckingham wrote:
> but the obvious question is if
> it isn't an idempotent function what do we do? do we abort? perhaps the real
> question is not whether we can require idempotency but what are we trying to
> achieve with it --- there may be another way :)
It is easy enough to test if the
On Tue, Mar 27, 2001 at 09:26:15AM -0800, Peter Buckingham wrote:
> I x A = I x A x A
> A = A^2
Problem with this: A isn't a matrix, nor is it even a vector (in the big
sense, not the pointy-arrow). It isn't that simple. Also, idempotent in
the CS world is diferent then in the algebe
> >could you not try a simple test (not guaranteed to be 100% accurate
> >though),
> >by copying the first data element and apply it twice and then check to see
> >that the result of applying it once is the same as applying it twice.
>
> Feels a little too magic to me, and awfully fragile. I'm n
At 09:26 AM 3/27/2001 -0800, Peter Buckingham wrote:
>Dan Sugalski wrote:
> >
> > At 09:50 PM 3/26/2001 -0500, James Mastros wrote:
>
>[..]
>
> > >I'd think /perl/ should complain if your comparison function isn't
> > >idempotent (if warnings on, of course). If nothing else, it's probably an
> >
Dan Sugalski wrote:
>
> At 09:50 PM 3/26/2001 -0500, James Mastros wrote:
[..]
> >I'd think /perl/ should complain if your comparison function isn't
> >idempotent (if warnings on, of course). If nothing else, it's probably an
> >indicator that you should be using that schwartz thang.
>
> If y
At 07:37 PM 3/26/2001 -0800, Russ Allbery wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > You're ignoring side-effects. The tied data may well be returned the
> > same every time it's accessed, but that doesn't mean that things aren't
> > happening behind the scenes. What if we were trackin
Simon Cozens <[EMAIL PROTECTED]> writes:
>On Mon, Mar 26, 2001 at 10:50:09AM -0500, Uri Guttman wrote:
>> SC> it? That is, @s = sort { f($a) <=> f($b) } @t
>>
>> because that would require the PSI::ESP module which isn't working
>> yet. how would perl intuit exactly the relationship between th
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 need
> "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
Uri Guttman <[EMAIL PROTECTED]> writes:
>> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes:
> RA> Uri Guttman <[EMAIL PROTECTED]> writes:
> map { $_->[0] } sort { compare($a->[1], $b->[1]) } map { [$_, f($_)] } data
>^^^ ^^^
> RA> Then you need t
> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes:
RA> Uri Guttman <[EMAIL PROTECTED]> writes:
>>> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> No, it wouldn't, don't be silly. The ST can always be generalized to
SC> ST(data, func, compare) =
SC> map { $_->[0] } sort
Dan Sugalski <[EMAIL PROTECTED]> writes:
> You're ignoring side-effects. The tied data may well be returned the
> same every time it's accessed, but that doesn't mean that things aren't
> happening behind the scenes. What if we were tracking the number of
> times a scalar/hash/array was accessed?
Uri Guttman <[EMAIL PROTECTED]> writes:
>> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
> SC> No, it wouldn't, don't be silly. The ST can always be generalized to
> SC> ST(data, func, compare) =
> SC> map { $_->[0] } sort { compare($a->[1], $b->[1]) } map { [$_, f($_)] } data
> a
James Mastros wrote:
> we should have a :constant and a
> :idempotent attrib for subs, and make them unremovable.
Well, :idempotent might be useful, but not for sort, which
should just assume idempotency anyway.
And I don't like the name ":constant", it smacks too much
of OO. I'd hope we would
At 09:50 PM 3/26/2001 -0500, James Mastros wrote:
>On Mon, Mar 26, 2001 at 07:31:29PM -0500, Dan Sugalski wrote:
> > At 06:51 PM 3/26/2001 -0500, John Porter wrote:
> > >As for :idempotent, I think sort() needs to assume the comparison sub
> > >is idempotent, rather than requiring such an attribut
On Mon, Mar 26, 2001 at 06:31:22PM -0500, Dan Sugalski wrote:
> At 04:04 PM 3/26/2001 -0500, James Mastros wrote:
> >The only way f(a) can not be stable and f(a) <=> f(b) can be is somthing of
> >a corner case. In fact, it's a lot of a corner case.
> You're ignoring side-effects.
Damm. I hate it
On Mon, Mar 26, 2001 at 07:31:29PM -0500, Dan Sugalski wrote:
> At 06:51 PM 3/26/2001 -0500, John Porter wrote:
> >As for :idempotent, I think sort() needs to assume the comparison sub
> >is idempotent, rather than requiring such an attribute explicitly.
> Assuming idempotency's fine, though I don
Tad McClellan wrote:
> Nothing like throwing some disk accesses into it if slow is what
> you seek.
Yeah. Or web fetches!
--
John Porter
On Mon, Mar 26, 2001 at 05:44:43PM -0500, John Porter wrote:
> Jarkko Hietaniemi wrote:
> > It's all about reduction to primitive-comparable and the
> > relative cost of it.
>
> You're right. Extraction of fields is only one example.
>
> (But it's illustrative, no?)
I like to use sorting file
At 07:01 PM 3/26/2001 -0500, John Porter wrote:
>Dan Sugalski wrote:
> >
> > If we disallow changing the attributes on subs at runtime,
>
>Probably a good idea anyway, at least for a subset of attributes,
>such as :idempotent (or :constant).
Oh, it's a fine idea, and I'm personally all for it. An
At 06:51 PM 3/26/2001 -0500, John Porter wrote:
>Dan Sugalski wrote:
> >
> > You're ignoring side-effects. The tied data may well be returned the same
> > every time it's accessed, but that doesn't mean that things aren't
> > happening behind the scenes.
>
>Like the :constant attribute on object m
Dan Sugalski wrote:
>
> If we disallow changing the attributes on subs at runtime,
Probably a good idea anyway, at least for a subset of attributes,
such as :idempotent (or :constant).
--
John Porter
Give the braindead no head.
Dan Sugalski wrote:
>
> You're ignoring side-effects. The tied data may well be returned the same
> every time it's accessed, but that doesn't mean that things aren't
> happening behind the scenes.
Like the :constant attribute on object methods in certain other languages.
So, we could say, i
Dan Sugalski wrote:
> John Porter wrote:
> > No, it will generate a more crashed perl.
>
> I thought we fixed that particular core dump.
Yes; but it's still bad.
We just are more stable in the face of this badness.
--
John Porter
Trond Michelsen wrote:
> I realize that memoization isn't something you want to do on functions
> that may return different results with the same input. However I'm a bit
> curious of when these functions are useful in sort(),
>...
> sort {rand($a) <=> rand($b)} @nums;
Right.
> Will the abo
At 04:04 PM 3/26/2001 -0500, James Mastros wrote:
>On Mon, Mar 26, 2001 at 03:36:08PM -0500, Dan Sugalski wrote:
> > The only issue there is whether memoization is appropriate. It could be
> > argued that it isn't (it certainly isn't with perl 5)
>Hm. I don't see a linguistic reason why it isn't
At 06:11 PM 3/26/2001 -0500, John Porter wrote:
>Trond Michelsen wrote:
> > I realize that memoization isn't something you want to do on functions
> > that may return different results with the same input. However I'm a bit
> > curious of when these functions are useful in sort(),
> >...
> > sor
At 04:33 PM 3/26/2001 -0500, John Porter wrote:
>Dan Sugalski wrote:
> > The only issue there is whether memoization is appropriate. It could be
> > argued that it isn't (it certainly isn't with perl 5) though I for one
> > wouldn't mind being able to more aggressively assume that data was
> > sem
On Mon, Mar 26, 2001 at 03:36:08PM -0500, Dan Sugalski wrote:
>>> because that would require the PSI::ESP module which isn't working
>>> yet.
>> Not at all. Simon's example looks like a simple case of memoization.
>> The cache only needs to be maintained for the duration of the sort,
>> and it al
Jarkko Hietaniemi wrote:
> It's all about reduction to primitive-comparable and the
> relative cost of it.
You're right. Extraction of fields is only one example.
(But it's illustrative, no?)
--
John Porter
Useless use of time in void context.
On Mon, Mar 26, 2001 at 05:29:24PM -0500, John Porter wrote:
> Jarkko Hietaniemi wrote:
> > ST (or GR) applies to any situation where you your sort
> > comparator function isn't directly expressible with (Perl) primitives,
> > and worthwhile it is (like Yoda feel I) when the cost of converting
> >
Jarkko Hietaniemi wrote:
> ST (or GR) applies to any situation where you your sort
> comparator function isn't directly expressible with (Perl) primitives,
> and worthwhile it is (like Yoda feel I) when the cost of converting
> the keys (so that the primitives can again be employed) begins to
> do
On Mon, Mar 26, 2001 at 05:17:38PM -0500, John Porter wrote:
> Simon Cozens wrote:
> > With all due respect, that's not been my experience. Even beginners know
> > how to do things like "length", by far the most common case for the ST.
>
> You must be kidding. Sorting a list of strings by length
Simon Cozens wrote:
> With all due respect, that's not been my experience. Even beginners know
> how to do things like "length", by far the most common case for the ST.
You must be kidding. Sorting a list of strings by length is more
common that, say, sorting them numerically by some embedded nu
On Mon, Mar 26, 2001 at 04:54:51PM -0500, Uri Guttman wrote:
> well, you must be hanging around smart newbies. :)
No, I just learn 'em right. :)
--
The Blit is a nice terminal, but it runs emacs.
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> On Mon, Mar 26, 2001 at 04:36:35PM -0500, Uri Guttman wrote:
>> and even creating a function to extract the key is not for
>> beginners in many case. most of the time i see issues with the ST
>> is with key extraction.
SC> Wit
On Mon, Mar 26, 2001 at 04:36:35PM -0500, Uri Guttman wrote:
> SC> Do you see any ESP there? Do you see any parsing of arbitrary
> SC> pieces of code? No, me neither.
>
> and even creating a function to extract the key is not for beginners in
> many case. most of the time i see issues with th
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> No, it wouldn't, don't be silly. The ST can always be generalized to
SC> ST(data, func, compare) =
SC> map { $_->[0] } sort { compare($a->[1], $b->[1]) } map { [$_, f($_)] } data
and i don't see multiple keys or sort order selec
Dan Sugalski wrote:
> The only issue there is whether memoization is appropriate. It could be
> argued that it isn't (it certainly isn't with perl 5) though I for one
> wouldn't mind being able to more aggressively assume that data was
> semi-constant...
The :idempotent attribute for subs?
On Mon, Mar 26, 2001 at 03:36:08PM -0500, Dan Sugalski wrote:
> The only issue there is whether memoization is appropriate. It could be
> argued that it isn't (it certainly isn't with perl 5)
Hm. I don't see a linguistic reason why it isn't with perl5. Unless the
comparisign function as a whol
At 03:23 PM 3/26/2001 -0500, Adam Turoff wrote:
>On Mon, Mar 26, 2001 at 10:50:09AM -0500, Uri Guttman wrote:
> > > "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
> > SC> Why can't Perl automagically do a Schwartzian when it sees a
> > SC> comparison with complicated operators or functio
On Mon, Mar 26, 2001 at 10:50:09AM -0500, Uri Guttman wrote:
> > "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
> SC> Why can't Perl automagically do a Schwartzian when it sees a
> SC> comparison with complicated operators or functions on each side of
> SC> it? That is, @s = sort { f(
On Mon, Mar 26, 2001 at 08:25:17AM -0800, Peter Scott wrote:
> I'm kinda puzzled by the focus on Schwartzian when I thought the GRT was
> demonstrated to be better.
Because the transform is a specialized case
of the schwartzian transform where the default sort is sufficient.
Address the issu
On Mon, Mar 26, 2001 at 10:50:09AM -0500, Uri Guttman wrote:
> SC> it? That is, @s = sort { f($a) <=> f($b) } @t
>
> because that would require the PSI::ESP module which isn't working
> yet. how would perl intuit exactly the relationship between the records
> and the keys extraction and compar
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> I'm kinda puzzled by the focus on Schwartzian when I thought the
PS> GRT was demonstrated to be better. Anyway, all we need is a
PS> syntax for specifying an extraction function and whether the
PS> comparison is string or numeric
At 10:50 AM 3/26/2001 -0500, Uri Guttman wrote:
> > "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
>
> SC> Why can't Perl automagically do a Schwartzian when it sees a
> SC> comparison with complicated operators or functions on each side of
> SC> it? That is, @s = sort { f($a) <=> f($
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> Why can't Perl automagically do a Schwartzian when it sees a
SC> comparison with complicated operators or functions on each side of
SC> it? That is, @s = sort { f($a) <=> f($b) } @t would Do The Right
SC> Thing.
because that wo
On Tue, Mar 20, 2001 at 11:15:51PM -0500, John Porter wrote:
> So you think
>
> @s =
> map { $_->[0] }
> sort { $a->[1] <=> $b->[1] }
> map { [ $_, /num:(\d+)/ ] }
> @t;
>
> would be more clearly written as
>
> @s = schwartzian(
> {
> second_map => sub { $_->
On Tue, Mar 20, 2001 at 11:15:51PM -0500, John Porter wrote:
> Adam Turoff wrote:
> > This message is not an RFC, nor is it an intent to add a feature
> > to Perl or specify a syntax for that feature[*].
>
> Yay.
>
[...]
> So you think
>
> @s =
> map { $_->[0] }
> sort { $a->[1
i have to put my 2 cents in...
after reading all the discussion so far about the Schwartz,
i feel that map{} sort map{} is perfect in it's syntax.
if you code and understand Perl (i've seen situations where
these aren't always both happening at the time) and knowingly
use the building block fun
On Thu, Mar 22, 2001 at 11:13:47PM -0500, John Porter wrote:
> Brent Dax wrote:
> > Someone else showed a very ugly syntax with an anonymous
> > hash, and I was out to prove there was a prettier way to do it.
> Do we want prettier? Or do we want more useful?
> Perl is not exactly known for its pr
Brent Dax wrote:
>
> Someone else showed a very ugly syntax with an anonymous
> hash, and I was out to prove there was a prettier way to do it.
Do we want prettier? Or do we want more useful?
Perl is not exactly known for its pretty syntax.
--
John Porter
>> "Brent" == Brent Dax <[EMAIL PROTECTED]> writes:
> Brent> @s = schwartzian(
> Please, if we're going to add an operator, let's not call it schwartzian!
> I have enough trouble already telling people how to spell my name. :)
Which is why my real suggestion was a 'tsort' ('tsort' eq 'tr
> this would have to be a proper module and not a builtin op. there is no
> reason to make this built in.
This was essentially my point with regards to naming this op
"map_sort_map". Just explaining the function of the op negates its
usefulness *as* an op, because of the complexity of extracting
> "RLS" == Randal L Schwartz <[EMAIL PROTECTED]> writes:
RLS> sort { $a/$b expression } { transforming expression, glued with $_ } @list
RLS> so $a->[0] is guaranteed to be the original element, and the list-return
RLS> value of the second block becomes $a->[1]... $a->[$#$a].
RLS> S
> "Dan" == Dan Brian <[EMAIL PROTECTED]> writes:
Dan> IMO the very quest for a name would be reason enough to not do it.
Dan> "map_sort_map"? That begs the question. And since Randal asks that it not
Dan> be named after him ... (I heard he filed a trademark on Schwartzian, so
Dan> that's out.
Could someone summarize the arguments for such an operator? Doing so, to
me, seems to subtrack from the scripting domain something which belongs
there. Teaching the transform in classes is a wonderful way to both
illustrate the power of Perl's map, and more importantly, help programmers
understand
> "Brent" == Brent Dax <[EMAIL PROTECTED]> writes:
Brent> @s = schwartzian(
Please, if we're going to add an operator, let's not call it schwartzian!
I have enough trouble already telling people how to spell my name. :)
Maybe I should have a kid named "Ian", so I can see on a roster some
Zenon Zabinski wrote:
> Personally, I have never used the Schwartzian Transform ...
> so I may not be fully knowledgeable of its usefulness.
>
> do you need to understand the
> intricacies if you can just cut and paste and just change a few
> variables?
Not to be harsh, but you probably *do*
John Porter declared:
Adam Turoff wrote:
> This message is not an RFC, nor is it an intent to add a feature to Perl
or specify a syntax for that feature[*].
Yay.
> We're all for making easy things easy, but the complexities of
> "map {} sort {} map {} @list" has always been befuddling to newbies,
Hey,
I just have a couple of ideas that may either make me look like a fool
or provoke some discussion:
Personally, I have never used the Schwartzian Transform (but I have
heard, looked at it), so I may not be fully knowledgeable of its
usefulness. However, do the advantages of including it o
> Loooking over dev.perl.org/rfc, only two RFCs mention sorting:
> RFC 124: Sort order for any hash
> RFC 304: sort algorithm to be selectable at compile time
>
> and none mentioning the Schwartz. :-)
>
> This message is not an RFC, nor is it an intent to add a feature
> to Perl or
Bart Lateur wrote:
> IMHO, it is: HoA, HoH, LoA, LoH
But that's only two levels, when the number of levels
can really be unbounded. Only the *top* level can be
a list, rather than an array.
Since any two levels can have a relationship
...->[0]->[0]->...
...->[0]->{X}->...
On Wed, 21 Mar 2001 15:40:20 -0500, John Porter wrote:
>Uri Guttman wrote:
>> JP> y/L/A/;
>>
>> tell that to perllol :)
>
>I do, through clenched teeth, every time I see it.
IMHO, it is:
HoA
HoH
LoA
LoH
--
Bart.
Uri Guttman wrote:
> JP> y/L/A/;
>
> tell that to perllol :)
I do, through clenched teeth, every time I see it.
"Perl: Laughing Out Loud" :-)
> the 'ian' suffix is overkill. think
> about all the classic mathematical transforms and they don't append
> 'ian' to the person's name. fourier,
> "JP" == John Porter <[EMAIL PROTECTED]> writes:
JP> Uri Guttman wrote:
>> records can be strings, or any perl [LH]o[LH].
JP> y/L/A/;
tell that to perllol :)
>> for a schwartz (drop the 'ian') or GR transform.
JP> Why? So it conforms with the "Guttman-Rosler" naming standard
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> On Wed, Mar 21, 2001 at 10:24:05AM -0500, John Porter wrote:
>> Uri Guttman wrote:
>> > records can be strings, or any perl [LH]o[LH].
>>
>> y/L/A/;
>>
>>
>> > for a schwartz (drop the 'ian') or GR transform.
>
> "John" == John Porter <[EMAIL PROTECTED]> writes:
John> No special name, huh? Maybe that's the way it ought to be.
That's the way I feel occasionally about the Schwartzian Transform,
actually. Having to explain that it was named *for* me but not *by*
me (in fact, actually to spite me, if
Jarkko Hietaniemi wrote:
> (John Macdonald suggested the trick to me at least a year before
> the GR paper, and it's there in the Sorting chapter, though it is
> not called by any special name...)
Very interesting indeed.
No special name, huh? Maybe that's the way it ought to be.
--
John Porte
On Wed, Mar 21, 2001 at 10:24:05AM -0500, John Porter wrote:
> Uri Guttman wrote:
> > records can be strings, or any perl [LH]o[LH].
>
> y/L/A/;
>
>
> > for a schwartz (drop the 'ian') or GR transform.
>
> Why? So it conforms with the "Guttman-Rosler" naming standard?
Which *I* would call
Uri Guttman wrote:
> records can be strings, or any perl [LH]o[LH].
y/L/A/;
> for a schwartz (drop the 'ian') or GR transform.
Why? So it conforms with the "Guttman-Rosler" naming standard?
--
John Porter
Adam Turoff <[EMAIL PROTECTED]> writes:
> We're all for making easy things easy, but the complexities of
> "map {} sort {} map {} @list" has always been befuddling to newbies,
> especially when reading the code left-to-right.
I've always thought that the purpose of the Schwartzian transform was
On Tue, Mar 20, 2001 at 11:15:51PM -0500, John Porter wrote:
> @s = schwartzian(
> {
> second_map => sub { $_->[0] },
> the_sort=> sub { $a->[1] <=> $b->[1] },
> first_map => sub { [ $_, /num:(\d+)/ ] },
> },
> @t );
Hm. I'd rather see:
schwartzian({/num:(\d
> "JP" == John Porter <[EMAIL PROTECTED]> writes:
JP> Is that really an improvement?
JP> Every programmer understands right-to-left data flow when it's
JP> written with parentheses. Perl novices just need to understand
JP> that
JP> map { & } sort { & } map { & } @
JP> is a mer
Adam Turoff wrote:
> This message is not an RFC, nor is it an intent to add a feature
> to Perl or specify a syntax for that feature[*].
Yay.
> We're all for making easy things easy, but the complexities of
> "map {} sort {} map {} @list" has always been befuddling to newbies,
> especially w
86 matches
Mail list logo
