Re: renaming grep to where
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' would filter out the ones that pass
it.
There's a neat trick for this: .grep:{ not ... }
HTH :)
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: renaming grep to where
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 summary, when we last left this discussion, Larry was inclined to retain
the name 'grep', and to add a 'classify' built-in that would allow positional
or named partitioning of a list. For example (in updated syntax):
(:@sheep, :@goats) := classify { /baaa/ ?? 'sheep' !! 'goats' } @list;
(@x, @y, @huh).pairs := classify { /she/ ?? 0 !! /he/ ?? 1 !! 2 } @list;
%people_who_use
= classify { /[EMAIL PROTECTED]/ ?? 'perl' !! /[()]/ ?? 'lisp' !!
'???' }
@people;
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 label.
Personally, I don't have a problem with us keeping 'grep'. However, if we do
decide to change the name, I suspect 'keep' might be readable, short, SWIM,
and not confused with other operations:
my @evens = keep { $^num % 2 == 0 } @numbers;
Damian
[svn:perl6-synopsis] r12246 - doc/trunk/design/syn
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
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podWed Sep 20 03:22:42 2006
@@ -15,7 +15,7 @@
Date: 21 Mar 2003
Last Modified: 20 Sept 2006
Number: 6
- Version: 55
+ Version: 56
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -2118,7 +2118,7 @@
It can then be passed to Ccall as C*$args:
# Double the return value for thermo
-thermo.wrap( - \$args { call(*$args) * 2 } );
+thermo.wrap( - \$args { call([,] =$args) * 2 } );
The wrapper is not required to call the original routine; it can call another
CCode object by passing the CCapture to its Ccall method:
[svn:perl6-synopsis] r12247 - doc/trunk/design/syn
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)
+++ doc/trunk/design/syn/S06.podWed Sep 20 03:27:09 2006
@@ -2115,7 +2115,7 @@
temp thermo.wrap( { call($^t + 273.16) } );
The entire argument list may be captured by the C\$args parameter.
-It can then be passed to Ccall as C*$args:
+It can then be passed to Ccall as C[,] =$args:
# Double the return value for thermo
thermo.wrap( - \$args { call([,] =$args) * 2 } );
call, call(), .call, and captures
From S06:
sub bar ($a,$b,$c,:$mice) { say $mice }
sub foo (\$args) { say $args.perl; bar.call($args); }
The C.call method of CCode objects accepts a single CCapture
object, and calls it without introducing a CCALLER frame.
And from S12:
In addition to Cnext METHOD, the special function Ccall dispatches
to the next candidate, possibly with a new argument list:
call; # calls with the original arguments
call(); # calls with no arguments
call(1,2,3);# calls with a different set of arguments
And back in S06:
The entire argument list may be captured by the C\$args parameter.
It can then be passed to Ccall as C[,] =$args:
# Double the return value for thermo
thermo.wrap( - \$args { call([,] =$args) * 2 } );
The inconsistency between these three things called call is vexing to
me. One is a method and takes a capture and only a capture. The second is
a special function and takes an argument list, but also has a special
arglistless form that passes on the original arguments. The third is a
function that takes only a function list, but apparently lacks a
arglistless form (otherwise, why bother with capturing an arglist in the
example?).
I believe the current spec works. I just think the inconsistency is
bad--the three things called call do very similar things, but take
completely different arguments. I suspect this is just historical smear
and we just need to back up and normalize.
(Let me quickly note here that I don't think it's possible to write a
subroutine or method that can take either a bare argument list or a
Capture and treat them the same, because of the intractable ambiguity that
would arise in the case of an argument list that actually contains a
single capture as its only positional element. If I'm mistaken, then
other avenues open up. But I don't think I am.)
Audrey confirmed to me on IRC that the motivation for the arglistless form
was that passing on the original arguments will likely be one of the most
common uses of call. And I certainly can't argue with that, I agree.
But why, then, does .call not have an argumentless form? (Because we
can't write user-defined methods, short of Cis parsed tricks, that
differentiate between .meth and .meth()? We can't write user-defined subs
that do that either, AFAIK...)
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(\()).
4. Introduce some syntax for getting a capture of the current argument
list explicitly. Perhaps $?ARGS or $?_ or $?CAPTURE. One shouldn't
have to choose between repeating your 20 parameters in order to take a
capture of them, and eliminating your nice self-documenting 20
parameter names so you can use the easy \$arglist trick.
Trey
Re: renaming grep to where
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 label.
Personally, I don't have a problem with us keeping 'grep'. However, if
we do decide to change the name, I suspect 'keep' might be readable,
short, SWIM, and not confused with other operations:
my @evens = keep { $^num % 2 == 0 } @numbers;
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 will likely get
you mv on the OS module, etc.
Is any of this going to break the bank? If not, I'll get it in today.
Re: renaming grep to where
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 will likely get you mv on the OS module, etc. Is any of this going to break the bank? If not, I'll get it in today. You mean grep is going away? I'd had hoped that enough people had expressed their I like grep and Don't fix what isn't broken opinions for it not to... Oh well. I'll miss it. -- masak
Re: renaming grep to where
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
selects, we could go with a synonym like choose or, in the 4-char
category, pick. But my vote is still to keep grep as grep.
On 9/20/06, Aaron Sherman [EMAIL PROTECTED] wrote:
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 label.
Personally, I don't have a problem with us keeping 'grep'. However, if
we do decide to change the name, I suspect 'keep' might be readable,
short, SWIM, and not confused with other operations:
my @evens = keep { $^num % 2 == 0 } @numbers;
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 will likely get
you mv on the OS module, etc.
Is any of this going to break the bank? If not, I'll get it in today.
--
Mark J. Reed [EMAIL PROTECTED]
Re: renaming grep to where
[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 perl5 selects, we could go with a synonym like choose or, in the 4-char category, pick. But my vote is still to keep grep as grep. I don't know that we have consensus, I was just trying to bring this thread in for a landing so I can write it up. As S29 stands now, there is a grep, and there is no classify. At least the latter needs to be fixed, per Damian pointing out lost history that I should have been on top of. I'll wait on the removal of grep for any(@larry) to make a clear statement to that effect.
Re: call, call(), .call, and captures
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 have no problem with that, but the original form should probably exist too. I don't know if that's called invoke or what, but something that takes an arglist and constructs the capture to pass on would be very helpful to most users. 4. Introduce some syntax for getting a capture of the current argument list explicitly. Perhaps $?ARGS or $?_ or $?CAPTURE. One shouldn't have to choose between repeating your 20 parameters in order to take a capture of them, and eliminating your nice self-documenting 20 parameter names so you can use the easy \$arglist trick. I like the idea in 4, even though I'm not sure that I follow the rest of your logic. Having access to a variable that contains the current argument list called $?ARGS seems to be in line with the rest of the $? state variables that are provided. So, in general, I think the only thing missing is something like invoke so that: invoke(1,2,3); is identical to: call(\(1,2,3)); and: invoke([,] =$?ARGS); is identical to: call($?ARGS); is identical to: call(); Certainly a distinction on call vs call() is not what Perl 6 programmers will come to expect from the rest of the language, and I see no pressing reason to introduce it here.
Re: renaming grep to where
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 would be the disadvantage of renaming it to a more intuitive name? I can only see advantages. Lost culture perhaps. There's a long strong tradition of the term grep in perl and it would be a shame to toss that away without some serious thought. I would second that strongly. Perl6 is already different enough from Perl5 for good reasons; making it different for bad reasons seems to me a really bad idea. If this sort of change is on the cards, then for consistency a serious effort should be made to remove *all* Unixisms from Perl (unlink, flock, fork, and all the signal stuff spring to mind; a case could be made for the filetest ops as well). I think that that level of culture- and history-loss would be a real shame; I can see however that others may think it more important to make Perl more platform-agnostic in character as well as in implementation. Ben -- 'Deserve [death]? I daresay he did. Many live that deserve death. And some die that deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends.' [EMAIL PROTECTED]
Re: renaming grep to where
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 dissimilar considering that it uses a different regular expression syntax. -- -- Halloween == Oct 31 == Dec 25 == Christmas --
Re: renaming grep to where
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 there's a fine line between renaming things in Perl 6 because it's possible and because it's desirable. Once you're off the leash of the old language there's a perceived obligation to give everything the name that best represents its purpose - but things inhabit the names they're given. The Beatles probably sounded like a really dumb name for a band once. Is there a serious objection to letting it be? 'select' has POSIX and SQL meaning, 'where' has a SQL meaning, 'grep' has a Unix command connotation - but 'grep' has the benefit that it also has an existing perl connotation. -- Andy Armstrong, hexten.net
Re: call, call(), .call, and captures
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 subroutine. : : 3. To call with no arguments, use .call(\()) and call(\()). : : I have no problem with that, but the original form should probably exist : too. I don't know if that's called invoke or what, but something that : takes an arglist and constructs the capture to pass on would be very : helpful to most users. It would be suboptimal to give something so related a name that is completely unrelated. If we had such a thing it should callv or callargs or some such. But it's not yet clear to me that this is frequent enough to deserve the sugar over call(\(...)). By the way, call() is just short for nextroutine().call() or some such, where nextroutine() is a mystical call that retrieves the next candidate based on what kind of dispatcher we're in. : 4. Introduce some syntax for getting a capture of the current argument :list explicitly. Perhaps $?ARGS or $?_ or $?CAPTURE. One shouldn't :have to choose between repeating your 20 parameters in order to take a :capture of them, and eliminating your nice self-documenting 20 :parameter names so you can use the easy \$arglist trick. : : I like the idea in 4, even though I'm not sure that I follow the rest of : your logic. Having access to a variable that contains the current : argument list called $?ARGS seems to be in line with the rest of the $? : state variables that are provided. Uh, no, $? variables are supposed to be compile-time constants. That's why there's no $?SELF anymore. Since individual constraints within the siglet are considered to be anded, it might be possible to declare both a capture and the rest of the parameters like this:: sub foo (\$args $a, $b, $c) In other words we relax the constraint that \$x has to come at the end, so \$x would just take a snapshot of the rest of the args and keep processing the binding to any remaining parameters. : So, in general, I think the only thing missing is something like invoke : so that: : : invoke(1,2,3); : : is identical to: : : call(\(1,2,3)); : : and: : : invoke([,] =$?ARGS); : : is identical to: : : call($?ARGS); : : is identical to: : : call(); We might prefer a three-way distinction just to avoid user confusion: call; no args allowed, always uses existing parameters callcap($capture) one arg, must be capture (plus named?) callargs($a: $b, $c)same as callcap(\($a: $b, $c)); (plus the corresponding dot forms). Alternately, just keep callargs and force callcap to be written callargs([,] =$capture). After all, if you're going to do anything with the args, you're usually not interested in the whole original capture by itself. What we really need is a unary operator that is sugar for [,](=(...)). Just don't anyone suggest *. :-) Candidates: callargs(`$foo) callargs(_$foo) callargs(|$foo) callargs(¢$foo) Another approach would be to give captures a sigil that autoinserts, and you'd have to \ it to suppress that, much like @foo always interpolates into list context. Then we just get something like callargs(¢x) and the mixed declaration above would be sub foo (¢args $a, $b, $c) : Certainly a distinction on call vs call() is not what Perl 6 programmers : will come to expect from the rest of the language, and I see no pressing : reason to introduce it here. Yes, that would be a mistake. Macros that abuse () are a design smell. Larry
Re: renaming grep to where
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
Re: renaming grep to where
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
Re: call, call(), .call, and captures
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 the
:current subroutine.
:
: 3. To call with no arguments, use .call(\()) and call(\()).
:
: I have no problem with that, but the original form should probably exist
: too. I don't know if that's called invoke or what, but something that
: takes an arglist and constructs the capture to pass on would be very
: helpful to most users.
It would be suboptimal to give something so related a name that is
completely unrelated. If we had such a thing it should callv or
callargs or some such. But it's not yet clear to me that this is
frequent enough to deserve the sugar over call(\(...)).
invoke is just a very commonly used name in places like parrot and XS,
so I thought of it right off the bat.
I think your call, callargs and callcap are fine looking things.
As for $?ARGS, you're right, I was forgetting that it's not compile-time
constant.
Would $?ROUTINE have access to its current invocation? In other words,
could $?ROUTINE.args or $?ROUTINE.invocation.args find the current
invocation and ask for its capture? Why do I ask for that when you've
already said that signatures could include a capture? Macros. A macro
might want to do something with its caller's arguments, but doesn't know
what localized name it will have been given. If it can ask for its
$?ROUTINE, then it's always going to work.
macro debug() {
if $*ENVDEBUG {
q:code{
say(DEBUG: , $?ROUTINE.name,
called with: ,
Dumper($?ROUTINE.args))
};
} else {
q:code{1};
}
}
What we really need is a unary operator that is sugar for [,](=(...)). Just
don't anyone suggest *. :-)
I was thinking about that. I wonder if [\] would make sense, or is that
just begging to have in-editor parsers fall over screaming ;)
Other options might be (in decreasing order of my fondness for them):
callargs(-- $foo) -- a nice inverse to -
callargs($\ $foo)-- mnemonic: Dereference this capture
callargs(.* $foo)-- Ok, only to be passive-aggressive ;)
callargs(*\ $foo)-- kind of the same idea as $\
Candidates:
callargs(`$foo)
callargs(_$foo)
callargs(|$foo)
callargs(¢$foo)
None of these LOOK like capture-expansion to me other than _ which I'm
always hesitant to mess with. | seems too confusing.
Another approach would be to give captures a sigil that autoinserts, and
you'd have to \ it to suppress that, much like @foo always interpolates
into list context. Then we just get something like
callargs(¢x)
and the mixed declaration above would be
sub foo (¢args $a, $b, $c)
I've been a Perl programmer for 15 years, so I don't know why adding a
sigil would bother me, but it does... Can't give you a good reason,
though, so perhaps it's moot. Unicode sigils might have a valid ickiness
factor, though. I can't figure out what the ascii form of ¢ would be...
Certainly most expansions involving c and/or | are going to have
ambiguity problems.
Re: renaming grep to where
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 desire to not fix what ain't broken, helped them along their way to superstardom. I'm not sure if there is a lesson to be learned here. As I haven't previously spoken on the subject, I'll weigh in to express a slight preference for the name grep, though I like Larry's idea of a generalised 'divvy'. Last year, teaching ML, I taught the definition of the 'filter' function as 'grep', simply because I'd forgotten that it was called 'filter' in ML. Mind you, as it had been a year or two since I'd last used ML, I'd also forgotten a few of the other keywords, a problem I have with other languages too. Do you 'throw' or 'raise' an exception? Do you use 'else if', 'elseif', 'elsif', or 'elif'? I can see how aliases can be a Bad Thing, but when my mind is elsewhere I would appreciate some loan words from other languages. -- And for mile after mile you'll never see me tire/You'll never me me slow down for a while/'Cause I am the fox, like it or not/I'm always gonna be there running over the rock/ Yes I am the fox, a fascinating cross/ Of sharp as a whip and tough as an ox Bernie Taupin, 'The Fox' pgpWI4WXRDtv7.pgp Description: PGP signature
Capture sigil
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 to try to get these to behave when they're stored in a scalar variable: [,] =$capture Fact: This contrasts with the ease with which we can request arrayness and hashness using the @ and % sigils. 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 help. Bikeshed: What should that sigil be? And if it's in Latin-1, what's the ASCII workaround? Latin-1 candiates: ¡ 00A1INVERTED EXCLAMATION MARK ¢ 00A2CENT SIGN £ 00A3POUND SIGN ¤ 00A4CURRENCY SIGN ¥ 00A5YEN SIGN ¦ 00A6BROKEN BAR § 00A7SECTION SIGN ¨ 00A8DIAERESIS © 00A9COPYRIGHT SIGN ª 00AAFEMININE ORDINAL INDICATOR « 00ABLEFT-POINTING DOUBLE ANGLE QUOTATION MARK ¬ 00ACNOT SIGN 00ADSOFT HYPHEN ® 00AEREGISTERED SIGN ¯ 00AFMACRON ° 00B0DEGREE SIGN ± 00B1PLUS-MINUS SIGN ² 00B2SUPERSCRIPT TWO ³ 00B3SUPERSCRIPT THREE ´ 00B4ACUTE ACCENT µ 00B5MICRO SIGN ¶ 00B6PILCROW SIGN The obvious ASCII for ¢ would be c/ or C/ or c| or c| or maybe just |. The obvious ASCII for © would be (c), I suppose. Or instead of going for visual lookalikes, we could go for semantic likenesses. If @@ is multiple arrays, then @% or %@ could be an array mixed with a hash (and a scalar, but let's not go that far). Which leads me to wonder if there's a Latin-1 synonym for @@, like § maybe for sectional, or µ for multidimensional, or ® for, er, repetitious or something. Hmm, then ®©foo could take the multidimensional feeds out of capture foo. Maybe µ¢foo looks better though. Or maybe we could work the € in there somewhere for extra dimensional... ☺ On the other hand, we could just make |foo a capture because it inclusive-ORs several other structures. Main downside is that it looks too much like an ell. That's probably not a showstopper in practice. Much of the time we'd be using it to qualify other variables anyway, so instead of scattering [,] all over the place we would have things like foo(|$foo) foo(|@foo) foo(|%foo) foo(|foo) Visually it kinda works as an insert this here marker too. And most of the places you'd use it wouldn't be using | operators. Another factor is that it kind of resonates visually with the \ that makes captures. Larry
Re: Capture sigil
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 towards |. Whether it's the canonical sigil or the ASCII of ¢ doesn't much matter to me. Trey
Re: Capture sigil
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 # ASCII of ¢$foo d/$foo # d() divided by $foo is rather confusing. (Same goes for |). Oops, I meant same goes for c|. I like |: So the Term Term exclusion makes me rather lean towards |. Whether it's the canonical sigil or the ASCII of ¢ doesn't much matter to me. Trey
Re: Capture sigil
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 worth thinking about. Captures are useful beasts.
Fact: We're currently going through contortions to try to get these to behave
when they're stored in a scalar variable: [,] =$capture
Fact: This contrasts with the ease with which we can request arrayness
and hashness using the @ and % sigils.
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 sigil is the wrong way to go for several
reasons, but most important among them is that there are going to be a
lot of scalars that contain objects that are awfully capture-like, and
they'll need whatever semantics we deem appropriate for captures too.
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.
First of all, I need a word. I'm going to call an expanded capture a
signature even though that's a bit too metaish. I don't encourage
others to use this term, but it helps me to get my head around this. A
signature is a bit like a list. It has no data type that you can point
to directly. Signatures are also probably lazy like lists.
When we want to turn a capture that is stored in a scalar into a
signature, we need an operator that performs that action, and
unambiguously does NOT perform the action of turning it into a list. I
suggested some in my previous message (such as -- and $\).
Subroutines just so happen to take signatures, so you can invoke them
with one:
foo(-- $capture);
foo($\ $capture);
Now, you need to be able to go in the other direction. You need to be
able to assemble a signature and convert it into a capture. This, we
already have:
$cap = \(-- $othercap, $a, :$b)
$cap = \($\ $othercap, $a, :$b)
This would transform $othercap from a capture to a signature, add in a
positional and a named value and then re-integrate the resulting
signature as a new capture.
Calling subroutines with such a thing looks nice and clean:
$values = \([EMAIL PROTECTED], [EMAIL PROTECTED], $c, :mean1);
$avg1 = avg(-- $values, :undefignore);
$avg2 = avg(-- $values, :undefiszero);
That's as simple as you can get, and we didn't have to promote captures
to a new kind of sigil type to do it.
Re: Capture sigil
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 help. Once upon a time I had an unproposed proposal that the thing that distinguished @ from $ is that @ auto-flattens. So perhaps captures as well as arrays can be stored in @-variables, if you define flattening as the [,] operator. The reason I didn't propose it is because I couldn't figure out what to do with %. Luke
Re: Capture sigil
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 captured inside it, or trying to break out, and because we use currency to pass value(s) between individuals. I don't have an ASCII suggestion. -kolibrie
Re: Capture sigil
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 sigil is the wrong way to go for several
: reasons, but most important among them is that there are going to be a
: lot of scalars that contain objects that are awfully capture-like, and
: they'll need whatever semantics we deem appropriate for captures too.
I don't see how that follows. There will be lots of objects containing
lots of things that don't give a rip about having a capture interface.
: 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 going to be such an operator, and it probably won't be
Latin-1. The only question in my mind is whether it's also a sigil.
: First of all, I need a word. I'm going to call an expanded capture a
: signature even though that's a bit too metaish. I don't encourage
: others to use this term, but it helps me to get my head around this.
That's not a good choice of term, since signatures already mean something
else entirely in Perl 6.
: A signature is a bit like a list. It has no data type that you can point
: to directly. Signatures are also probably lazy like lists.
What you're calling a signature is in fact just another capture in our
terminology.
: When we want to turn a capture that is stored in a scalar into a
: signature, we need an operator that performs that action, and
: unambiguously does NOT perform the action of turning it into a list. I
: suggested some in my previous message (such as -- and $\).
The Style Police have rated those as slightly less ugly than [,]=.
: Subroutines just so happen to take signatures, so you can invoke them
: with one:
:
: foo(-- $capture);
: foo($\ $capture);
That's foo(|$capture) now.
: Now, you need to be able to go in the other direction. You need to be
: able to assemble a signature and convert it into a capture. This, we
: already have:
:
: $cap = \(-- $othercap, $a, :$b)
: $cap = \($\ $othercap, $a, :$b)
:
: This would transform $othercap from a capture to a signature, add in a
: positional and a named value and then re-integrate the resulting
: signature as a new capture.
In my current thinking that's just \( |$othercap, $a, :$b ).
: Calling subroutines with such a thing looks nice and clean:
:
: $values = \([EMAIL PROTECTED], [EMAIL PROTECTED], $c, :mean1);
: $avg1 = avg(-- $values, :undefignore);
: $avg2 = avg(-- $values, :undefiszero);
:
: That's as simple as you can get, and we didn't have to promote captures
: to a new kind of sigil type to do it.
I think | is a lot nice-and-cleaner and simpler than --. And it
can also work as a sigil.
Larry
Re: Capture sigil
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
Re: Capture sigil
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 such. Unfortunately the whatever use of * can't take unary argument or we fail to parse things like 0..*:by(2) correctly. Besides, people would accuse us of reintroducing typeglobs. :-) Which they aren't quite, but they're similar enough that a P5 person would think of *foo as a typeglob and be thoroughly confused. Oh, and we'd also have to rethink our use of * as a shorthand for GLOBAL::. Larry
Re: renaming grep to where
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: Let it be. :) --
Re: renaming grep to where
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 differently:
:
: On 20 Sep 2006, at 19:05, Larry Wall whispered words of wisdom:
: Let it be. :)
my Yellow sub marine { @we.all.live }
Larry
Re: Capture sigil
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 going to be such an operator, and it probably won't be Latin-1. The only question in my mind is whether it's also a sigil. Well, that sounds reasonable enough. Let me take the last point, then, which I'm only slightly convinced I have a good answer for: They just don't seem important enough to pump out another sigil for. Filehandles are FAR more valuable and potentially semantically rich, so I would expect them to get their own sigil long before captures. If captures have an expand-o-op, then I think they have everything they need to be on-par with features like filehandles. : When we want to turn a capture that is stored in a scalar into a : signature, we need an operator that performs that action, and : unambiguously does NOT perform the action of turning it into a list. I : suggested some in my previous message (such as -- and $\). The Style Police have rated those as slightly less ugly than [,]=. My problem with [,]= is not that it's ugly (it is, a bit), but that it's two operations which are both being slightly bent out of shape for their use here. I do agree that capture expansion is something which demands its own op. : Subroutines just so happen to take signatures, so you can invoke them : with one: : : foo(-- $capture); : foo($\ $capture); That's foo(|$capture) now. Hrm... ugly is one thing, but visual ambiguity is another. With an operator like -- one can use or discard the parens at will. However, with | there is no alternative, since: x |$y could be a programmer trying to say: x() | $y I cry for a Q/A group every time I see that kind of thing go into Perl 6. It's especially unfortunate because there might be a fair amount of value to coercing simple types into captures, but we don't want to in this case, so that we can catch such errors. ... In my current thinking that's just \( |$othercap, $a, :$b ). Yep, if |$ is the capture sigil (making | the sigil prefix op) then this is a fairly obvious extrapolation from your previous messages. : Calling subroutines with such a thing looks nice and clean: : : $values = \([EMAIL PROTECTED], [EMAIL PROTECTED], $c, :mean1); : $avg1 = avg(-- $values, :undefignore); : $avg2 = avg(-- $values, :undefiszero); : : That's as simple as you can get, and we didn't have to promote captures : to a new kind of sigil type to do it. I think | is a lot nice-and-cleaner and simpler than --. And it can also work as a sigil. Keep in mind that, while -- is my strongest current idea, I'm more advocating the non-ambiguous, non-sigil idea, and not championing any particular implementation of that idea. One reason that I liked -- was for the fact that it looks like -- which defines return type inside of a signature. Though it's not clear to me if knowlege of expected return type is wrapped up in a capture. If so, then perhaps this is how you re-dispatch with a forced/overridden context: callargs(-- $args --Int); Though I admit that's going to catch HTML/XML programmers off-guard ;)
Re: Capture sigil
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 through contortions to try to get these to behave
when they're stored in a scalar variable: [,] =$capture
Fact: This contrasts with the ease with which we can request arrayness
and hashness using the @ and % sigils.
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 help.
Let me see if I'm following you correctly:
¤args = \(1,2,3,:miceblind)
Is the backslash still neccessary, or is the use of the Capture sigil
enough to indicate that the rvalue should be treated as a capture
object?
$¤args; # would this return 1 or an indication that
nothing's there?
@¤args; # would this return [1, 2, 3], or [2, 3]?
%¤args; # this would return { mice - 'blind' }
Would '¤¤args' mean anything?
Does '¤args' mean anything?
(I like '¤' for capture objects, because it reminds me of '*', and
capture objects remind me of Perl 5's typeglobs. Perhaps the ASCII
workaround could be '**'?)
'$¤args' would mean retrieve the scalar portion of the capture object
'args'; '¤$args' would mean treat the scalar object 'args' as if it
were a capture object. Right? (And what, precisely, is meant by
treating a scalar as if it were a capture object?)
Which leads me to wonder if there's a Latin-1 synonym for @@, like §
maybe for sectional, or µ for multidimensional, or (r) for, er, repetitious
or something.
Of these, I like the idea of § for Latin-1 equivalent of @@. Not only
does it have the meaning of section, but it registers in my brain as
this looks sigilish - perhaps due to its vague visual resemblance to
the dollar sign (oddly enough, ¢ doesn't look sigilish to me; I don't
know why not, but it doesn't). Do this, and the sigil set becomes:
$ scalar
@ ordered array
§ multislice view of @ (ASCII alias: @@)
% unordered hash, i.e. associative array
¤ capture object (ASCII alias: **)
code/rule/token/regex
:: package/module/class/role/subset/enum/type/grammar
Hmm, then (r)(c)foo could take the multidimensional feeds out of capture
foo. Maybe µ¢foo looks better though. Or maybe we could work
the € in there somewhere for extra dimensional... ☺
Ack! I beg you; stop the line noise!
On the other hand, we could just make |foo a capture because it
inclusive-ORs several other structures. Main downside is that it looks
too much like an ell. That's probably not a showstopper in practice.
Much of the time we'd be using it to qualify other variables anyway, so
instead of scattering [,] all over the place we would have things like
foo(|$foo)
foo(|@foo)
foo(|%foo)
foo(|foo)
I'm lost. What would '|@foo' mean?
Visually it kinda works as an insert this here marker too. And most
of the places you'd use it wouldn't be using | operators. Another factor
is that it kind of resonates visually with the \ that makes captures.
Please remind me: what does perl 6 do with '$(...)' and '@(...)'? And
oughtn't it do something analogous with '|(...)', '¤(...)', or
whatever the capture sigil turns out to be? Would that differ from
'\(...)'?
--
Jonathan Dataweaver Lang
[svn:perl6-synopsis] r12284 - doc/trunk/design/syn
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 == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podWed Sep 20 22:07:47 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 18 Sept 2006 + Last Modified: 20 Sept 2006 Number: 2 - Version: 69 + Version: 70 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -670,6 +670,7 @@ @ ordered array % unordered hash (associative array) code/rule/token/regex +| capture/arguments/match :: package/module/class/role/subset/enum/type/grammar @@ multislice view of @ @@ -817,15 +818,22 @@ $$args; # same as $args as Scalar or Scalar($args) @$args; # same as $args as Array or Array($args) %$args; # same as $args as Hash or Hash($args) +|$args; # all of the above When cast into an array, you can access all the positional arguments; into a hash, all named arguments; into a scalar, its invocant. +When stored in a variable using the C| sigil, the capture autointerpolates +into argument lists much like C@ autoflattens into lists: + +|args := \($a, @b, :option($c)); +somefunc(|args); # same as somefunc($a, @b, :option($c)) + All prefix sigil operators accept one positional argument, evaluated in scalar context as a rvalue. They can interpolate in strings if called with parentheses. The special syntax form C$() translates into C$( $/ ) to operate on the current match object; the same applies to C@(), C%() and -C*() forms. +C|() forms. CCapture objects fill the ecological niche of references in Perl 6. You can think of them as fat references, that is, references that Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podWed Sep 20 22:07:47 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 8 Mar 2004 - Last Modified: 16 Sep 2006 + Last Modified: 20 Sept 2006 Number: 3 - Version: 66 + Version: 67 =head1 Changes to Perl 5 operators @@ -65,7 +65,8 @@ argument, and C+ imposes a numeric (CNum) context (as opposed to being a no-op in Perl 5). Along the same lines, C? imposes a boolean (CBool) context, and the C[,] list operator imposes -a function-arguments (CCapture) context on its arguments. +a function-arguments (CCapture) context on its arguments (as does +the C| sigil when used as an operator). Unary sigils impose the container context implied by their sigil. As with Perl 5, however, C$$foo[bar] parses as C( $($foo) )[bar], so you need C$($foo[bar]) to mean the other way. @@ -1295,11 +1296,14 @@ interpolator, by casting its operands to CCapture objects and inserting them into the current argument list. -It can be used to interpolate an CArray or CHash into the current -call, as positional and named arguments respectively. +The C| capture sigil may also be used for this when you want to +interpolate a single item. + +Either of these can be used to interpolate an CArray or CHash +into the current call, as positional and named arguments respectively. Note that those arguments still must comply with the subroutine's -signature, but the presence of C[,] defers that test until run time for +signature, but the presence of C| or C[,] defers that test until run time for that argument (and for any subsequent arguments): my @args = [EMAIL PROTECTED], @bar; @@ -1312,7 +1316,16 @@ as is this: my $args = \(@foo, @bar);# construct a Capture object -push [,] @$args; +push |$args; + +The C| sigil functions as a unary form of the C[,] +list operator, so we could have written the earlier example as: + +my @args = [EMAIL PROTECTED], @bar; +push |@args; + +To the extent possible, the C| will treat its argument as +a CCapture even if it isn't. In list context, a CScalar holding an CArray object does not flatten. Hence @@ -1320,15 +1333,16 @@ push @foo, $bar; merely pushes a single CArray object onto C@foo. You can -explicitly flatten it in either of these ways: +explicitly flatten it in one of these ways: push @foo, @$bar; push @foo, $bar[]; +push @foo, |$bar; -Those two forms work because the slurpy array in Cpush's signature +Those three forms work because the slurpy array in Cpush's signature flattens the CArray object into a list argument. -Note that those two forms also allow you to specify list context on +Note that
