-library/Containers.pod
Log Message:
---
Adjust some prototypes to post-GLR implementation state.
Also, write better natural-language descriptions of some methods, since the
pseudocode had gone stale anyway.
Remove map(*) as it was removed during GLR.
Grammar and whitespace
HaloO,
Larry Wall wrote:
Basically, all types do Package whenever they need an associated
namespace.
Great! This is how I imagined things to be. And the reason why
the :: sigil is also the separator of namespaces.
And most of the Package role is simply:
method postfix:<::> () { return
On 9/29/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
And here I thought you were a responsible, law-abiding citizen... :P
And so it begins.
I daresay there will be no shortage of jokes among P6ers about "does Hash" ...
--
Mark J. Reed <[EMAIL PROTECTED]>
Larry Wall wrote:
but only if self.HOW does Hash.
And here I thought you were a responsible, law-abiding citizen... :P
--
Jonathan "Dataweaver" Lang
On Fri, Sep 29, 2006 at 01:24:12PM -0700, Larry Wall wrote:
: method postfix:<::> () { return %.HOW.packagehash }
Urque.
Actually, that'd have to be %($.HOW.packagehash) or $.HOW.packagehash.{},
since what I wrote there would mean %(self.HOW).packagehash instead, which
might work accidentally
On Fri, Sep 29, 2006 at 02:05:06PM -0400, Mark J. Reed wrote:
: On 9/29/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
: >Terminology issue: IIRC (and please correct me if I'm wrong), Perl 6
: >uses 'module' to refer to 'a perl 5-or-earlier module', and uses
: >'package' to refer to the perl 6-or-lat
Mark J. Reed wrote:
Jonathan Lang wrote:
> Terminology issue: IIRC (and please correct me if I'm wrong), Perl 6
> uses 'module' to refer to 'a perl 5-or-earlier module', and uses
> 'package' to refer to the perl 6-or-later equivalent.
Other way around. "package" is Perl 5, because that's the P5
On 9/29/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
Terminology issue: IIRC (and please correct me if I'm wrong), Perl 6
uses 'module' to refer to 'a perl 5-or-earlier module', and uses
'package' to refer to the perl 6-or-later equivalent.
Other way around. "package" is Perl 5, because that'
On Fri, Sep 29, 2006 at 12:35:43AM -0700, Trey Harris wrote:
: If you define a BUILD in a role, will it be called when an object of a
: class that does the role is instantiated, as part of the .new BUILD walk?
Yes. That is mentioned in A12, even if S12 didn't make it explicit.
At least S12:531 i
t is about requiring
minimal functionality from the parties in the contract, not about
banning them from going above the requirements. Secondly, what happens
when you use two modules with two different prototypes for the same
multi? Without this declaration, and assuming the modules don'
Terminology issue: IIRC (and please correct me if I'm wrong), Perl 6
uses 'module' to refer to 'a perl 5-or-earlier module', and uses
'package' to refer to the perl 6-or-later equivalent.
Aaron Sherman wrote:
Details:
Larry has said that programming by contract is one of the many paradigms
that
In a message dated Fri, 29 Sep 2006, Aaron Sherman writes:
First the high-level point: I'm dropping the RFC, because, as TimToady
pointed out on IRC, we're not quite far enough down the line to see the
breadth or certainty of the need yet.
Yes, but I don't think the conversation should stop.
In a message dated Thu, 28 Sep 2006, Jonathan Lang writes:
while roles can be abstract, classes and packages should not be.
Really? I think I need to let that sink in and percolate a bit.
I'm rather fond of creating abstract superclasses to factor out common
object-management code. I have m
Jonathan Lang wrote:
I hope not. My understanding is that '{ ... }' is supposed to
represent the notion of abstract routines: if you compose a role that
has such routines into a class or package, I'd expect the package to
complain bitterly if any such routines are left with yada-yadas as
their c
Trey Harris wrote:
One thing that occurs to me: following this "contract" or "promise"
analogy, what does C<...> mean in a role or class?
Unless I've missed somewhere in the Synopses that explicates C<...>
differently in this context, yada-yada-yada is just code that "complains
bitterly (by call
In a message dated Thu, 28 Sep 2006, Aaron Sherman writes:
Jonathan Lang wrote:
Aaron Sherman wrote:
Jonathan Lang wrote:
> Actually, it's a promise made by a package (not a class) to meet the
> specification given by a role (which can, and in this case probably
> does, reside in a separate fil
Jonathan Lang wrote:
Aaron Sherman wrote:
Jonathan Lang wrote:
> Actually, it's a promise made by a package (not a class) to meet the
> specification given by a role (which can, and in this case probably
> does, reside in a separate file - quite likely one heavily laced with
> POD).
That's a fi
Aaron Sherman wrote:
Jonathan Lang wrote:
> Actually, it's a promise made by a package (not a class) to meet the
> specification given by a role (which can, and in this case probably
> does, reside in a separate file - quite likely one heavily laced with
> POD).
That's a fine thing to want to do
Jonathan Lang wrote:
Aaron Sherman wrote:
TSa wrote:
> Miroslav Silovic wrote:
>> package Foo does FooMultiPrototypes {
>> ...
>> }
>
> I like this idea because it makes roles the central bearer of type
> information.
Type information is secondary to the proposal, but I'll run with what
you sai
Aaron Sherman wrote:
TSa wrote:
> Miroslav Silovic wrote:
>> package Foo does FooMultiPrototypes {
>> ...
>> }
>
> I like this idea because it makes roles the central bearer of type
> information.
Type information is secondary to the proposal, but I'll run with what
you said.
This (the example,
a
constraint. It's more of a second definition, and there isn't much need
for that in Perl 6.
I'm starting to think that "proto" was the wrong word, as it immediately
makes people think about C/C++ "prototypes", which are not at all the
same beast.
O
HaloO,
Trey Harris wrote:
I would hate for Perl 6 to start using C or C in the
sort of ways that many languages abuse "Object" to get around the
restrictions of their type systems. I think that, as a rule, any
prototype encompassing all variants of a multi should not only
specify types big e
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe that
declarative requirements should go on roles. And then packages could do
them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the central bea
Aaron Sherman wrote:
I certainly hope not, as I agree with you! That's not the goal at all,
and in fact if that were a side effect, I would not want this to be
implemented. The idea of having types AT ALL for protos was something
that I threw in because it seemed to make sense at the end. The re
Trey Harris wrote:
In a message dated Wed, 27 Sep 2006, Aaron Sherman writes:
Any thoughts?
I'm still thinking about the practical implications of this... but
what immediately occurs to me:
The point of multiple, as opposed to single, dispatch (well, one of
the points, and the only point t
Minor nitpick:
Any types used will constrain multis to explicitly matching those types
or compatible types, so:
our Int proto max(Seq @seq, *%adverbs) {...}
Would not allow for a max multi that returned a string (probably not a
good idea).
IIRC, perl 6 doesn't pay attention to the le
n do max, and not on anything that can't. Following that
observation to its logical conclusion, at some point we get to the core
containing prototypes like:
our proto max(Maxable $container)
our proto sort(Sortable $container)
our proto keys(Keyable $container)
which (I think) results i
Executive summary:
I suggest a signature prototype that all multis defined in or exported
to the current namespace must match (they match if the proto would allow
the same argument list as the multi, though the multi may be more
specific). Prototypes are exportable. Documentation tie-ins are
Bryan wrote:
> > > Er, scratch this. Blows up if the sub isn't prototyped. A much
> > > *better* way is to make the prototype of any sub a property
> > > (trait) of that sub. We can always query for a property.
> >
> > This is possible now:
> > $foo = sub ($) { print "hello wor
On Tuesday 04 September 2001 11:17 am, Garrett Goebel wrote:
> > Er, scratch this. Blows up if the sub isn't prototyped. A
> > much *better* way is to make the prototype of any sub a
> > property (trait) of that sub. We can always query for a
> > property.
>
> This is possible now:
>
> $foo = s
From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
>
> On Monday 03 September 2001 11:56 pm, Bryan C. Warnock wrote:
> > The third value is a "peek" value. Do the runtime
> > checking, but don't do any magic variable stuff. As a
> > matter of fact, don't run any user-code at all. Simply
> > re
On Monday 03 September 2001 11:56 pm, Bryan C. Warnock wrote:
> The third value is a "peek" value. Do the runtime checking, but don't do
> any magic variable stuff. As a matter of fact, don't run any user-code at
> all. Simply return a true or false value if the arguments *would* match.
> (This
> > Are prototypes going to be checked at runtime now?
>
> For methods, at least. Dunno about subs, that's Larry's call. I
> could make a good language case for and against it. It adds
> overhead on sub calls, which is a bad thing generally.
I
> But since the current prototyping system... has a highly positive
> pressure gradient compared to the surrounding air,
Well...I think it's more a problem of "I do no' thin' dat word means
wha' you thin' it means".
People want prototypes to b
At 11:47 PM 9/3/2001 -0400, Ken Fox wrote:
>"Bryan C. Warnock" wrote:
> > {
> > my $a = sub ($$) { code };
> > gork($a);
> > }
> >
> > sub gork {
> > my ($a) = shift;
> > $a->(@some_list); # <- Here
> >
A few more ideas to put down, lest I lay wake all night, thoughts churning...
One.
Presumably, there will be an op for the actual calling of the subroutine.
That op can take an (extra) argument, with one of three values, that the
prototype checking can get to.
The first value indicates that th
"Bryan C. Warnock" wrote:
> {
> my $a = sub ($$) { code };
> gork($a);
> }
>
> sub gork {
> my ($a) = shift;
> $a->(@some_list); # <- Here
> }
>
> The reason prototypes aren't checked at "Here" is because there
, where compile-time checking isn't possible.
{
my $a = sub ($$) { code };
gork($a);
}
sub gork {
my ($a) = shift;
$a->(@some_list); # <- Here
}
The reason prototypes aren't checked at "Here" is because there really isn't
a way to know what the proto
At 10:32 PM 9/3/2001 -0400, Bryan C. Warnock wrote:
>On Monday 03 September 2001 10:27 pm, Dan Sugalski wrote:
> > >To me, that seems only a language decision. This could certainly handle
> > >that.
> >
> > Ah, but calling in the first way has two PMCs in as parameters, while the
> > second has o
On Monday 03 September 2001 10:27 pm, Dan Sugalski wrote:
> >To me, that seems only a language decision. This could certainly handle
> >that.
>
> Ah, but calling in the first way has two PMCs in as parameters, while the
> second has only one. Potentially at least. A world of difference there.
A
At 10:17 PM 9/3/2001 -0400, Bryan C. Warnock wrote:
>On Monday 03 September 2001 09:30 pm, Dan Sugalski wrote:
> > A clever idea, and one I'd not though of. That's probably the best way to
> > do it. Has some other issues, like do we allow prototypes like:
> >
>
On Monday 03 September 2001 09:30 pm, Dan Sugalski wrote:
> A clever idea, and one I'd not though of. That's probably the best way to
> do it. Has some other issues, like do we allow prototypes like:
>
>sub foo ($$) {};
>
> to be called as:
>
>foo(@bar)
At 10:11 PM 9/2/2001 -0400, Bryan C. Warnock wrote:
>On Sunday 02 September 2001 07:49 pm, Dan Sugalski wrote:
> > On Sun, 2 Sep 2001, Bryan C. Warnock wrote:
> > > Are prototypes going to be checked at runtime now?
> >
> > For methods, at least. Dunno about subs
On Sunday 02 September 2001 07:49 pm, Dan Sugalski wrote:
> On Sun, 2 Sep 2001, Bryan C. Warnock wrote:
> > Are prototypes going to be checked at runtime now?
>
> For methods, at least. Dunno about subs, that's Larry's call. I could make
> a good language case for and
On Sun, 2 Sep 2001, Bryan C. Warnock wrote:
> Are prototypes going to be checked at runtime now?
For methods, at least. Dunno about subs, that's Larry's call. I could make
a good language case for and against it. It adds overhead on sub calls,
which is a bad thing generally. (I
On Sunday 02 September 2001 08:18 pm, Michael G Schwern wrote:
> On Sun, Sep 02, 2001 at 07:47:37PM -0400, Bryan C. Warnock wrote:
> > Are prototypes going to be checked at runtime now?
> >
> > The following parses, but doesn't do anything, including warn.
>
On Sun, Sep 02, 2001 at 07:47:37PM -0400, Bryan C. Warnock wrote:
> Are prototypes going to be checked at runtime now?
>
> The following parses, but doesn't do anything, including warn.
>
> my $a = sub ($) { print };
Warning because you said you take an argument and then
Are prototypes going to be checked at runtime now?
The following parses, but doesn't do anything, including warn.
my $a = sub ($) { print };
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Thu, Sep 21, 2000 at 03:38:59AM -0600, Tom Christiansen wrote:
> > > Could the prototype people please report whether Tim Bunce's issues with
> > > prototypes have been intentionally/adequately addressed?
>
> >I'm not a prototype person (in fact RFC
> > Could the prototype people please report whether Tim Bunce's issues with
> > prototypes have been intentionally/adequately addressed?
>I'm not a prototype person (in fact RFC 128 makes it a hanging offence
>to use that confusing word in connection with
2)] }
sub foo ( ($key, \%hash) : repeat{1,} ) {...}
# or:
sub foo ( ($key, HASH $hashref) : repeat{1,} ) {...}
> confess "values must be Frobulants"
>if grep { $_->isa("Frobulant") }, @_[map {1+2*$_} 0.. int($#_/2)] }
sub foo ( (Frobulant $key, $va
yntax for such :-) but what about compile-time versus run-time issues?
Could the prototype people please report whether Tim Bunce's issues with
prototypes have been intentionally/adequately addressed?
--tom
On 16 Sep 2000 22:11:25 -0400, Chaim Frenkel wrote:
>BL>sub min {
>BL>my $min = shift;
>
>
>As I proposed, @_ would flatten the incoming arguments.
>
>But a sub with a prototype (that includes a non-trailing '@') would then
>be able to see the raw arguments.
OK. As long as flattenin
> "BL" == Bart Lateur <[EMAIL PROTECTED]> writes:
BL> I'll give one example.
BL> sub min {
BL> my $min = shift;
As I proposed, @_ would flatten the incoming arguments.
But a sub with a prototype (that includes a non-trailing '@') would then
be able to see the raw arguments.
> Does the prototype help guide the decision that it is a block and not
> an anon-hash?
Yes, as it does now in the existing prototype mechanism. For example:
use Data::Dumper 'Dumper';
sub takes_block (&) { print "takes_block: ", Dumper $_[0] }
sub takes_any
> I'm under the impression that "&" used in a function prototype signifies
> that the function takes a code block.
That's right. As I said in another post, I'm functioning rather poorly
just at the moment. :-(
Damian
On 11 Sep 2000 13:47:22 -0400, Chaim Frenkel wrote:
>Sorry, I don't see list flattening as _fundemental_ to perl. It is
>just the way it is currently done. Could you tell me how it could be
>_fundemental_?
I'll give one example.
sub min {
my $min = shift;
foreach
From: Damian Conway [mailto:[EMAIL PROTECTED]]
>> >> my_while { pred() } { # don't gimme no Tcl flac.
>> >> ...
>> >> } # no semicolon needed here!
>>
>> DC> Just added to the RFC :-)
>>
>> How would the parser handle this? Some '}' would need
> ';' some don't.
>
> Th
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> How would the parser handle this? Some '}' would need ';' some don't.
DC> The trailing C<&> parameter specification tells the parser that there
DC> the last argument will be a raw block and that it need not be a followed
DC> by a semicol
egates without flattening, and without having
to use reference syntax (@$foo), would fall out of Damian's "parameters
once known as prototypes" RFC.
I wonder why not going full LISP with nested lists would be that bad.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
> >> my_while { pred() } { # don't gimme no Tcl flac.
> >> ...
> >> } # no semicolon needed here!
>
> DC> Just added to the RFC :-)
>
> How would the parser handle this? Some '}' would need ';' some don't.
The trailing C<&> parameter specification tells the parser that there
On 10 Sep 2000 00:33:43 -0400, Chaim Frenkel wrote:
>PS> Yes, please. I view the flattening of lists as a feature, not a bug, and
>PS> it has made Perl a lot easier to understand IMHO.
>
>I view it as a mis-feature.
I'm sorry to disagree. But flattening of argument lists is one of those
things
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> my_while { pred() } { # don't gimme no Tcl flac.
>> ...
>> } # no semicolon needed here!
DC> Just added to the RFC :-)
How would the parser handle this? Some '}' would need ';' some don't.
--
Chaim Frenkel
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>> for ($x,$y,$z) (@a1,@a2,4..12,@a4) { ... }
>>
>> Probably we'll have to say that the user must explicitly zip if that
>> is what is desired.
PS> Yes, please. I view the flattening of lists as a feature, not a bug, and
PS> it has made Pe
> Actually this is pretty cool, add a = and turn it into a variable
> declaration:
>
>my format $FORMAT = <<'.';
> @, @
> $stuff, $junk
> .
>
> And that looks pretty similar to Perl 5. ;-)
Yah, but it's frought with the possibility of confusion. I can easily
s
Tom Christiansen wrote:
> format $fh < @, @
> $stuff, $junk
> EO_FORMAT
Actually this is pretty cool, add a = and turn it into a variable
declaration:
my format $FORMAT = <<'.';
@, @
$stuff, $junk
.
And that loo
> > No-one AFAICT has yet brought up formats, and what would happen
> > to them if bareword filehandles go the way of the dodo.
I'm about to propose that formats be replaced with a mechanism of
Text::Autoformat::form (with some extensions).
Damian
>Peter Scott wrote:
>>
>> No-one AFAICT has yet brought up formats, and what would happen to them if
>> bareword filehandles go the way of the dodo.
>Here's some thoughts I've been tooling with. If we take advantage of the
>indirect object syntax, we can actually make format into a member
>funct
Peter Scott wrote:
>
> No-one AFAICT has yet brought up formats, and what would happen to them if
> bareword filehandles go the way of the dodo.
Here's some thoughts I've been tooling with. If we take advantage of the
indirect object syntax, we can actually make format into a member
function:
At 10:19 AM 8/30/00 -0400, Jerrad Pierce wrote:
>Not a huge issue, but I hadn't seen anyone else bring it up.
>If in fact:
> bareword filehandles are ditched
> globs are killed
> prototypes are potentially touched.
>
>perlsub
>su
Not a huge issue, but I hadn't seen anyone else bring it up.
If in fact:
bareword filehandles are ditched
globs are killed
prototypes are potentially touched.
perlsub
sub myopen (*;$) myopen HANDLE, $name
sub mypipe (**) m
> > You know, I would like to pass code blocks in any arg position;
> > I want sub foo(&\@&\@&) to be callable as
> >
> > foo { alpha() } @bravo { charlie() } @delta { echo() };
> >
> > No Cs, no commas.
Already in the RFC.
> And one further note: it would be nice if,
John Porter wrote:
>
> You know, I would like to pass code blocks in any arg position;
> I want sub foo(&\@&\@&) to be callable as
>
> foo { alpha() } @bravo { charlie() } @delta { echo() };
>
> No Cs, no commas.
And one further note: it would be nice if, given a prototype
which does
At 03:24 PM 8/29/00 -0400, John Porter wrote:
>Peter Scott wrote:
> >
> > Yes, please. I view the flattening of lists as a feature, not a bug, and
> > it has made Perl a lot easier to understand IMHO.
>
>So... is an RFC forthcoming? Or shall I?
I mailed an RFC on multiple loop variables in for(
Peter Scott wrote:
>
> Yes, please. I view the flattening of lists as a feature, not a bug, and
> it has made Perl a lot easier to understand IMHO.
So... is an RFC forthcoming? Or shall I?
--
John Porter
We're building the house of the future together.
At 02:57 PM 8/29/00 -0400, John Porter wrote:
>But as for the semantics... how does perl handle this:
>
> for ($x,$y,$z) (@a1,@a2) { ... }
>and
> for ($x,$y,$z) (@a1,@a2,@a3,@a4) { ... }
>
>Making the case where the number of iterators == the number of arrays
>special may not be so
Jonathan Scott Duff wrote:
> I'm wondering how we get both
>
> for ($x,$y,$z) (@array) { ... }
>
> and
>
> for ($x,$y,$z) (@array1,@array2,@array3) { ... }
That's an -internals issue. Suffice it (here) to say that
the parser could be made to handle it. In fact, to the parser,
it'
On Mon, Aug 28, 2000 at 04:04:20PM -0400, John Porter wrote:
> Well, I think it's likely that the perl6 parser would be made to
> handle this; but even if not, it shouldn't be too hard to get it
> to allow a ref to such a list:
>
> for [ $x, $y, $z ] ( @list ) { ...
I'm wondering how we ge
Peter Scott wrote:
>
> for my($x, $y, $z) (@list) { ... }
> ...
> IANAPE (I Am Not A Parsing Expert). So I thought I would see if anyone who
> was could say whether this construct would really give the parser problems
> or whether looking ahead for the block will disambiguate.
Well, I t
79 matches
Mail list logo
