Re: Capture sigil
On Thu, Sep 21, 2006 at 10:20:20PM -0700, Jonathan Lang wrote: : Two questions: : : 1. How would the capture sigil affect the use of capture objects as : replacements for perl5's references? I don't see how it would have any effect at all, unless the P5 ref happened to be to a typeglob, or had both array and hash semantics tied to it. The regular $$x, @$x, and %$x look much like they do in P5. : 2. With the introduction of the capture sigil, would it be worthwhile : to allow someone to specify a signature as a capture object's 'type'? : That is: : :my :(Dog: Str $name, Num :legs) |x = \($spot: Spot):legs4; : : in analogy to 'my Dog $spot'? There are a several syntax errors in there, and we currently don't allow assignment to a capture, only binding. Semantically, I don't know what such a construct would buy you over the already defined: my (|x Dog: Str $name, Num :$legs) := \($spot: Spot, :legs(4)); Larry
Re: Capture sigil
Larry Wall wrote: Jonathan Lang wrote: : Two questions: : : 1. How would the capture sigil affect the use of capture objects as : replacements for perl5's references? I don't see how it would have any effect at all, unless the P5 ref happened to be to a typeglob, or had both array and hash semantics tied to it. The regular $$x, @$x, and %$x look much like they do in P5. But $x is a scalar; wouldn't you need to use '|x' to denote a capture object, thus making the above '$|x', '@|x', and '%|x', respectively? we currently don't allow assignment to a capture, only binding. IOW, if you want someone to be able to say '$|x' and get '$a' as a result, you'd have to say '|x := \$a' (or perhaps '$|x := $a') instead of '|x = \$a'. Right? -- Jonathan Dataweaver Lang
Re: Capture sigil
On Fri, Sep 22, 2006 at 12:32:27AM -0700, Jonathan Lang wrote: : Larry Wall wrote: : Jonathan Lang wrote: : : Two questions: : : : : 1. How would the capture sigil affect the use of capture objects as : : replacements for perl5's references? : : I don't see how it would have any effect at all, unless the P5 ref happened : to be to a typeglob, or had both array and hash semantics tied to it. : The regular $$x, @$x, and %$x look much like they do in P5. : : But $x is a scalar; wouldn't you need to use '|x' to denote a capture : object, thus making the above '$|x', '@|x', and '%|x', respectively? You don't need to use | to store a capture any more than you need @ to store an array. Just as $x = @b; @$x; gives you the original array, likewise $x = [EMAIL PROTECTED]; @$a; gives you the original array as well. : we currently don't allow assignment to a capture, only binding. : : IOW, if you want someone to be able to say '$|x' and get '$a' as a : result, you'd have to say '|x := \$a' (or perhaps '$|x := $a') instead : of '|x = \$a'. Right? Yes. That's how it's currently specced, anyway. (The \ is probably required, or it'll try to bind to the contents of $a instead.) Larry
Re: Capture sigil
Larry Wall wrote: You don't need to use | to store a capture any more than you need @ to store an array. Just as $x = @b; @$x; gives you the original array, Huh. I'm not used to this happening. So what would the following code do, and why? my @b = ('foo', 'bar'); my $x = @b; say $x; likewise $x = [EMAIL PROTECTED]; @$a; gives you the original array as well. Err... don't you mean '@$x' instead of '@$a'? : we currently don't allow assignment to a capture, only binding. : : IOW, if you want someone to be able to say '$|x' and get '$a' as a : result, you'd have to say '|x := \$a' (or perhaps '$|x := $a') instead : of '|x = \$a'. Right? Yes. That's how it's currently specced, anyway. (The \ is probably required, or it'll try to bind to the contents of $a instead.) ??? There's some potential non-dwimmery here - either that, or there's a steep learning curve (that I haven't mastered) before dwimmery can be applied[1]. I would expect $|x to refer to the scalar slot of the capture object |x; as such, '$|x := ...' would mean 'bind the scalar slot of |x to ...'. Likewise, I would expect '... := $a' to mean 'bind ... to the scalar variable $a'. Or is the distinction between '$a' and 'the contents of $a' similar to the distinction between a Unix filename and a Unix file ID? That is, are we talking about the difference between hard links and symbolic links in Unix? -- Jonathan Dataweaver Lang [1] I'm not sure that there's much of a difference between the two statements.
Re: Capture sigil
Jonathan Lang wrote: Larry Wall wrote: You don't need to use | to store a capture any more than you need @ to store an array. Just as $x = @b; @$x; gives you the original array, Huh. I'm not used to this happening. So what would the following code do, and why? my @b = ('foo', 'bar'); my $x = @b; say $x; @b gets a list shoved into it $x gets the array @b shoved into it The array @b gets printed. Arrays in a scalar context in Perl6 auto-capture themselves and the scalar becomes a reference to the array (or hash, or even capture, for that matter). At a higher level, think of it this way: all data types are objects. Assigning an array into a scalar is just a change in notation. likewise $x = [EMAIL PROTECTED]; @$a; gives you the original array as well. Err... don't you mean '@$x' instead of '@$a'? Yes, he does. : we currently don't allow assignment to a capture, only binding. : : IOW, if you want someone to be able to say '$|x' and get '$a' as a : result, you'd have to say '|x := \$a' (or perhaps '$|x := $a') instead : of '|x = \$a'. Right? Yes. That's how it's currently specced, anyway. (The \ is probably required, or it'll try to bind to the contents of $a instead.) ??? IMHO most of the confusion here goes away if capture variables ONLY store parameter-list-like captures, and any other kind of capture should, IMHO, permute itself into such a structure if you try to store it into one. That way, their use is carefully constrained to the places where Perl 6 can't already do the job.
Re: Capture sigil
Aaron Sherman wrote: IMHO most of the confusion here goes away if capture variables ONLY store parameter-list-like captures, and any other kind of capture should, IMHO, permute itself into such a structure if you try to store it into one. That way, their use is carefully constrained to the places where Perl 6 can't already do the job. My understanding is that perl6 treats references as subsets of the capture object - something along the lines of the following (WARNING - this is going to border on 'internals' territory): When you bind a variable to an object, that variable becomes a synonym of that object for all purposes. However, barring auto-capturing, the variable's sigil must match the object's type: bind a scalar variable to an object, and the object better know how to behave like a scalar, else you have trouble. I understood that list-like objects generally don't know how to behave like scalars, and vice versa. A capture object is an object that's intended to allow for indirection: it's a perl6opaque object with (at least) three attributes inside, all of which are to be used exclusively for binding purposes: in effect, it's something like: role Capture { has $invocant, @positional, %named, ::returnType; } Note that you don't need any or | attributes in order to capture a parameter list. The '\' prefix operator constructs a Capture object and binds the various parts of its parameter list to the appropriate attributes. The '$' prefix operator returns the Capture object's $invocant attribute; the '@' prefix operator returns the Capture object's @positional attribute; the Capture object's '%' prefix operator returns the Capture object's %named attribute; and the Capture object's '::' prefix operator returns the Capture object's ::returnType attribute. Such a Capture object would be unable to capture codeblocks or other Capture objects without extending its capabilities. That is, '\code' wouldn't have an attribute to bind to code. There _might_ be a way around this without introducing a new attribute, but only if code objects know how to behave like scalars. I may be off in terms of some of the details; but am I on the right course in general? -- Jonathan Dataweaver Lang
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. Also; role type parameters Sam.
Re: Capture sigil
Two questions: 1. How would the capture sigil affect the use of capture objects as replacements for perl5's references? 2. With the introduction of the capture sigil, would it be worthwhile to allow someone to specify a signature as a capture object's 'type'? That is: my :(Dog: Str $name, Num :legs) |x = /($spot: Spot):legs4; in analogy to 'my Dog $spot'? -- Jonathan Dataweaver Lang
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: 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