Re: Capture sigil

2006-09-22 Thread Larry Wall
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

2006-09-22 Thread Jonathan Lang

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

2006-09-22 Thread Larry Wall
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

2006-09-22 Thread Jonathan Lang

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

2006-09-22 Thread Aaron Sherman

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

2006-09-22 Thread Jonathan Lang

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

2006-09-21 Thread Sam Vilain
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

2006-09-21 Thread Jonathan Lang

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

2006-09-20 Thread Trey Harris

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

2006-09-20 Thread Trey Harris
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

2006-09-20 Thread Aaron Sherman

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

2006-09-20 Thread Luke Palmer

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

2006-09-20 Thread Nathan Gray
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

2006-09-20 Thread Larry Wall
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

2006-09-20 Thread Smylers
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

2006-09-20 Thread Larry Wall
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

2006-09-20 Thread Aaron Sherman

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

2006-09-20 Thread Jonathan Lang

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