Hi,
I was reading the RFC list, and I noticed this one. I haven't
seen any discussion about it, so I wanted to say:
1. I fully agree that it is needed -- signed/unsigned integer
support is sadly lacking in Perl5
2. When an implementation method is chosen, we should ensure that
is extensib
> > perl -le '$n=1; print "$n \t",((1 + (1/$n))** $n) while $n*=1.001'
> > [...]
> > When to throw away
> > a result as meaningless is certainly an important piece of wisdom,
> > I do not know any programming languages that do it for you
> > -- issue a warning when you've overloaded your accura
> 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
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> I'm hoping to have this stage of optimization in perl. Off by
> default with
> a normal parse-and-go run (though certainly enableable if you
> want), on by
> default with the bytecode compiler.
Don't forget about run-time information: You coul
> One-liners run on a Perl 6 binary should just be Perl 6 code. Do we
> really have to worry about backwards compatibility with one liners?
>
> Hmm... programs that have perl one-liners inside them might be
> troublesome.
Why not:
perl -e 'perl 5 one-liner'
perl --cmd 'perl 6 one-liner'
i.e
James Mastros wrote:
> > print $::OUT http://www.wall.org/~larry/index.html;
> Please, no! A URL isn't a /new/ type of literal, really.
> Either it's a > wierd form of a literal list, or it's a
> wierd type of file name, so you should open() it. Or it's
> a self-quoting literal, like Package
John Porter wrote:
> > $mySite = http://www.foo.bar/text.html;
> Vs.
> $mySite = new URL 'http://www.foo.bar/text.html';
>
> I am far from convinced.
Simon Coxens wrote
> A language that doesn't have everything is actually easier to program
> in than some that do.
> -- Dennis M. R
John Porter wrote
> > I'm sure you don't want to write "$a = new Integer '32'".
>
> Of course. That would be unbearably absurd.
> But how often do you have to write expressions that
> operate on three or more URLs? Or even two?
> How many perl instrinsics return URLs? How many
> perl intrinsics
Dan Sugalski wrote
> At 12:19 PM 4/16/2001 -0700, Peter Scott wrote:
> > Or were you espousing the notion that perl 6 programs should
> > be able to contain sections of perl 5 code? That gives me
> > strange palpitations.
>
> This is what I've been arguing against. Unless I misunderstand
> (and
> >is => typing, inheritance, etc.
> >has => composition, aggregation, etc.
>
> True, but those are basic OO concepts, which don't neatly apply to
> property-lists (a very old Lisp concept that Perl6 is adopting).
"is" does seem to imply an OO is-a relationship. So lets run
with it!
If $foo i
John Porter wrote:
> Larry Wall wrote:
> > We do have to worry about the C loop control function though.
> > It's possible that in
> >
> > FOO: while (1) {
> > next FOO if /foo/;
> > ...
> > }
> >
> > the C label is actually being recognized as a pseudo-package
> > name! The loop
Edward Peschko wrote:
> > As to what the combined
> >
> > $bar[$foo]
> >
> > would mean: that depends on what $bar contains.
> >
> I like visual clues to tell me
> what type of variable
> something is. And I disagree strongly with trying to
> steamroller the language's
> design paper-flat as
Uri Guttman wrote:
> so we have to get some way to denote a list of indices as a slice and
> also support some range operation as a possible component of that list
> with the knowledge that the range arguments are also indices and not
> just integers.
>
> i don't have any syntax ideas for this at
Michael G Schwern [mailto:[EMAIL PROTECTED]] wrote:
> Of course, there's problems of order of definition. What happens if
> Bar.pm is loaded before Foo? Dunno.
simple sematics can be defined. If we see a declaration:
package Foo is encapulated;
then we throw an error if the namespace, Foo,
> From: Damian Conway [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 11, 2001 4:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: suggested properties of operator results
> I think we will see n-ary comparisons allowed in Perl 6:
>
> if ($x < $y <$z < $foo) {...
>
> but as special case syntact
When you blass an object in Perl, you give it exactly
one type. The @ISA variable allows that type to refer
to many other classes as the inheritance tree. @ISA
is a list, but ref($obj) isn't. This means that you
sometimes have to create a lot of useless classes to
work around this limitation.
A s
Peter Scott wrote:
> What's wrong with multiple inheritance?
You have to create a whole load of extra classes whose only
purpose is to define a list of superclasses. Compare:
bless $self, qw(Employed Male);
with
package Employed_Male;
@ISA=qw(Employed Male); # multiple inheritance
...
David L. Nicol wrote:
>
> > The other standard solution is to
> > add a "Person has-a Employment_Status" relationship,
> > but that doesn't feel much better.
>
> It feels fine to me. Person has-a gender, person has-a job,
> it's more politically correct, even, than pigeonholing. You
> can even
Mark J. Reed wrote:
> Okay, but now we're getting into the fundamental O-O model for
> Perl. I guess that's fair game? You can certainly make the case
> that prototype-based inheritance makes at least as much sense
> as class-based inheritance for a dynamic language like Perl.
> But that's a maj
Michael G Schwern wrote:
> Rather than stumbling around in the dark here, is anyone actually
> experienced with object inheritance? Any Self programmers out there?
> Someone that's actually used this technique often and understands what
> works and what does? Any books/articles to recommend?
I
> I think they're supposed to be both by perl thingie and by value. So:
>
>my $foo is const = 0 is true;
>
> $foo has the property const, while the value 0 in $foo has
> the property true.
So, if I do
my $foo is constant = new Counter(0);
$foo->increment # OK
my $bar = new Counter(0) is
> They list two reasons to make your class final. One is security
> (which might actually be valid, but I doubt it will hold up to
> determined attack), the other though...
>
> You may also wish to declare a class as final for object-oriented
> design reasons. You may think that your cla
David L. Nicol wrote:
> How about some nice introductory links for MOP theory? The
> above-linked post is also the only time I recall seeing aspect
> theory mentioned in here either. Someone explained aspectJ to
> me at a PM meeting and it sounded like a sure recipe for
> completely impossible A
Uri Guttman
> we are planning automatic over/underflow to bigfloat. so there is no
> need for traps. they could be provided at the time of the
> conversion to big*.
OK. But will Perl support signaling and non-signaling NANs?
Dan Sugalski wrote:
> Okay, I'm whipping together the "fancy math" section of the
> interpreter assembly language. I've got:
[...]
> Can anyone think of things I've forgotten? It's been a while
> since I've done numeric work.
I'm not sure where this belongs, but I'd really like to have
a usage
Brent Dax wrote:
> And I didn't see anything about you being able to hyper =,
> so ^= ought to be alright too.
I would expect
@a ^= 1; # sets default value for (all elems of) @a
@a ^+= 1; # increments each element of @a
etc.
Dave.
--
Dave Whipp, Senior Verification Engineer,
> > More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST
> > continue to work.
>
> What is void plus one?
Can't we utilize the lazy arrays stuff to make all this work.
Out of the box, all entries could default to NaN. But its easy
to write
@a ^= 0;
to change this default.
Aaron Sherman wrote
> On Mon, Oct 22, 2001 at 11:30:01AM -0700, David Whipp wrote:
> > > > More, someone has mentioned the %x{$_}++ feature, which
> IMHO, MUST
> > > > continue to work.
> > >
> > > What is void plus one?
> >
> >
> > Aaron Sherman wrote
> Larry's hubris notwithstanding, I'd like to suggest that
> "more", in this
> case means "no, it prints nothing".
>
> This *must* be true, as you don't want:
>
> @a ^+ @b
>
> to always return an infinite list. You want it to produce a list with
> (as a3 suggested
Aaron Sherman wrote:
> Someone's missing something, and I sure hope it's not me. Let me write
> a code sample here:
>
> sub incrind (@ary, $ind) {
> @ary[$ind]++
> }
>
> Are you suggesting that by adding in "@ary ^= 0", like so:
>
> sub incrind (@ary, $ind) {
>
Aaron Sherman wrote:
> All of this is still coming into focus for me, and I want to spend
> more time reading the articles later, but for now I just wanted
> to see if anyone else has been thinking these thoughts
I do like the idea of AOP; but I think the mechanism you suggest
are too clumsy.
> If Perl is going to have data hiding (I think I read that this was a
> goal), then you cannot declare these relationships outside of the
> class that defines the method. That would be like putting a "friend"
> delcaration only on the foriegn class in C++. It simply should not
> work that way.
I
Damian Conway wrote:
> but I still have immense difficulty with the notion that:
>
> $x == NaN
>
> doesn't return true if $x contains NaN.
Anyone with a hardware background should have no difficulty with
this concept. All common HDLs have multi-valued logic systems,
including values li
> So the imaginary numbers would be standard literals? Like
>
> $x=2+10i;
>
> Great idea, as well as sqrt(-1) returning 1i istead of raising the
> exception. BTW, I was thinking once that numeral literals
> like 4k or 10G
> (meaning 4*2**10, 10*2**30) would be very nice. What do you think?
> > > First this thread tells me that "123foo" will be 123 in numeric
> > > context. Now I find myself wondering what "123indigo" evaluates
> > > to!
> >
> > It would evaluate to 123. If "use complex" is in effect, it would
> > evaluate to 123i. At least that's the position I'm taking at the
> >
> Well, as discussed briefly in an earlier thread,
> http:[EMAIL PROTECTED]/msg08514.html
> if we allow ! in function names, we can distinguish between the normal
> and in-place versions of functions without proliferating the number of
> keywords.
>
> chomp! $string;
> my $chomped_string
> Is chomp? just a bad example, or is there some utility in asking if a
> string has already been chomped?
The query is asking what the string would look like, if it were chomped.
Dave.
Perl6 is going to introduce a non-resumable throw/catch mechanism to replace
die/$@. (I assume that die will be synonymous with throw, for
compatibility.)
But what about warnings? I frequently find myself wanting to "catch"
warnings (e.g. to add extra context around a library's "use of undefined
Michael G Schwern wrote:
> Reading this in Apoc 4 ...
I looked on http://dev.perl.org/perl6/apocalypse/: no sign of Apoc4. Where
do I find this latest installment?
Dave.
Apo4, when introducing POST, mentions that there is a
corresponding "PRE" block "for design-by-contract
programmers".
However, I see the POST block being used as a finalize;
and thus allowing (encouraging?) it to have side effects.
I can't help feeling that contract/assertion checking
should not
In light of Apo4, I thought I'd re-ask this question. Is the following still
the approved idiom, or will we have a nice little /[A-Z]+/ thingie:
sub foo
{
temp $SIG{__WARN__} = sub {
warn "$(timestamp) $@\n"
}
warn "hello"
}
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip
Casey West wrote:
> So you're suggesting that we fake lexical scoping? That sounds more
> icky than sticking to true lexical scoping. A block dictates scope,
> not before and not after. I don't see ickyness about making that so.
Perl is well known for its non-orthogonality. To say that "A bloc
Graham Barr wrote:
> But I have lost count of the number
> of times I have wanted to do
>
> if ((my $foo = bar()) eq 'foo') {
> ...
> }
>
> if ($foo eq 'bar') {
> ...
> }
>
To be contrasted with:
while (my($k, $v) = each %h1)
{
...
}
while (my($k, $v) = each %h2) # error?
{
Piers Cawley [mailto:[EMAIL PROTECTED]] wrote:
> Damian Conway <[EMAIL PROTECTED]> writes:
> > I suppose this discussion also raises the vexed question
> whether ??:: can also be put out to pasture in favour of:
> >
> > $val = if $x { 1 } else { 2 };
I like that idea.
> Only if you can also
Peter Haworth [mailto:[EMAIL PROTECTED]] wrote:
> This is all very sensible, and I completely agree with it.
> However, don't we
> need some restrictions on what can go in PRE and POST blocks
> to ensure that they are still valid in inherited methods?
There's another issue: sometimes we don't
> > switch(...) {
> >case 1: ...;
> >nobreak; /* intentional fall-through */
> >case 2: ...;
> >break;
> >case 3: ...;
> > }
> >
> > Does anyone agree that `nobreak' reads much better than `skip'?
>
> "skip" was uncomforta
> In a related matter, computer languages with Symbolic Mathematics
> capabilities, like Mapple, let you explicitly demand where do
> you want the operation to take place.
>
> This could be done naturally in perl6 using the colon meta-operator:
>
> my $plain = $c - $d : Math::Complex # 3.0 + 0
> printf "%d hash is $(%foo.string)", $bar ;
> no ambiguity and no confusion.
This would be nice, if scalar things use '$'. But:
perl5: printf "%d is $foo{bar}", $baz;
perl6: printf "%d is $(%foo{bar})", $baz;
Not so nice.
Dave.
Luke Palmer [mailto:[EMAIL PROTECTED]] wrote:
> Then the macro would not recieve 4 as the second argument,
> rather 2*6/3 in syntax tree form. Would the macro have to
> do its own constant folding? I hope not. So how could it
> check whether this thing was an integer? How could it
> differentiate
Mark J. Reed wrote:
> On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> > method m1
> > {
> >m2; # calls method m2 in the same class
> Yes, but does it call it as an instance method on the current invocant
> or as a class method with no invocant? If the former, how would you
Mark J. Reed wrote
> On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote:
> > ..class.m2: # call static m2 within m1's class, regardless
> of how m1 was called
> Typo. That should be just .class.m2, only one leading '.'.
Wouldn't that be the current topic's class?
Dave.
Piers Cawley
> > This may be a case of keep up at the back, but if that is a
> method call,
> > how do I call a subroutine from within a method ?
>
> [...]
>
> Yes, I know there's several different ways I could do it, but this
> approach feels right.
I think this comes does to huffmann encodi
Melvin Smith wrote
> I think that would be just plain bad design, but I'd be happy
> if someone showed me a use for it. :)
well, I've been known to do
sub UNIVERSAL::debug
{
my $self = shift;
my $msg = "@_";
eval {$self=$self->name} if ref($self);
my $timestamp = ...;
my
Melvin Smith wrote:
> So we have undef and reallyundef? :)
Seems reasonable, given that we have c and c.
How about:
sub foo ( $a is optional )
{
if exists($a) { ... }
elsif defined($a) { ... }
else { ... }
}
Dave.
Damian Conway wrote:
> BUGS
> Unlikely, since it doesn't actually do anything. However,
> bug reports and other feedback are most welcome.
Bug:
don't { die } unless .error;
doesn't DWIM (though the current behavour, "do nothing", is
logically correct).
Dave.
Miko O'Sullivan [mailto:[EMAIL PROTECTED]] wrote:
> Sorry, I thought I'd expressed agreement at some point. I like the
> "else\s+(if|while|for|loop)" construct very much, and I think the
> programmers of the world would like it too. I know a some people have
> issues with "where's the if" but it
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
> what about
> >
> > while (do_something_with_side_effects_and_check_still_ok()) {
> >
> > I presume we don't want to do look-ahead here.
>
> Yes, I think he was saying exactly that we will do look-ahead
> here. "we don't guarantee order of
Miko O'Sullivan wrote:
> Just checking here: is PRE_LAST a separate and non-mutually exclusive
> concept from LAST? I.e., would this make sense:
>
>foreach @arr -> $i {
> PRE_LAST {print "before last loop\n"}
> LAST {print "after last loop\n"}
> print "$i\n";
>}
>
> If
Damian Conway [mailto:[EMAIL PROTECTED]] wrote:
> > ".bar" is the auto-created accessor for
> > "$.bar", so they should do the same thing, no?
>
> Presumably, but perhaps not quite as fast.
Assuming some subclass has not overridden .bar()
Dave.
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
> You might not be able to REASONABLY get a length, so you return
> undef. In your documentation, you advise users not to take the length,
> but just dive right in and fetch the element you want, e.g.:
>
> my $pi2k = @pi_digits[2000];
In this ca
As always, most of it is great. so only the niggles get discussed.
On page 7, the following example is given:
$oldpos = pos $string;
$string =~ m/... <( .pos == $oldpos )> .../;
This implies that match position is associated with the string. This worries
me. If 2 threads are matching on
Page 13 tells use about C decls. But it also says that the topic must
be a regex. Whilst it explains that this isn't really a problem, I'm not
sure that it justifies it. So perhaps someone can clarify why this
(hypothetical) code in not a reasonable generalization:
our $foo = 0;
sub do_somethin
First, a slight clarification: if I say:
m:w/ %foo := [ (\w+) = (\w+) [ , (\w+) ]* ] /
does this give me a hash of arrays? (i.e. is the rhs of a hash processed as
a scalar context)
When I look at this, I see a common pattern: the join/split concept. It
feels like there should be a standard a
Luke Palmer wrote:
> So there's no elegant way the new regexes support it?
> That's a shame.
seems fairly elegant to me, with 2 caveats:
First, we need assertions as part of the default library. I.e. we shouldn't
need a C for things like min and max.
Second, we should eliminate as much of
Brent Dax wrote:
> $href = hash { %hash }; #B
Why the curlies? if C is a function (ctor), then surely these should
be parentheses. In this context, parentheses are optional, so this could be
written
$href = hash %hash;
Dave.
I'm wondering if Perl6's new regex can be applied to non-string things. I
seem to recall A5 mentioning something about strings tied to array
implementations; but I'm wanting something a little more powerful.
A bit of context: I use Perl for verification of big complex ASICs. We run a
simulation a
Luke Palmer wrote:
> Since variables are copy-on-write, you get the speed of
> pass-by-reference with the mutability of pass-by-value,
> which is what everyone wants. If you have this, why would
> you want to do enforced const reference? That's not
> rhetorical; I'm actually curious.
One reas
Thom Boyer [mailto:[EMAIL PROTECTED]] wrote:
> sub while (bool $test, &body);
> sub while (&test, &body);
>
> But neither of these really works.
>
> The first would imply that the test is evaluated only once
> (and that once is
> before 'sub while' is even called). That'd be useles
Steffen Mueller
> > %hash4 = ("Something", "mixing", pairs => and, "scalars");
>1 23 4 5
> Perl5 says "Odd number of elements in hash assignment at -e line 1."
> And Perl6 should, too.
Hmm, I rather like the idea of thinking of a %foo variable as
Piers Cawley wrote:
> Maybe we should just say 'sod it' and implement the entire Smalltalk
> Collection hierarchy and have done with it? Sets, bags, hashes
> (dictionaries for the Smalltalker), whatever, all have their uses...
I'm not sure if you were being facetious, but I do think all the
funct
> my Date $date .= new('June 25, 2002');
If we're assuming that C creates an C
object, then that object should be able to overload its assignment operator.
I don't know what the perl6 syntax will be, but something along the lines of
class Date
{
method operator= ($value is rx//)
{
In Perl5, I might write:
sub set_date {
my ($self, $date) = @_;
$date =~ /(\d{4})-(\d{2})-(\d{2})/ or croak "bad date format";
@$self{qw/year month day/} = ($1,$2,$3);
}
I could then call:
$foo->set_date('2002-09-04')
In Perl6 I can write:
sub set_date ( $date is rx/
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
> I'm thinking XS thoughts because we're going to need a few external
> things at SOME point It would be so nice if Perl 6's XS
> was part of the language, rather than an external pre-processor.
> [ some interesting stuff]
> Thoughts?
Its good
Larry wrote:
> : $shouldbe3 = (1,2,3) + 0;
>
> It's 3, though not for the reason a Perl 5 programmer would think.
> (In Perl 6 it's the length of the anonymous array, not the
> last value.)
This kind of clever magic always makes me nervous:
it introduces subtle bug potentials.
(7,8,9) ==
It seems that the fundamental problem is the dichotomy between
a scalar, and a list of 1 elem. Thus, we want
$a = 7
to DWIM, whether I mean a list, or a scalar. Seems to me that
the best way to solve a dichotomy is to declare it to not to
be one: a scalar *IS* a list of one element. The only t
> From: Jonathan Scott Duff
> > $b = 7, 6, 5
> > @b = 7, 6, 5
> >
> > Again, both create identical objects, under different
> > interfaces. But now we have a problem with +$b: what should
> > this mean? To be consistant with +$a (above), I would
> > suggest that it simply returns the sum of
Kv Org [mailto:[EMAIL PROTECTED]] wrote
> I believe Perl6 needs a facility to run
> "compartmented" code (object-oriented and
> module-loading) that is tagged as to its permissions
> and "owner" ID. The goal would be to let such code use
> harmful actions only by calling permitteed outside
> funct
Michael Lazzaro wrote:
> > What if a subclass adds extra, optional arguments to a
> > method, is that ok?
>
> This is the scariest question, I think... In theory, yes, there are
> lots of potential interfaces that would benefit from optional
> extensions, & I've made a few. In strict terms,
Michael G Schwern <[EMAIL PROTECTED]> wrote:
> I can see too many problems with that technique, I think one was
> already mentioned where subclasses can unintentionally weaken
> preconditions to the point of eliminating them.
Which is, of course, why we OR them, yet AND the postconditions
It
Mark J. Reed wrote:
> I realize the above is mathematically simplistic. The
> real reason y = x/0 returns an error is because no matter what
> value you assign to y, you aren't going to get x back via multiplying
> y by 0.
Well, that may be true in math; but there's no reason why it has to be
tr
> it looks like "Lukasiewiczian NULL" is just the nifty NULL
> that SQL has, and the nifty ways that it affects logical
> and aggregate operations. Actually, something I wouldn't mind
> seeing in other languages -- I can't say if perl is one of those,
> but if it can be provided by expansion, that
Jonathan Scott Duff wrote:
> > Ok, how about this: Is there a reason I to? Or
> > should I not go there?
>
> Off hand, it sounds expensive. I don't see a way to only let
> the people who use it incur the penalty, but my vision isn't
> the best in the world.
It should be possible to define the
Larry Wall [mailto:larry@;wall.org] wrote:
> : unary (postfix) operators:
> :... - [maybe] same as ..Inf [Damian votes Yes]
>
> I wonder if we can possibly get the Rubyesque leaving out of
> endpoints by saying something like 1..!10.
Perhaps we could use the less-than symbol: 1 ..< 10
Luke Palmer [mailto:fibonaci@;babylonia.flatirons.org] wrote:
> for @x | @y -> $x is rw | $y {
> $x += $y
> }
This superposition stuff is getting to me: I had a double-take,
wondering why we were iterating with superpositions (Bitops
never entered my mind). Did the C<;> ever o
David Wheeler [mailto:david@;wheeler.net] wrote:
> The problem with this is that you have explicitly introduced true and
> false into the language, and have therefore destroyed the utility of
> context:
>
>my boolean $bool = 0; # False.
>my $foo = ''; # False context.
>if ($
Michael Lazzaro [mailto:mlazzaro@;cognitivity.com] wrote
> On Friday, November 1, 2002, at 01:38 PM, David Whipp wrote:
> > Presumably, there exist rules for implicit casting when
> > comparing objects of different types. If we have a rule
>
> My initial assumption is that
Every primitive type has an associated object type, whose name differs only
by capitalized first letter. A few posts back, Larry mentioned that perhaps
similar things should look different: this may be a good case to apply this
principle.
Whenever a value passes through a primitive type, it loses
Dan Sugalski [mailto:dan@;sidhe.org] wrote:
> At 6:50 PM -0800 11/6/02, David Whipp wrote:
> > Whenever a value passes through a primitive type, it
> > loses all its run-time properties; and superpositions
> > will collapse.
>
> What makes you think so, and are you
Dan Sugalski [mailto:dan@;sidhe.org] wrote:
> At 8:24 PM -0800 11/6/02, David Whipp wrote:
> >If I am wrong, then I am in need of enlightenment. What
> >is the difference between the primitive types and their
> >heavyweight partners? And which should I use in a typical
&g
> I think that solves all the problems we're having. We change \c to
> have more flexible meanings, with \0o, \0x, \0d, \0b, \o, \x as
> shortcuts. Boom, we're done. Thanks!
How far can we go with this \c thing? How about:
print "\c[72, 101, 108, 108, 111]";
will that print "Hello"?
Miko O'Sullivan [mailto:[EMAIL PROTECTED]] wrote:
> SUMMARY
>
> Proposal for the "purge" command as the opposite of "grep" in
> the same way that "unless" is the opposite of "if".
I like it.
But reading it reminded me of another common thing I do
with grep: partitioning a list into equivalence
Luke Palmer [mailto:[EMAIL PROTECTED]] wrote:
> By default they're keyed by strings. You can smack a property on them
> to key them by something else, though:
>
> my %sparse is keyed(Int);
> my %anything is keyed(Object); # or UNIVERSAL
Should that be a property of the hash-object, not
I was reading the "Partially Memorized Functions" thread, and the thought
came to mind that what we really need, is to define a different
implementation of the method for a specific value of the arg. Something
like:
sub days_in_month( Str $month, Int $year )
{
...
}
sub days_in_month( Str $mont
93 matches
Mail list logo
