Uri persisted:
> DC> How do you know that the values of %lookup are strings? DC> How
> would the optimizer know?
>
> because that would be the default comparison and the extracted key value
> would be stringified unless some other marker is used. most sorts are on
> strings so this would be a
> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
LP> Uri Guttman writes:
>> because that would be the default comparison and the extracted key value
>> would be stringified unless some other marker is used. most sorts are on
>> strings so this would be a useful huffman and removal of
Uri Guttman writes:
> because that would be the default comparison and the extracted key value
> would be stringified unless some other marker is used. most sorts are on
> strings so this would be a useful huffman and removal of a redundancy.
While I like where most of this is going, I beg to diff
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Uri wrote:
DC> @out = sort
DC> [ { ~ %lookup{ .{remotekey} } }, #1
>> if string cmp is the default, wouldn't that ~ be redundant?
DC> How do you know that the values of %lookup are strings?
DC
Uri wrote:
DC> If a key-extractor block returns number, then C<< <=> >> is used to
DC> compare those keys. Otherwise C is used. In either case, the
DC> returned keys are cached to optimize subsequent comparisons against
DC> the same element.
i would make cmp the default as it is now.
Err
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Suppose C's signature is:
DC> type KeyExtractor ::= Code(Any) returns Any;
DC> type Comparator ::= Code(Any, Any) returns Int;
DC> type Criterion::= KeyExtractor
DC> | Comparator
Joe Gottman asked:
If we use this signature, won't the code
sort ('foo', 'bar', 'glarch');
attempt to use the first parameter as a Criteria?
No. Because a string like 'foo' wouldn't match the first parameter's type.
Since sort has to be a multi sub anyhow, why don't we do
multi s
- Original Message -
From: "Damian Conway" <[EMAIL PROTECTED]>
To: "Larry Wall" <[EMAIL PROTECTED]>
Cc: "Perl 6 Language" <[EMAIL PROTECTED]>
Sent: Sunday, February 15, 2004 5:59 PM
Subject: [perl] Re: The Sort Problem
> Here's a proposed syntax and semantics for C that tries to preserv
Here's a proposed syntax and semantics for C that tries to preserve the
(excellent) features of Uri's "on the right track" proposal whilst integrating
it into the Perl 6 design without multiplying entities (especially colons!)
unnecessarily.
Suppose C's signature is:
type KeyExtractor ::=
