Author: larry
Date: Wed Sep 20 22:07:47 2006
New Revision: 12284
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S12.pod
Log:
The | sigil and operator.
Modified: doc/trunk/design/syn/S02.pod
==
Larry Wall wrote:
Okay, I think this is worth bringing up to the top level.
Fact: Captures seem to be turning into a first-class data structure
that can represent:
argument lists
match results
XML nodes
anything that requires all of $, @, and % bits.
Fact: We're currently going
Larry Wall wrote:
On Wed, Sep 20, 2006 at 05:18:12PM -0400, Aaron Sherman wrote:
: For this reason, I'd suggest putting away the Latin-1 glyphset and
: instead focusing on developing operators to act on containers with
: multiple access methods and their expanded forms.
There's already goi
On Wed, Sep 20, 2006 at 11:44:49PM -0400, John Macdonald wrote:
: On Wed, Sep 20, 2006 at 07:11:42PM +0100, Andy Armstrong wrote:
: > On 20 Sep 2006, at 19:05, Larry Wall wrote:
: > >Let it be. :)
: >
: > I could just as easily have called for a revolution :)
:
: No, you should have quoted diffe
On Wed, Sep 20, 2006 at 07:11:42PM +0100, Andy Armstrong wrote:
> On 20 Sep 2006, at 19:05, Larry Wall wrote:
> >Let it be. :)
>
> I could just as easily have called for a revolution :)
No, you should have quoted differently:
> On 20 Sep 2006, at 19:05, Larry Wall whispered words of wisdom:
> >
On Thu, Sep 21, 2006 at 12:45:46AM +0100, Smylers wrote:
: Larry Wall writes:
:
: > Conjecture: We need a corresponding sigil to request captureness. As
: > Bikeshed: What should that sigil be?
:
: What's * doing these days?
Thought a lot about that one, but I think it's more useful in 0..*
and
Larry Wall writes:
> Conjecture: We need a corresponding sigil to request captureness. As
> Bikeshed: What should that sigil be?
What's * doing these days?
Smylers
On Wed, Sep 20, 2006 at 05:18:12PM -0400, Aaron Sherman wrote:
: Consider this the first test of the first-classness of objects in Perl
: 6. You have an object that's something not entirely unlike:
:
: class Capture { has $.scalar; has @.array; hash %.hash }
:
: I think the addition of a sigi
On Wed, Sep 20, 2006 at 12:28:10PM -0700, Larry Wall wrote:
> Bikeshed: What should that sigil be? And if it's in Latin-1, what's the
> ASCII workaround?
The one that springs out to me is:
> ¤ 00A4CURRENCY SIGN
Probably because it looks like a container with something cap
On 9/20/06, Larry Wall <[EMAIL PROTECTED]> wrote:
Conjecture: We need a corresponding sigil to request captureness.
As with @ and %, you can store a capture in a $ to hide it, but we
don't have the ability to have capture variables that know how to
behave like captures without fakey syntactic hel
Larry Wall wrote:
Okay, I think this is worth bringing up to the top level.
Fact: Captures seem to be turning into a first-class data structure
that can represent:
argument lists
match results
XML nodes
anything that requires all of $, @, and % bits.
This is quite true, and wo
Oops, I hate typos that result in my writing exactly the opposite of what
I meant:
In a message dated Wed, 20 Sep 2006, Trey Harris writes:
In a message dated Wed, 20 Sep 2006, Larry Wall writes:
The obvious ASCII for ¢ would be c/ or C/ or c| or c| or maybe just |.
I like ¢,but:
c/$foo
In a message dated Wed, 20 Sep 2006, Larry Wall writes:
The obvious ASCII for ¢ would be c/ or C/ or c| or c| or maybe just |.
I like ¢,but:
c/$foo # ASCII of ¢$foo
d/$foo # d() divided by $foo
is rather confusing. (Same goes for |).
So the Term Term exclusion makes me rather lean tow
Okay, I think this is worth bringing up to the top level.
Fact: Captures seem to be turning into a first-class data structure
that can represent:
argument lists
match results
XML nodes
anything that requires all of $, @, and % bits.
Fact: We're currently going through contortions
> names they're given. "The Beatles" probably sounded like a really
> dumb name for a band once.
But maybe less dumb than 'The Quarrymen', which was the original name of
the band. (They all went to Quarry Bank school, now Calderstones.)
Perhaps the renaming, unfettered by their history or by a
Larry Wall wrote:
On Wed, Sep 20, 2006 at 11:18:09AM -0400, Aaron Sherman wrote:
: Trey Harris wrote:
: >Might I propose the following normalization:
: >
: >1. .call, method definition call(), and .wrap call all take captures.
:
: >2. .call() and both types of call() all pass on the arguments of
On 20 Sep 2006, at 19:05, Larry Wall wrote:
Let it be. :)
I could just as easily have called for a revolution :)
--
Andy Armstrong, hexten.net
On Wed, Sep 20, 2006 at 06:54:11PM +0100, Andy Armstrong wrote:
: The Beatles" probably sounded like a really dumb name for a band once.
:
: Is there a serious objection to letting it be?
Let it be. :)
Larry
On Wed, Sep 20, 2006 at 11:18:09AM -0400, Aaron Sherman wrote:
: Trey Harris wrote:
: >Might I propose the following normalization:
: >
: >1. .call, method definition call(), and .wrap call all take captures.
:
: >2. .call() and both types of call() all pass on the arguments of the
: > current s
On 20 Sep 2006, at 18:41, Doug McNutt wrote:
I never thought about the potential for serious ambiguity in
interpretation. The UNIX grep tool is really dissimilar considering
that it uses a different regular expression syntax.
(perl grep doesn't have to be used with an RE of course)
I guess
Just a perl 5 physicist here. I had to run to the Camel book to find out that
grep existed in the world of perl. But I have done this (from memory):
$stuff_in_lines = `grep suntide *.txt`;
I never thought about the potential for serious ambiguity in interpretation.
The UNIX grep tool is really
Quoth [EMAIL PROTECTED]:
> On Tue, Sep 19, 2006 at 04:38:38PM +0200, Thomas Wittek wrote:
> > Jonathan Lang schrieb:
> > > IMHO, syntax should be left alone until a compelling reason to change
> > > it is found. While I think it would be nice to have a more intuitive
> > > name for grep
> > What
Trey Harris wrote:
Might I propose the following normalization:
1. .call, method definition call(), and .wrap call all take captures.
2. .call() and both types of call() all pass on the arguments of the
current subroutine.
> 3. To call with no arguments, use .call(\()) and call(\()).
I
[EMAIL PROTECTED] wrote:
I still don't think we have a consensus that grep needs to be renamed,
much less what it should be renamed to. To me, "keep" implies throwing
the rest away,I.e., modifying the list. "Select" has the advantage of
lacking that connotation. To avoid dissonance with the two
I still don't think we have a consensus that grep needs to be renamed,
much less what it should be renamed to. To me, "keep" implies throwing
the rest away,I.e., modifying the list. "Select" has the advantage of
lacking that connotation. To avoid dissonance with the two perl5
"select"s, we could
Aaron (>):
OK then. Just so that I can type of the final result in S29, let's see
if everyone agrees to several points that have been made in this thread:
1. "classify" is the real grep
2. convenience function, "keep" is probably a macro
3. "use List :compat" will get you a "grep" just as it wil
Damian Conway wrote:
In other words, classify() takes a list of values, examines each in
turn, and ascribes a "label" value to it. The call returns a list of
pairs, where each pair key is one of the label values and each pair
value is an array of all the list values that were ascribed that labe
From S06:
sub bar ($a,$b,$c,:$mice) { say $mice }
sub foo (\$args) { say $args.perl; &bar.call($args); }
The C<.call> method of C objects accepts a single C
object, and calls it without introducing a C frame.
And from S12:
In addition to C, the special function C dispatches
Author: audreyt
Date: Wed Sep 20 03:27:09 2006
New Revision: 12247
Modified:
doc/trunk/design/syn/S06.pod
Log:
* Ditto.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++
Author: audreyt
Date: Wed Sep 20 03:22:42 2006
New Revision: 12246
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: TreyHarris++ pointed out another slurpy-star legacy.
Modified: doc/trunk/design/syn/S06.pod
==
---
Just to point out that it's probably worth going back and rereading the
earlier iterations of this discussion, in December 2002 (subject: "purge: the
opposite of grep") and November 2005 (subject: "Classification syntax"). That
way, those who repeat history are condemned to study it. ;-)
In su
Author: audreyt
Date: Wed Sep 20 02:41:02 2006
New Revision: 12239
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: As &code.call() is specified to take one single
Capture argument, fix the example in which the
argument was erroneously flattened.
Modified: doc/trunk/design/syn
Jonathan Lang skribis 2006-09-19 16:39 (-0700):
> >Anyway, it's not clear to me that grep always has an exact opposite.
> I don't see why it ever wouldn't: you test each item in the list, and
> the item either passes or fails. 'select' would filter out the items
> that fail the test, while 'reject
33 matches
Mail list logo
