Allison Randal is the new Project Manager
Hi, folks. As has probably been obvious to most of you, I've been really busy with my O'Reilly day job and haven't had time to attend to Perl 6 and Parrot business. With no prompting, Allison Randal stepped forward and has been taking on more and more of the day-to-day running of the show. I'm so impressed with how she's been doing that I'm officially stepping down and handing the reins to her. Best of luck to all! Nat
Re: Allison Randal is the new Project Manager
Nathan Torkington [EMAIL PROTECTED] writes: Hi, folks. As has probably been obvious to most of you, I've been really busy with my O'Reilly day job and haven't had time to attend to Perl 6 and Parrot business. With no prompting, Allison Randal stepped forward and has been taking on more and more of the day-to-day running of the show. I'm so impressed with how she's been doing that I'm officially stepping down and handing the reins to her. Best of luck to all! Thanks, Nat, and thanks, Allison! -- Johan
Re: The Sort Problem
On Mon, Feb 16, 2004 at 01:04:01AM -0700, Luke Palmer wrote: : This is pattern matching more than it is type comparison. And Perl's : all about pattern matching. I'm just wondering whether it needs Itwo : pattern archetectures. I suspect it does, at least from the viewpoint of mere mortals. The regex engine is built around the notion of ordered rules, whereas the multi dispatch engine is designed to run rules in order of distance. I think we'll have done good enough if the regex engine can be used at runtime against a list of actual argument types. The regex engine is allowed to have deep, powerful nooks, after all. People are trained not to expect to understand patterns on first glance. But I a strong gut feeling that the dispatch engine needs to remain transparent to casual readers--or there will never be any casual readers of Perl 6. Of course, someone will doubtless attempt this unification, since a single use can turn Perl into another language. It's just not a language I would have bothered to learn 25 years ago... Larry
The Sort Problem: a definitive ruling
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
Csort in Perl6 is a global multisub:
multi sub *sort(Criterion @by: [EMAIL PROTECTED]) {...}
multi sub *sort(Criterion $by: [EMAIL PROTECTED]) {...}
multi sub *sort( : [EMAIL PROTECTED]) {...}
where:
type KeyExtractor ::= Code(Any) returns Any;
type Comparator ::= Code(Any, Any) returns Int;
type Criterion::= KeyExtractor
| Comparator
| Pair(KeyExtractor, Comparator)
;
That means that we can call Csort without a block (to sort stringifically
ascending with Ccmp):
# Stringifically ascending...
@sorted = sort @unsorted;
or with a single two-argument block/closure (to sort by whatever the specified
comparator is):
# Numerically ascending...
@sorted = sort {$^a = $^b} @unsorted;
# Namewise stringifically descending case-insensitive...
@sorted = sort {lc $^b.name cmp lc $^a.name}
@unsorted;
# or...
@sorted = sort {$^b.name cmp $^a.name} is insensitive
@unsorted;
# or...
@sorted = sort {$^a.name cmp $^b.name} is descending is insensitive
@unsorted;
# Modtimewise numerically ascending...
@sorted = sort {-M $^a = -M $^b} @unsorted;
# Fuzz-ifically...
sub fuzzy_cmp($x, $y) returns Int;
@sorted = sort fuzzy_cmp, @unsorted;
or with a single one-argument block/closure (to sort according whatever the
specified key extractor returns):
# Numerically ascending...
@sorted = sort {+ $^elem} @unsorted;
@sorted = sort {+ $_} @unsorted;
# Namewise stringifically descending case-insensitive...
@sorted = sort {~ $^elem.name} is descending is insensitive @unsorted;
@sorted = sort {lc $^elem.name} is descending @unsorted;
@sorted = sort {lc .name} is descending @unsorted;
# Modtimewise numerically ascending...
@sorted = sort {-M} @unsorted;
# Key-ifically...
sub get_key($elem) {...}
@sorted = sort get_key, @unsorted;
or with a single extractor/comparator pair (to sort according to the extracted
key, using the specified comparator):
# Modtimewise stringifically descending...
@sorted = sort {-M}={$^b cmp $^a} @unsorted;
# Namewise fuzz-ifically...
@sorted = sort {.name}=fuzzy_cmp @unsorted;
or with an array of comparators and/or key extractors and/or
extractor-comparator pairs (to sort according to a cascading list of criteria):
# Numerically ascending
# or else namewise stringifically descending case-insensitive
# or else modtimewise numerically ascending
# or else namewise fuzz-ifically
# or else fuzz-ifically...
@sorted = sort [ {+ $^elem},
{$^b.name cmp $^a.name} is insensitive,
{-M},
{.name}=fuzzy_cmp,
fuzzy_cmp,
],
@unsorted;
If a key-extractor block returns number, then C = is used to compare
those keys. Otherwise Ccmp is used. In either case, the keys extracted by
the block are cached within the call to Csort, to optimize subsequent
comparisons against the same element. That is, a key-extractor block is only
ever called once for each element being sorted.
If a key-extractor/comparator pair is specified, the key-extractor is the key
of the pair and the comparator the value. The extractor is used to retreive
keys, which are then passed to the comparator.
The Cis descending and Cis insensitive traits on a key extractor or a
comparator are detected within the call to Csort (or possibly by the
compiler) and used to modify the case-sensitivity and direction of any
comparison operators used for the corresponding key or in the corresponding
comparator.
Note that ambiguous cases like:
@sorted = sort {-M}, {-M}, {-M};
@sorted = sort {$^a = $^b}, {$^a = $^b}, {$^a = $^b};
@sorted = sort [...], [...], [...];
# etc.
will be dispatched according to the normal multiple dispatch semantics
(which will mean that they will mean):
@sorted = sort {-M} == {-M}, {-M};
@sorted = sort {$^a = $^b} == {$^a = $^b}, {$^a = $^b};
@sorted = sort [...] == [...], [...];
# etc.
and so one would need to write:
@sorted = sort == {-M}, {-M}, {-M};
@sorted = sort == {$^a = $^b}, {$^a = $^b}, {$^a = $^b};
@sorted = sort == [...], [...], [...];
# etc.
to get Ccmp comparison on all the arguments.
-cut-cut-cut-cut-cut-cut
Thanks to everyone who contributed to this discussion (especially Uri). As you
see, the result is sort facility that is simultaneously much more powerful,
much easier-to-use in the simple cases, has the potential to
Re: Traits: to renew OO inheritance in a hacker style discussion
On Thu, Feb 12, 2004 at 09:38:47AM -0800, Larry Wall wrote: Yes, that's a very good paper, which is why Perl 6 now has something called Roles, which are intended to degenerate either to Traits or Interfaces. My take on it is that Roles' most important, er, role will be to abstract out the decision to compose or delegate. But we'd like them to function as interfaces when the Role is abstract, and we'd like them to function as Traits when you don't happen to specify any state attributes. But for hiding the delegation decision, you at least have to allow the amount of state that lets you remember the object you're delegating to. Of course, the Traits paper didn't go into traits with state, though it did mention it as a future research topic. We're just doing that future research for them. :-) By the way, we distinguish Traits from traits (which are compile-time properties applied by is. To apply a Role we use does. In a sense, there is no such thing as state. A read-only attribute is a role constituted of one getter method. A write-only attribute is a role constituted of one setter method. A read-write attribute is a role constituted of two methods, one getter and one setter. A noread-nowrite attribute could as well live in a parallel universe. No attributes. It is turtles all the way down. :) More seriously, the mere user of a class has no way to know if he accesses a real attribute or a synthetic one. A synthetic attribute being one that is calculated from real attributes or whose modification affects other attributes. It may interesting to provide syntax to declare the dependancies between attributes even if there is no way to enforce them. Larry
Re: The Sort Problem: a definitive ruling
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 prefix:-M ? i.e. how does it tell the outer block that it (the
outer-block) needs a parameter? There seems to be some transitive magic
going on here. Could similar magic be used to have infix:= require two
higher-order variables (e.g. could sort { = } @unsorted be made to
work?)
Dave.
Re: The Sort Problem: a definitive ruling
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 reading this: what is the signature
of prefix:-M ?
Presumably something like:
sub prefix:-M (?$file = $CALLER::_) {...}
i.e. how does it tell the outer block that it (the outer-block) needs
a parameter?
Because it operates on $_. It tells it the same way:
map { .name } @objects
Does. Of course, this is going to be tough on the compiler, who will
have to take the C= $CALLER::_ part into account.
There seems to be some transitive magic going on here. Could similar
magic be used to have infix:= require two higher-order variables
(e.g. could sort { = } @unsorted be made to work?)
No. Although you could do such a thing with:
sort infix:=, @unsorted;
Luke
Re: The Sort Problem: a definitive ruling
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 mightiest tree in the forest with a herring) good job all. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: The Sort Problem: a definitive ruling
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/A06.html#Bare_subs
any block that doesn't have placeholder-specified parameters but which refers
(even implicitly) to $_ will automatically have the signature of ($_).
That's why:
@odd = grep { $_ % 2 } @nums;
will still work in Perl 6.
Since a bare C-M implicitly refers to $_, the surrounding block
automagically gets a one-parameter signature and hence is (correctly!)
interpreted as a key extractor.
Don't you just love it when a plan^H^H^H^Hdesign comes together? ;-)
There seems to be some transitive magic going on here.
There is. Kinda. Just not the type of magic you thought.
Could similar magic be used to have infix:= require two
higher-order variables (e.g. could sort { = } @unsorted be made to
work?)
No. But this will work:
sort infix:= @unsorted
Damian
Re: The Sort Problem: a definitive ruling
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 @sorted = sort {$^a = $^b} @unsorted;
so because that has 2 placeholders, it is will match this signature:
type Comparator ::= Code(Any, Any) returns Int;
i have to remember that placeholders are really implied args to a code
block and not just in the expression
DC # Namewise stringifically descending case-insensitive...
DC @sorted = sort {lc $^b.name cmp lc $^a.name}
DC @unsorted;
DC # or...
DC @sorted = sort {$^b.name cmp $^a.name} is insensitive
DC @unsorted;
DC # or...
DC @sorted = sort {$^a.name cmp $^b.name} is descending is insensitive
DC @unsorted;
TIMTOWTDI lives on!
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 fuzzy_cmp, @unsorted;
ok, so that is recognizes as a compare sub due to the 2 arg sig. so does
the sub must be defined/declared before the sort code is compiled?
DC or with a single one-argument block/closure (to sort according
DC whatever the specified key extractor returns):
DC # Numerically ascending...
DC @sorted = sort {+ $^elem} @unsorted;
DC @sorted = sort {+ $_} @unsorted;
is $^elem special? or just a regular place holder? i see $_ will be set
to each record as we discussed.
DC # Namewise stringifically descending case-insensitive...
DC @sorted = sort {~ $^elem.name} is descending is insensitive @unsorted;
DC @sorted = sort {lc $^elem.name} is descending @unsorted;
DC @sorted = sort {lc .name} is descending @unsorted;
just getting my p6 chops back. .name is really $_.name so that makes
sense. and $^elem is just a named placeholder for $_ as before?
DC # Key-ifically...
DC sub get_key($elem) {...}
DC @sorted = sort get_key, @unsorted;
and that is parsed as an extracter code call due to the single arg
sig. again, it appears that it has to be seen before the sort code for
that to work.
DC or with a single extractor/comparator pair (to sort according to the
DC extracted key, using the specified comparator):
DC # Modtimewise stringifically descending...
DC @sorted = sort {-M}={$^b cmp $^a} @unsorted;
so that is a single pair of extractor/comparator. but there is no comma
before @unsorted. is that correct? see below for why i ask that.
DC # Namewise fuzz-ifically...
DC @sorted = sort {.name}=fuzzy_cmp @unsorted;
i first parsed that as being wrong and the {} should wrap the whole
thing. so that is a pair again of extractor/comparator.
DC or with an array of comparators and/or key extractors and/or
DC extractor-comparator pairs (to sort according to a cascading list of
DC criteria):
DC # Numerically ascending
DC # or else namewise stringifically descending case-insensitive
DC # or else modtimewise numerically ascending
DC # or else namewise fuzz-ifically
DC # or else fuzz-ifically...
DC @sorted = sort [ {+ $^elem},
DC {$^b.name cmp $^a.name} is insensitive,
DC {-M},
DC {.name}=fuzzy_cmp,
DC fuzzy_cmp,
i see the need for commas in here as it is a list of criteria.
DC ],
but what about that comma? no other example seems to have one before the
@unsorted stuff.
DC @unsorted;
DC If a key-extractor block returns number, then C = is used to
DC compare those keys. Otherwise Ccmp is used. In either case, the keys
DC extracted by the block are cached within the call to Csort, to
DC optimize subsequent comparisons against the same element. That is, a
DC key-extractor block is only ever called once for each element being
DC sorted.
where does the int optimizer come in? just as you had it before in the
extractor code? that will need to be accessible to the optimizer if the
GRT is to work correctly.
i like that the key caching is defined here. we can implement it in
several different ways depending on optimization hints and such. we
could support the ST, GRT and orchish and select the best one for each
sort. or we could have one basic sort and load the others as pragmas or
modules.
DC The Cis descending and Cis insensitive traits on a key extractor
DC or a comparator are detected within the call to Csort (or possibly
DC by the compiler) and used to modify the case-sensitivity and
DC direction of any comparison operators used for the corresponding key
DC or in the corresponding comparator.
or by reversing the order of the
Re: The Sort Problem: a definitive ruling
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 fuzzy_cmp, @unsorted;
ok, so that is recognizes as a compare sub due to the 2 arg sig. so does
the sub must be defined/declared before the sort code is compiled?
Nope. Csort is declared as a multimethod. This works, too:
$code = sub ($a, $b) { -M $a = -M $b };
@sorted = sort $code, @unsorted;
DC or with a single one-argument block/closure (to sort according
DC whatever the specified key extractor returns):
DC # Numerically ascending...
DC @sorted = sort {+ $^elem} @unsorted;
DC @sorted = sort {+ $_} @unsorted;
is $^elem special? or just a regular place holder? i see $_ will be set
to each record as we discussed.
Those two statements are exactly the same in every way. Well, except
how they're writted. $^elem is indeed a regular placeholder. $_
becomes an implicit parameter when it is referred to, in the absence of
placeholders or another type of signature.
DC # Key-ifically...
DC sub get_key($elem) {...}
DC @sorted = sort get_key, @unsorted;
and that is parsed as an extracter code call due to the single arg
sig. again, it appears that it has to be seen before the sort code for
that to work.
Nope. Runtime dispatch as before.
DC or with a single extractor/comparator pair (to sort according to the
DC extracted key, using the specified comparator):
DC # Modtimewise stringifically descending...
DC @sorted = sort {-M}={$^b cmp $^a} @unsorted;
so that is a single pair of extractor/comparator. but there is no comma
before @unsorted. is that correct? see below for why i ask that.
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 (some_function { ... }) { ... }
Or:
if (some_function()) {...}
{...} # Bare block
DC or with an array of comparators and/or key extractors and/or
DC extractor-comparator pairs (to sort according to a cascading list of
DC criteria):
DC # Numerically ascending
DC # or else namewise stringifically descending case-insensitive
DC # or else modtimewise numerically ascending
DC # or else namewise fuzz-ifically
DC # or else fuzz-ifically...
DC @sorted = sort [ {+ $^elem},
DC {$^b.name cmp $^a.name} is insensitive,
DC {-M},
DC {.name}=fuzzy_cmp,
DC fuzzy_cmp,
i see the need for commas in here as it is a list of criteria.
DC ],
but what about that comma? no other example seems to have one before the
@unsorted stuff.
It's not a closure, so you need a comma.
DC @unsorted;
DC If a key-extractor block returns number, then C = is used to
DC compare those keys. Otherwise Ccmp is used. In either case, the keys
DC extracted by the block are cached within the call to Csort, to
DC optimize subsequent comparisons against the same element. That is, a
DC key-extractor block is only ever called once for each element being
DC sorted.
where does the int optimizer come in? just as you had it before in the
extractor code? that will need to be accessible to the optimizer if the
GRT is to work correctly.
If the block provably returns an int, Csort might be able to optimize
for ints. Several ways to provably return an int:
my $extractor = an int sub($arg) { $arg.num }
@sorted = sort $extractor, @unsorted;
Or with a smarter compiler:
@sorted = sort { int .num } @unsorted;
Or Csort might even check whether all the return values are ints and
then optimize that way. No guarantees: it's not a language-level issue.
i like that the key caching is defined here.
Yeah. This is a language-level issue, as the blocks might have
side-effects.
DC Note that ambiguous cases like:
DC @sorted = sort {-M}, {-M}, {-M};
DC will be dispatched according to the normal multiple dispatch semantics
DC (which will mean that they will mean):
DC @sorted = sort {-M} == {-M}, {-M};
DC and so one would need to write:
DC @sorted = sort == {-M}, {-M}, {-M};
that clears up that one for me.
this is very good overall (notwithstanding my few nits and
questions). it will satisfy all sorts of sort users, even those who are
out of sorts.
Agreed. I'm very fond of it..
Luke
Re: The Sort Problem: a definitive ruling
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 (some_function { ... }) { ... }
Or:
if (some_function()) {...}
{...} # Bare block
Silly me. That doesn't solve anything. I don't know why I thought it
did. I still think that this looks weird:
foo $bar { ... } $baz;
But that's just preference.
Luke
Re: The Sort Problem: a definitive ruling
- 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
Csort in Perl6 is a global multisub:
multi sub *sort(Criterion @by: [EMAIL PROTECTED]) {...}
multi sub *sort(Criterion $by: [EMAIL PROTECTED]) {...}
multi sub *sort( : [EMAIL PROTECTED]) {...}
where:
type KeyExtractor ::= Code(Any) returns Any;
type Comparator ::= Code(Any, Any) returns Int;
type Criterion::= KeyExtractor
| Comparator
| Pair(KeyExtractor, Comparator)
;
snip
If a key-extractor block returns number, then C = is used to
compare
those keys. Otherwise Ccmp is used. In either case, the keys extracted
by
the block are cached within the call to Csort, to optimize subsequent
comparisons against the same element. That is, a key-extractor block is
only
ever called once for each element being sorted.
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', 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. Will the sort
end up being numerical or alphabetic?
Joe Gottman
Re: The Sort Problem: a definitive ruling
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 expression
Indeed.
DC sub fuzzy_cmp($x, $y) returns Int;
DC @sorted = sort fuzzy_cmp, @unsorted;
ok, so that is recognizes as a compare sub due to the 2 arg sig. so does
the sub must be defined/declared before the sort code is compiled?
Yes. And, yes, declaration is sufficient.
DC @sorted = sort {+ $^elem} @unsorted;
DC @sorted = sort {+ $_} @unsorted;
is $^elem special? or just a regular place holder?
Regular.
just getting my p6 chops back. .name is really $_.name so that makes
sense. and $^elem is just a named placeholder for $_ as before?
Yes and yes.
DC @sorted = sort get_key, @unsorted;
and that is parsed as an extracter code call due to the single arg
sig.
Yes.
again, it appears that it has to be seen before the sort code for
that to work.
Correct.
DC or with a single extractor/comparator pair (to sort according to the
DC extracted key, using the specified comparator):
DC # Modtimewise stringifically descending...
DC @sorted = sort {-M}={$^b cmp $^a} @unsorted;
so that is a single pair of extractor/comparator. but there is no comma
before @unsorted.
Typo. I'm pretty sure it would actually need a comma there.
DC @sorted = sort {.name}=fuzzy_cmp @unsorted;
Comma required there too. :-(
DC ],
but what about that comma?
It's required.
no other example seems to have one before the @unsorted stuff.
The comma exception only applies to simple blocks. I messed up those two
examples. :-(
where does the int optimizer come in?
When the key extractor is known to return an Int. Which would occur either
when it's explicitly declared to do that, or when the compiler can intuit a
block's return type from the type of value returned by the block (i.e. if the
block always returns the result of a call to Cint).
just as you had it before in the
extractor code?
Yup.
so are those traits are only allowed/meaningful on comparison blocks?
or will an extraction block take them
Both. That's why I wrote:
The Cis descending and Cis insensitive traits
on a key extractor or a comparator...
^
you have examples which show the
traits on either the extractor or comparator code blocks. that implies
that the guts can get those flags from either and use them as needed.
Yep. Inside the body of Csort you'd access them as:
$by.trait{descending}
$by.trait{insensitive}
(unless Larry's changed the trait accessor syntax since last I looked).
Damian
Re: The Sort Problem: a definitive ruling
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 sort? amazing how you and luke both came up with the exact same answer. p6 syntax like that is killing me slowly! uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: The Sort Problem: a definitive ruling
JG == Joe Gottman [EMAIL PROTECTED] writes:
JGHow 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 the result of the following code?
JG sort {$_.key} (1= 'a', 10 = 'b', 2 ='c');
JGThere is nothing in the signature of the key-extractor to suggest that
JG all the keys are numbers, but as it turns out they all are. Will the sort
JG end up being numerical or alphabetic?
my take is that either = or cmp (my pref) would be the default
comparator. if you want to force one, you need to use prefix ~ or + or
int.
oh, another reason to make cmp the default is BACKWARDS COMPATIBILITY!
we have support now for the old simple @sorted = sort @unsorted syntax
so the cmp should still be the default.
hey, i am remembering p6 syntax now! but give me a week and i will
forget it again :)
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: The Sort Problem: a definitive ruling
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 syntax like that is killing me slowly! No, it's gradually making your *stronger*. ;-) Damian
Re: The Sort Problem: a definitive ruling
On Fri, Feb 20, 2004 at 02:47:55PM +1100, Damian Conway wrote:
: Yep. Inside the body of Csort 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 properties, and properties
are just mixed-in roles (usually enums), then it's more likely that
something like:
$by.Direction == descending
$by.Case == insensitive
would be the incantation. Or maybe if enums auto-booleanize, then
you could say
$by.Direction::descending
$by.Case::insensitive
And then
$by.descending
$by.insensitive
might be allowed as abbreviations when unambiguous. Or maybe we
require matching:
$by ~~ descending
$by ~~ insensitive
But there is no such thing as a true property or false property.
There's a Boolean role that can have the value true or false. Traits
are mixed in to declared objects at compile time, and can do weird
things to such objects at mixin time.
Likewise there's no such thing as a descending property. There's
a Direction property which defaults to ascending. And a Case property
that defaults to sensitive.
To do otherwise is to set ourselves up for objects that can be both
true and false simultaneously. Only junctions should be allowed
to do that...
Larry
Re: The Sort Problem: a definitive ruling
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. so how is that allowed there without a block? is it because it is the name is in a style of a sub? that makes sense to me but i want to make sure i get it. and now back to my advil addiction. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
