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, 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,
-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, 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
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
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
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
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
> 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:
> 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
> >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
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
"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
"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
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
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.
> 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
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
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
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
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 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.
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
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
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
> 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 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 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
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
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
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
> "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 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 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
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
64 matches
Mail list logo
