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
> 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);
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
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
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
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
While all the discussion around Schwartzian transforms is interesting, the
single ultimate question is:
"Can perl automatically optimize away function and tie calls inside
a sort function, and under what circumstances?"
It doesn't really matter if the functions inside the sort function a
Dan Sugalski wrote:
> It doesn't really matter if the functions inside the sort function are
> idempotent--what matters is whether it's OK for us to go and memoize the
> things (or whatever else we might choose to do)
Exactly, that's what I've been trying to say.
And that's why I propose the :c
On Wed, Mar 28, 2001 at 11:11:20AM -0500, Dan Sugalski wrote:
>"Can perl automatically optimize away function and tie calls inside
> a sort function, and under what circumstances?"
Agreed.
> It doesn't really matter if the functions inside the sort function are
> idempotent--what matters
At 11:22 AM 3/28/2001 -0500, John Porter wrote:
>Dan Sugalski wrote:
> > It doesn't really matter if the functions inside the sort function are
> > idempotent--what matters is whether it's OK for us to go and memoize the
> > things (or whatever else we might choose to do)
>
>Exactly, that's what I
James Mastros wrote:
> I'm of the opinion that we should consider 3 to be Just Plain Silly and not
> worth worring about overmuch.
AFAICT, you're worrying about everything overmuch.
It suffices, I believe, to put the following contract on the
sort() function:
If the user-supplied comparison
On Wednesday 28 March 2001 11:47, Dan Sugalski wrote:
> At 11:22 AM 3/28/2001 -0500, John Porter wrote:
> >Dan Sugalski wrote:
> > > It doesn't really matter if the functions inside the sort function are
> > > idempotent--what matters is whether it's OK for us to go and memoize
> > > the things (o
Dan Sugalski wrote:
>...
> subs inside the sort sub are called" then life becomes much easier.
Easier for perl. Don't we want to make life easier for the programmer?
I mean, in general, it would be nice if there were a way to have
perl memoize for us, rather than have to arrange it ourself.
It c
On Wed, Mar 28, 2001 at 11:59:19AM -0500, John Porter wrote:
> I mean, in general, it would be nice if there were a way to have
> perl memoize for us, rather than have to arrange it ourself.
Again with the over-specific solutions! What you seem to want is for
(for instance)
sub foo :memoize
At 11:59 AM 3/28/2001 -0500, John Porter wrote:
>Dan Sugalski wrote:
> >...
> > subs inside the sort sub are called" then life becomes much easier.
>
>Easier for perl. Don't we want to make life easier for the programmer?
>I mean, in general, it would be nice if there were a way to have
>perl mem
Since I'm supposed to be summarizing this thread for Simon's weekly write-up,
let me make sure I have the four(?) basic suggestions/stances.
1) There are too many variations/problems/issues to bother having Perl try to
handle them all. If folks want an optimized sort, they should continue to
Dan Sugalski <[EMAIL PROTECTED]> writes:
> I'm actually considering whether we even need to care what the
> programmer's said. If we can just flat-out say "We may optimize your
> sort function, and we make no guarantees as to the number of times tied
> data is fetched or subs inside the sort sub
John Porter <[EMAIL PROTECTED]> writes:
> If the user-supplied key extraction function is tagged with
> :function/:pure (or whatever), then perl is free to optimize
> the operation of sort() by memoizing the results of calls to
> that function.
I'd really like to see a concrete example o
> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> >we can just flat-out say "We may optimize your
> > sort function"
>
> I am strongly in favor of that approach. I see no reason to allow for
> weird side effects in Perl 6.
Let me second the motion. "Allow optimisation" should be the default. A
Russ Allbery wrote:
> I'd really like to see a concrete example of a sane sorting function which
> cannot be memoized. (Issues of syntax aside; just caching the result of
> comparing any two pairs of data results in caching data that a sane
> sorting algorithm will never use again.
Well, we se
At 01:22 PM 3/28/2001 -0800, Russ Allbery wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > I'm actually considering whether we even need to care what the
> > programmer's said. If we can just flat-out say "We may optimize your
> > sort function, and we make no guarantees as to the number of
On Wed, Mar 28, 2001 at 04:36:58PM -0500, Dan Sugalski wrote:
> With perl, though, this does
> potentially unexpected things if $i is tied. Do we still optimize it away?
> Do we only do it if we can tell that $i's not tied?
Yep. And in non-trivial cases, the only way to do that might be for $i
On Wed, Mar 28, 2001 at 05:57:30PM -0500, James Mastros wrote:
> [A bunch of stuff]
Oh, and I agree with sombody else on this thread that unless otherwise
stated, the sort should always assume statelessness (and thus the ability to
cache at will). If it's trivial to see that the sort function isn
Are we over-optimizing? The Perl is just an interpreter language.
Who really needs this kind of optimization for Perl? Even C does
not provide this feature. Though Pascal/Ada have distinctions
like function/procedure, it does not make them any faster than C.
Just given its ugly name, I hate to se
> - Make readability your main objective. Readability is possibly the
> weakest part of Perl.
>
> - Keep your eyes on modularity. Modularity is by far the best concept
> where complexity could be hidden.
>
> - Don't forget usability. This is after all the point why people use
> Perl in the first
25 matches
Mail list logo
