Darren Duncan wrote:
So "filter" is now my preference for a new name, and if
"grep" is kept, then that can be an alias for it;
We've also had a policy of removing synonyms (e.g. "for"/"foreach"),
so I think we should have only one name for any one function.
Damian
On 9/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Have there been any significant changes since the 2nd. edition of "Perl 6
and Parrot Essentials"?
If so, where should I look for a summary?
Yes, there have. That book is completely out of date. Please check out
http://perlcabal.org/syn
At 6:26 AM +0200 9/19/06, Damian Conway wrote:
The standard--and self-explanatory--CS term for this operation has
always been "filter", which is also currently used by Python, Scheme,
Haskell, and numerous other languages, so *if* we're going to change
it from "grep", we ought to change it to "fi
We have gone to a great deal of trouble to remove homonyms (such as
"eval"/"eval","select"/"select","do"/"do"/"do") from Perl 6, so I
would be very unhappy to see us create a new one by re-using "where"
to mean two different things.
I don't object in principle to renaming "grep" to something more
Author: larry
Date: Mon Sep 18 20:33:07 2006
New Revision: 12185
Modified:
doc/trunk/design/syn/S02.pod
Log:
Some handwaving about type equivalence.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/
Darren Duncan wrote:
> Putting aside legacy issues for the moment,
>
> I suggest that it might be appropriate to rename the .grep list operator
> to .where, so we can say, for example:
>
> @filtered = @originals.where:{ .foo eq $bar };
>
> We already have a "where" keyword in the language, whi
Aankhen wrote:
>
> The major feeling was that there should be no CGI.pm (if someone was
> hellbent on using it, they could use the Perl 5 module).
In theory, "use perl5:CGI" could be a fine solution. In practice, it
hasn't worked out well for me. Even something that seems simple like
passing a h
On Mon, Sep 18, 2006 at 09:00:42PM -0400, Bob Rogers wrote:
:It is probably true that Perl 6 error handling as currently defined
: could be implemented either way.
Nope, S04 specifically sez:
A C block sees the lexical scope in which it was defined, but
its caller is the dynamic locat
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Mon, 18 Sep 2006 11:53:36 +0200
Am Montag, 18. September 2006 03:56 schrieb Bob Rogers:
>The attached patch consolidates most of the existing stack-unwinding
> code into Continuation:invoke; previously, RetContinuation:invoke and
> Randal L. Schwartz wrote:
>
>> The thing that CGI.pm does is put in one place everything you need for
>> a simple web form. And there's an amazing number of applications for
>> this... putting a "contact us" page on an otherwise static site comes
>> to mind immediately.
>>
>> Sure, if you're bu
Trey Harris schrieb:
> > @filtered = @originals.where:{ .foo eq $bar };
>
> Note that this can be written:
>
>@filtered = any(@originals) ~~ { .foo eq $bar};
I generally like "words" more than sequences of non-word characters as
you can quickly remember/guess the meaning, what's not always the
At 3:36 PM -0700 9/18/06, Trey Harris wrote:
In a message dated Mon, 18 Sep 2006, Darren Duncan writes:
I suggest that it might be appropriate to rename the .grep list
operator to .where, so we can say, for example:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be writte
In a message dated Mon, 18 Sep 2006, Darren Duncan writes:
Putting aside legacy issues for the moment,
I suggest that it might be appropriate to rename the .grep list operator to
.where, so we can say, for example:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be writt
Putting aside legacy issues for the moment,
I suggest that it might be appropriate to rename the .grep list
operator to .where, so we can say, for example:
@filtered = @originals.where:{ .foo eq $bar };
We already have a "where" keyword in the language, which is used for
very similar thing
Randal L. Schwartz wrote:
The thing that CGI.pm does is put in one place everything you need for a
simple web form. And there's an amazing number of applications for
this... putting a "contact us" page on an otherwise static site comes to mind
immediately.
Sure, if you're building a complex sh
Have there been any significant changes since the 2nd. edition of "Perl 6
and Parrot Essentials"?
If so, where should I look for a summary?
---
Get a free email address at http://www.ippimail.com and
support your favori
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40349]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40349 >
Hi,
This is a patch to (attempt to) close the Cage Cleaner's RT ticket
#40278. The
* Richard Hainsworth <[EMAIL PROTECTED]> [2006-09-18 15:20]:
> I copied your neat program into a file, called it gtk2test.p6
> and got
> pugs gtk2_test.p6
> ***
>unexpected ":"
>expecting term postfix, operator, ";" or end of input
>at gtk2_test.p6 line 2, column 56
Note my translation
Richard Hainsworth skribis 2006-09-18 17:18 (+0400):
> However, I am using pugs from the debian package and not directly from
> the repository. So perhaps, the problem is I am not using the latest
> version of pugs.
That version is rather old in our universe :)
--
korajn salutojn,
juerd waal
I copied your neat program into a file, called it gtk2test.p6 and got
pugs gtk2_test.p6
***
unexpected ":"
expecting term postfix, operator, ";" or end of input
at gtk2_test.p6 line 2, column 56
However, I am using pugs from the debian package and not directly from
the repository. So pe
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Sep 18 13:15:03 2006 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with m
Quoth [EMAIL PROTECTED] (Larry Wall):
> Okay, combining all these approaches minimalistically but without
> golfing we get something like:
>
> my @numbers = sort { rand }, constant @goal = 1..9;
> my $steps = 0;
>
> until @numbers ~~ @goal {
>say [EMAIL PROTECTED];
>@
Am Montag, 18. September 2006 03:56 schrieb Bob Rogers:
>The attached patch consolidates most of the existing stack-unwinding
> code into Continuation:invoke; previously, RetContinuation:invoke and
> find_exception_handler also did stack-unwinding, and none of the three
> did it quite the same
23 matches
Mail list logo
