On Friday, February 20, 2004, at 05:48 , Damian Conway wrote:
Joe Gottman asked:
How do you decide whether a key-extractor block returns number? Do
you look at the signature, or do you simply evaluate the result of
the key-extractor for each element in the unsorted list? For example,
wha
Smylers wrote:
Oh. I'd been assuming that quote marks indicated strings, and that,
while a string containing only digits could obviously be treated as a
number (as in Perl 5), it wouldn't be one without being provoked.
Correct.
What about:
$x = '0345';
Is that a number?
Nope. A string (un
Luke wrote:
I think you're forgetting what language you're talking about. Those are
numbers. After this statement:
$x = '345';
C<$x> is a number.
I don't think so. C<$x> is, of course, a variable. And what it contains after
that statement will depend on whether the variable is explicitly
Smylers wrote:
sort {$_.key} (1=> 'a', 10 => 'b', 2 =>'c');
There is nothing in the signature of the key-extractor to suggest that
all the keys are numbers, but as it turns out they all are.
Are they? I'd been presuming that pair keys would always be strings
Nope.
> and that the C<< => >>
Uri wondered:
DC> No. C<< &infix:<=> >> is the name of the binary C<< <=> >> operator.
so how is that allowed there without a block?
A Code object in a scalar context yields a Code reference.
Damian
Joe Gottman asked:
How do you decide whether a key-extractor block returns number? Do you
look at the signature, or do you simply evaluate the result of the
key-extractor for each element in the unsorted list? For example, what is
the result of the following code?
sort {$_.key} (1=> 'a
Smylers writes:
> Luke Palmer writes:
>
> > After this statement:
> >
> > $x = '345';
> >
> > C<$x> is a number.
>
> Oh. I'd been assuming that quote marks indicated strings, and that,
> while a string containing only digits could obviously be treated as a
> number (as in Perl 5), it would
At 2:49 PM -0700 2/20/04, Luke Palmer wrote:
After this statement:
$x = '345';
C<$x> is a number.
No, it isn't. It's a string. Or, rather, it's a PerlScalar.
I should hope it would be treated as one during
multimethod dispatch.
I should certainly hope *not*. If so, it's a bug. We ought to go
Luke Palmer writes:
> After this statement:
>
> $x = '345';
>
> C<$x> is a number.
Oh. I'd been assuming that quote marks indicated strings, and that,
while a string containing only digits could obviously be treated as a
number (as in Perl 5), it wouldn't be one without being provoked.
>
Smylers writes:
> Joe Gottman writes:
>
> > sort {$_.key} (1=> 'a', 10 => 'b', 2 =>'c');
> >
> > There is nothing in the signature of the key-extractor to suggest that
> > all the keys are numbers, but as it turns out they all are.
>
> Are they? I'd been presuming that pair keys would alw
Joe Gottman writes:
> sort {$_.key} (1=> 'a', 10 => 'b', 2 =>'c');
>
> There is nothing in the signature of the key-extractor to suggest that
> all the keys are numbers, but as it turns out they all are.
Are they? I'd been presuming that pair keys would always be strings (as
for hashes in
Smylers writes:
> Luke Palmer writes:
>
> > Uri Guttman writes:
> >
> > > > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
> >
> > > DC> @sorted = sort {-M}=>{$^b cmp $^a} @unsorted;
> > >
> > > but there is no comma before @unsorted. is that correct?
> >
> > Yes. Commas may be
Luke Palmer writes:
> Uri Guttman writes:
>
> > > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>
> > DC> @sorted = sort {-M}=>{$^b cmp $^a} @unsorted;
> >
> > but there is no comma before @unsorted. is that correct?
>
> Yes. Commas may be ommitted on either side of a block whe
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Uri bemoaned:
cause you agonize me head!
DC> sort &infix:<=> @unsorted
>> my brane hertz!!
>> so that declares (creates?) an infix op as a code block?
DC> No. C<< &infix:<=> >> is the name of the binary C<< <=> >> operator.
On Fri, Feb 20, 2004 at 02:47:55PM +1100, Damian Conway wrote:
: Yep. Inside the body of C you'd access them as:
:
: $by.trait{descending}
: $by.trait{insensitive}
:
: (unless Larry's changed the trait accessor syntax since last I looked).
Well, if traits are just compile-time proper
Uri bemoaned:
DC> sort &infix:<=> @unsorted
my brane hertz!!
so that declares (creates?) an infix op as a code block?
No. C<< &infix:<=> >> is the name of the binary C<< <=> >> operator.
amazing how you and luke both came up with the exact same answer.
"Great minds..." etc. ;-)
> p6 synt
> "JG" == Joe Gottman <[EMAIL PROTECTED]> writes:
JG>How do you decide whether a key-extractor block returns number? Do you
JG> look at the signature, or do you simply evaluate the result of the
JG> key-extractor for each element in the unsorted list? For example, what is
JG> t
> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
LP> Uri Guttman writes:
>> > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> # Modtimewise numerically ascending...
DC> @sorted = sort {-M $^a <=> -M $^b} @unsorted;
>>
DC> # Fuzz-ifically...
DC> sub fuzzy_cmp($x, $y) r
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> No. But this will work:
DC> sort &infix:<=> @unsorted
my brane hertz!!
so that declares (creates?) an infix op as a code block? and since <=>
is known to take 2 args it is parsed (or multidispatched) as a
comparator block for sor
Uri checked:
DC> @sorted = sort {$^a <=> $^b} @unsorted;
so because that has 2 placeholders, it is will match this signature:
type Comparator ::= Code(Any, Any) returns Int;
Correct.
i have to remember that placeholders are really implied args to a code
block and not just in the
- Original Message -
From: "Damian Conway" <[EMAIL PROTECTED]>
To: "Perl 6 Language" <[EMAIL PROTECTED]>
Sent: Thursday, February 19, 2004 8:29 PM
Subject: [perl] The Sort Problem: a definitive ruling
> C in Perl6 is a global multisub:
>
>
Luke Palmer writes:
> Yes. Commas may be ommitted on either side of a block when used as an
> argument. I would argue that they only be omitted on the right side, so
> that this is unambiguous:
>
> if some_function { ... }
> { ... }
>
> Which might be parsed as either:
>
> if (so
Uri Guttman writes:
> > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
> DC> # Modtimewise numerically ascending...
> DC> @sorted = sort {-M $^a <=> -M $^b} @unsorted;
>
> DC> # Fuzz-ifically...
> DC> sub fuzzy_cmp($x, $y) returns Int;
> DC> @sorted = sort
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> # Stringifically ascending...
DC> @sorted = sort @unsorted;
DC> or with a single two-argument block/closure (to sort by whatever the
DC> specified comparator is):
DC> # Numerically ascending...
DC> @sorte
Dave Whipp wondered:
@sorted = sort {-M} @unsorted;
One thing I've been trying to figure out reading this: what is the signature
of prefix:-M ? i.e. how does it tell the outer block that it (the
outer-block) needs a parameter?
It doesn't. As A6 explained:
http://dev.perl.org/perl6/apocalypse
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> "Once again the Iron Designer rises to the supreme challenge of
DC> the Mailinglist Stadium and expresses the true spirit of Perl
DC> 6!!!"
and the challenge for next week is slicing squid with noodles!
(or cutting down the mightie
Dave Whipp writes:
> "Damian Conway" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > type KeyExtractor ::= Code(Any) returns Any;
>
> > # Modtimewise numerically ascending...
> > @sorted = sort {-M} @unsorted;
>
>
> One thing I've been trying to figure out readin
"Damian Conway" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> type KeyExtractor ::= Code(Any) returns Any;
> # Modtimewise numerically ascending...
> @sorted = sort {-M} @unsorted;
One thing I've been trying to figure out reading this: what is the signature
of pref
The design team discussed "The Sort Problem" during yesterday's
teleconference. Here is Larry's decision: final, definitive, and unalterable
(well...for this week at least ;-)
-cut-cut-cut-cut-cut-cut
C in Perl6 is a global multisub:
multi su
29 matches
Mail list logo
