David L . Nicol <[EMAIL PROTECTED]> writes:
>Jarkko Hietaniemi wrote:
>
>> Some sort of simple markup embedded within the C comments. Hey, let's
>> extend pod! Hey, let's use XML! Hey, let's use SGML! Hey, let's use
>> XHTML! Hey, let's use lout! Hey, ...
>
>Either run pod through a pod pull
Simon Cozens wrote:
[...]
> I'm just not sure it's fair on Old World hackers. Will there be a way to stop
> Perl upgrading stuff to Unicode on the way in?
and I'm probably not the only Old World hacker that would
prefer a build option to simply eliminate Unicode support altogether...
Nick Ing-Simmons <[EMAIL PROTECTED]> opined:
> >Either run pod through a pod puller before the C preprocessor gets to
> >the code, or figure out a set of macros that can quote and ignore pod.
> >
> >The second is Yet Another Halting Problem so we go with the first?
> >
> >Which means a little prog
As a developer since a quarter century but only a few months in Perl I'm
closely following the process of creating Perl6. I'm exited and also
disappointed what's going on in this process. This morning I read an
article which is completely unrelated to Perl but might give some
insight why Perl is P
On Fri, Mar 23, 2001 at 11:34:41PM +0100, Otto Wyss wrote:
> As a developer since a quarter century but only a few months in Perl I'm
> closely following the process of creating Perl6.
> This might come from the fact Perl was/is designed by
> english speaking people. It seems that the complexity
On Fri, 23 Mar 2001 23:34:41 +0100, Otto Wyss <[EMAIL PROTECTED]> wrote:
> A study in Science (291 P.2165) found out that english speaking children
> has twice as much reading problems as italian speaking children of the
> same age. And about similar difference towards german and french. This
> co
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 { $_->
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 11:09 PM 3/23/2001 +, Simon Cozens wrote:
> >
> > For instance, chr() will produce Unicode codepoints. But
> > you can pretend that they're ASCII codepoints, it's only
> > the EBCDIC folk that'll get hurt. I hope and suspect
> > there'll be an
> "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
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($
> "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 09:09 AM 3/26/2001 -0600, Garrett Goebel wrote:
>Someone please clue me in. A pointer to an RFC which defines the use of
>colons in Perl6 among other things would help.
>
>Why not have subsequent uses of : on the same variable name perform a cast?
>Or perhaps better returned the casted value?
At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
>So the results of ord are dependent on a global setting for "current
>character set" or some such, not on the encoding of the string that
>is passed to it?
Nope, ord is dependent on the string it gets, as those strings know what
their encoding is.
At 02:58 PM 3/26/2001 +0100, Dave Mitchell wrote:
>Nick Ing-Simmons <[EMAIL PROTECTED]> opined:
> > Perhaps we could teach pod that /* was alias for =pod
> > and */ an alias for =cut ?
>
>or possibly
>
>/*=foo is an alias for =foo,
>and */ is an alias for =cut only after a /*= has been encountered
On Mon, Mar 26, 2001 at 10:02:40AM -0600, David M. Lloyd wrote:
> $obj->method; # Clearly void context.
Unless it's not. For example as the last statement in a subroutine.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
This message pretty much sums up the distributive operator thing. Thought
I'd forward it on. I guess any further discussion of this topic ought to
be on perl6-language unless some has a better idea or doesn't think this
is the right place for it.
- D
<[EMAIL PROTECTED]>
-- Forwarded m
Dan Sugalski <[EMAIL PROTECTED]> writes:
>>This the main pain with 5.7.*'s EBCDIC scheme - making
>>
>>ord('A') == 193
>>
>>true :-/
>
>That would be true if EBCDIC was the default encoding, otherwise false.
But what about
our $var;
{
use encoding 'US-ascii';
$var = 'A';
}
{use Encoding 'i
At 02:52 AM 3/25/2001 -0500, Philip Newton wrote:
>On Fri, 23 Mar 2001, Dan Sugalski wrote:
>
> > At 02:31 PM 3/23/2001 -0500, Bryan C. Warnock wrote:
> > >On Friday 23 March 2001 14:18, Dan Sugalski wrote:
> > > > At 01:30 PM 3/22/2001 -0800, Hong Zhang wrote:
> > > > >We need the character equiv
Damien Neil <[EMAIL PROTECTED]> writes:
>On Mon, Mar 26, 2001 at 11:32:46AM -0500, Dan Sugalski wrote:
>> At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
>> >So the results of ord are dependent on a global setting for "current
>> >character set" or some such, not on the encoding of the string that
Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>For length, I'd as soon it returned the number of code points, but glyphs
>and bytes are also valid return values.
And that may be where it belongs - at the language level
chars($s) == 120
bytes($s) == 480
glyphs($s) == 360
length($
On Mon, Mar 26, 2001 at 06:16:00PM +, [EMAIL PROTECTED] wrote:
> Damien Neil <[EMAIL PROTECTED]> writes:
> >On Mon, Mar 26, 2001 at 11:32:46AM -0500, Dan Sugalski wrote:
> >> At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> >> >So the results of ord are dependent on a global setting for "curr
At 11:42 AM 3/26/2001 -0600, Garrett Goebel wrote:
>From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> > > So the results of ord are dependent on a global setting for
> > > "current character set" or some such, not on the encoding
> > > of the strin
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
>>So the results of ord are dependent on a global setting for "current
>>character set" or some such, not on the encoding of the string that
>>is passed to it?
>
>Nope, ord is dependent on the string it gets,
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> > So the results of ord are dependent on a global setting for
> > "current character set" or some such, not on the encoding
> > of the string that is passed to it?
>
> Nope, ord is dependent on the s
At 05:45 PM 3/26/2001 +, [EMAIL PROTECTED] wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> >>So the results of ord are dependent on a global setting for "current
> >>character set" or some such, not on the encoding of the string that
> >>is
On Mon, Mar 26, 2001 at 11:32:46AM -0500, Dan Sugalski wrote:
> At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> >So the results of ord are dependent on a global setting for "current
> >character set" or some such, not on the encoding of the string that
> >is passed to it?
>
> Nope, ord is depen
At 04:34 PM 3/24/2001 -0800, Dave Storrs wrote:
> I'll just toss my 0.01 cents in...my thought here is that this
>thread has now tied up a lot of cycles from a lot of very smart, very
>experienced people without resulting in an answer that is clearly The
>Right Thing. Whatever we do, ther
Nick Ing-Simmons wrote:
> Perhaps we could teach pod that /* was alias for =pod
> and */ an alias for =cut ?
that won't work because pod/cut is strictly line-based and C-style
comments are strictly stream-based.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
He who sa
On Mon, Mar 26, 2001 at 01:23:36PM -0600, David L. Nicol wrote:
> Nick Ing-Simmons wrote:
> > Perhaps we could teach pod that /* was alias for =pod
> > and */ an alias for =cut ?
>
> that won't work because pod/cut is strictly line-based and C-style
> comments are strictly stream-based.
Damn. Co
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 Fri, Mar 23, 2001 at 11:34:41PM +0100, Otto Wyss wrote:
> - Make readability your main objective. Readability is possibly the
> weakest part of Perl.
There's nothing fundamentally about Perl that makes it unreadable. Seriously.
Perl doesn't write unreadable Perl, people do. You can write some
> On Fri, Mar 23, 2001 at 11:34:41PM +0100, Otto Wyss wrote:
> > - Make readability your main objective. Readability is possibly the
> > weakest part of Perl.
>
> There's nothing fundamentally about Perl that makes it unreadable. Seriously.
> Perl doesn't write unreadable Perl, people do. You ca
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
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" == 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(
Damien Neil <[EMAIL PROTECTED]> writes:
>> >So $c = chr(ord($c)) could change $c? That seems odd.
>>
>> It changes its _representation_ (e.g. from 0x45,ASCII to 0xC1,EBCDIC)
>> but not its "fundamental" 'LATIN CAPITAL LETTER A'-ness.
>> Then of course someone will want it to be the number 0x45 a
David L . Nicol <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons wrote:
>
>> Perhaps we could teach pod that /* was alias for =pod
>> and */ an alias for =cut ?
>
>that won't work because pod/cut is strictly line-based and C-style
>comments are strictly stream-based.
I was not suggesting we hunt dow
> "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
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
Paul Johnson wrote:
> David M. Lloyd wrote:
>
> > $obj->method; # Clearly void context.
>
> Unless it's not. For example as the last statement in a subroutine.
Right. Context means context! Just because there's no context-
inducing code on this line, doesn't mean there isn't somewhere
David M. Lloyd wrote:
> $a = ($obj1, $obj2)->method;# Unclear. Calling in scalar context
> # gives no benefit, since you will
> # still have 2 return values. Maybe call
> # methods in list context
> "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
Please CC Otto in all replies concerning this topic. I want to make sure he
reads how wrong he is about Perl and its readability and I think Simon sums it
up perfectly here.
I also want to add that all of those strange looking symbols make Perl the
powerful language it is. I love the freedom
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.
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
On Mon, Mar 26, 2001 at 01:11:06PM -0700, Dan Brian wrote:
> As for the English influence, you're welcome to identify ways that the
> syntax could be extended or tightened to be less so. That's the intent of
> the mailing list. But please, no more Latin ... I like positional
> dependency. :)
Hmm.
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?
> Hmm. I just relized what he's talking about. As an example, most nonsimple
> statements (IE past-tense, ones with modal and action verbs, etc) end in the
> verb. For example, an english-speaker would say:
> I must walk the god. (Subject modal-verb action-verb direct-object.)
> A german-speake
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.
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
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: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
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
Otto Wyss wrote on 3/26/01 5.41:
>A study in Science (291
>P.2165) found out that
>english speaking children has
>twice as much reading
>problems as italian speaking
>children of the same age.
>And about similar difference
>towards german and french.
>This could come from the
>fact that english h
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
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: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
> >
On Mon, Mar 26, 2001 at 08:37:05PM +, [EMAIL PROTECTED] wrote:
> >If ord is dependent on the encoding of the string it gets, as Dan
> >was saying, than ord($e) is 0x81,
>
> It it could still be 0x81 (from ebcdic) with the encoding carried
> along with the _number_ if we thought that worth t
From: Damien Neil [mailto:[EMAIL PROTECTED]]
> On Mon, Mar 26, 2001 at 08:37:05PM +, [EMAIL PROTECTED] wrote:
> > >
> > > If ord is dependent on the encoding of the string it gets, as Dan
> > > was saying, than ord($e) is 0x81,
> >
> > It it could still be 0x81 (from ebcdic) with the encodin
> The reward? English-speaking children learn what is arguably the most
> flexible and expressive spoken language in the world.
Oh good hell.
> Yup. Remember, Larry Wall is a linguist by training--he learned in school
> about human languages. He applied this knowledge to Perl.
I wish I had
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:
>
> 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.
On Mon, Mar 26, 2001 at 03:34:16PM -0800, Brent Dax wrote:
> The reward? English-speaking children learn what is arguably the most
> flexible and expressive spoken language in the world.
"Arguably"? I don't see how one could argue that, and I speak the damned
language. (I'm afraid I'm not going
"Helton, Brandon" <[EMAIL PROTECTED]> wrote:
> Please CC Otto in all replies concerning this topic. I want to make
sure
> he
> reads how wrong he is about Perl and its readability and I think Simon
> sums it
> up perfectly here.
Give the braindead no head, Brandon. I've recently come acr
"David Grove" <[EMAIL PROTECTED]> wrote:
>
> "Helton, Brandon" <[EMAIL PROTECTED]> wrote:
>
> > Please CC Otto in all replies concerning this topic. I want to make
> sure
> > he
> > reads how wrong he is about Perl and its readability and I think
Simon
> > sums it
> > up perfectly
> >A study in Science (291
> >P.2165) found out that
> >english speaking children has
> >twice as much reading
> >problems as italian speaking
> >children of the same age.
> >And about similar difference
> >towards german and french.
> >This could come from the
> >fact that english has for 40
> >p
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
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
Folks, this thread has gotten out of hand. Do please stop.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
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
-Original Message-
From: Jarkko Hietaniemi [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 26, 2001 15.43
To: Brent Dax
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Perl culture, perl readabillity
>> The reward? English-speaking children learn what is arguably the most
>> flexibl
On Mon, 26 Mar 2001, David Grove wrote:
-[chopped]-
> Python has its place, and I do support it and its growingly cocky users
> (not that they have much to be cocky about since they're the largest group
> of lamers this side of VB) and frankly it needs to stay there. Same thing
> for Java, REBOL,
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 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
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
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
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
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
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?
> "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
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:
>> 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
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
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
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
86 matches
Mail list logo
