# New Ticket Created by Dan Miller
# Please include the string: [perl #131381]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131381 >
This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53-g66c6dda
implementing
-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
On Wednesday 02 July 2008 10:08:56 NotFound wrote:
> The lexinfo and addregistry pmc uses hash an pmc hash functions
> without access to his prototypes, giving warnings in c build and error
> in c++ build.
>
> This patch fixes the problem.
r28900 removed them, so I added a nice c
his prototypes, giving warnings in c build and error
in c++ build.
This patch fixes the problem.
--
Salu2
Index: src/pmc/addrregistry.pmc
===
--- src/pmc/addrregistry.pmc (revisión: 28958)
+++ src/pmc/addrregistry.pmc (copia de trab
# New Ticket Created by Allison Randal
# Please include the string: [perl #43249]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43249 >
To be removed from the 0.4.14 release (deprecation notice given in 0.4.13).
src/pmc
On Thursday 31 May 2007 07:19:11 Steve Peters wrote:
> Function prototypes in C work much better when they are living in a header
> file rather than in .c files. The attached patch below moves the
> prototypes generated in the src/ops/*.c files to the header files created
> from the
# New Ticket Created by Steve Peters
# Please include the string: [perl #43089]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43089 >
Function prototypes in C work much better when they are living in a header
file rat
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
On Oct 25, 2005, at 23:32, Nick Glencross wrote:
I was looking at callbacks the other evening. Am I right in thinking
that only two callback prototypes are supported, or have I missed a
trick there as well?
That's right. There are 2 callbacks (functions with 2 arguments only),
one wit
Leopold Toetsch via RT wrote:
On Oct 23, 2005, at 17:08, Nick Glencross (via RT) wrote:
Guys,
call_list.txt lists 'T' and 'L' as being prototypes for passing arrays
to nci functions, but no implementation exists in build_nativecall.pl.
This patch provides an implementa
On Oct 23, 2005, at 17:08, Nick Glencross (via RT) wrote:
Guys,
call_list.txt lists 'T' and 'L' as being prototypes for passing arrays
to nci functions, but no implementation exists in build_nativecall.pl.
This patch provides an implementation, as well as new tests.
I d
# New Ticket Created by Nick Glencross
# Please include the string: [perl #37512]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37512 >
Guys,
call_list.txt lists 'T' and 'L' as being prototypes
I couldn't resist start playing with exceptions. So I've put in some
opcodes, 2 new classes - no functionality yet.
Have fun,
leo
At 10:29 PM +0100 8/13/02, Piers Cawley wrote:
>I'd also like to be able to generate parrot code from within parrot
>and immediately execute it...
Working on the specs for that. Should be out soon...
--
Dan
--"it's lik
On Tue, 13 Aug 2002, John Porter wrote:
> Piers Cawley wrote:
> > I'd also like to be able to generate parrot code from within parrot
> > and immediately execute it...
>
> Something like that will be needed for eval() anyway, right?
Yes, like PDB_eval() may be...
Daniel Grunblatt.
Piers Cawley wrote:
> I'd also like to be able to generate parrot code from within parrot
> and immediately execute it...
Something like that will be needed for eval() anyway, right?
--
John Douglas Porter
On 13 Aug 2002, Piers Cawley wrote:
> Melvin Smith <[EMAIL PROTECTED]> writes:
>
> > At 06:56 PM 8/12/2002 +0100, Simon Cozens wrote:
> > >Here's a more interesting question: which parts of Parrot are
> > >enshrined, and which are prototypes, ready to b
At 11:10 PM -0400 8/12/02, Melvin Smith wrote:
>At 06:56 PM 8/12/2002 +0100, Simon Cozens wrote:
>>Here's a more interesting question: which parts of Parrot are enshrined,
>>and which are prototypes, ready to be thrown away? For instance, I'd
>>say much of lang
ut really bad masters.
>
>Here's a more interesting question: which parts of Parrot are enshrined,
>and which are prototypes, ready to be thrown away? For instance, I'd
>say much of languages/* is all proof-of-concept prototype stuff; imcc
>may not be. The assembler I'd cal
At 06:56 PM 8/12/2002 +0100, Simon Cozens wrote:
>Here's a more interesting question: which parts of Parrot are enshrined,
>and which are prototypes, ready to be thrown away? For instance, I'd
>say much of languages/* is all proof-of-concept prototype stuff; imcc
>may not
On 12 Aug 2002, Simon Cozens wrote:
> [EMAIL PROTECTED] (Daniel Grunblatt) writes:
> > Oh, no, I was talking about languages/parrot_compiler/. Sorry.
>
> Oh, I hadn't seen that. I can't work out what it is; it seems to be a
> device for generating "Couldn't find operator" errors. Is there any,
>
[EMAIL PROTECTED] (Daniel Grunblatt) writes:
> Oh, no, I was talking about languages/parrot_compiler/. Sorry.
Oh, I hadn't seen that. I can't work out what it is; it seems to be a
device for generating "Couldn't find operator" errors. Is there any,
dare I say it, documentation for it?
--
Going
On 12 Aug 2002, Simon Cozens wrote:
> [EMAIL PROTECTED] (Daniel Grunblatt) writes:
> > The assembler is a bit outdated, it shouldn't be too difficult to bring it
> > up to date, I just don't have enough time latetly. But it did work fine
> > and is easy to extend it. Why do you think it should be
[EMAIL PROTECTED] (Daniel Grunblatt) writes:
> The assembler is a bit outdated, it shouldn't be too difficult to bring it
> up to date, I just don't have enough time latetly. But it did work fine
> and is easy to extend it. Why do you think it should be thrown away?
It's in Perl?
--
MISTAKES:
On 12 Aug 2002, Simon Cozens wrote:
> Here's a more interesting question: which parts of Parrot are enshrined,
> and which are prototypes, ready to be thrown away? For instance, I'd
> say much of languages/* is all proof-of-concept prototype stuff; imcc
> may not be. Th
ch parts of Parrot are enshrined,
and which are prototypes, ready to be thrown away? For instance, I'd
say much of languages/* is all proof-of-concept prototype stuff; imcc
may not be. The assembler I'd call a prototype. The regex engine? The
GC? ...
--
10. The Earth quakes and the heavens
This quiets a few more gcc warnings. (I've already applied it.)
diff -r -u parrot-cvs/classes/pmc2c.pl parrot-andy/classes/pmc2c.pl
--- parrot-cvs/classes/pmc2c.pl Mon Jan 21 20:04:53 2002
+++ parrot-andy/classes/pmc2c.plTue Jan 22 11:43:10 2002
@@ -249,6 +249,9 @@
unless (exists $fla
At 02:33 PM 1/1/2002 -0500, Josh Wilmes wrote:
>I don't know if these functions might be obsolete, but here's a
>simple patch to add the missing prototypes if they are not.
Applied, thanks.
Dan
-
I don't know if these functions might be obsolete, but here's a
simple patch to add the missing prototypes if they are not.
Fixes this warning:
register.c:429: warning: no previous prototype for `Parrot_push_on_stack'
register.c:436: warning: no previous prototype for `Parro
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]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow keywords in sub prototypes
=head1 VERSION
Maintainer: Simon Cozens <[EMAIL PROTECTED]>
Date: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 309
Version: 1
Status: Developing
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Make subroutines' prototypes accessible from Perl
=head1 VERSION
Maintainer: Simon Cozens <[EMAIL PROTECTED]>
Date: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 298
Version:
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
Adam Turoff <[EMAIL PROTECTED]> writes:
> On Tue, Sep 19, 2000 at 08:47:11AM +0100, Piers Cawley wrote:
> > > That *shouldn't* be hard. If you're getting hung up on details like
> > > =over 4, =item, L<> and C<>, then leave them out.
> >
> > No, I'm getting hung up on the fact that it'll take
On Tue, Sep 19, 2000 at 08:47:11AM +0100, Piers Cawley wrote:
> > That *shouldn't* be hard. If you're getting hung up on details like
> > =over 4, =item, L<> and C<>, then leave them out.
>
> No, I'm getting hung up on the fact that it'll take a bunch of time to
> flesh out the RFCs beyond a s
Adam Turoff <[EMAIL PROTECTED]> writes:
> On Mon, Sep 18, 2000 at 10:18:41AM -0600, Nathan Torkington wrote:
> > Piers Cawley writes:
> > > The idea here is to allow people to get ideas on the lists in a rough
> > > form where they can get some initial comments (which may blow the
> > > 'real' RF
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
On Mon, Sep 18, 2000 at 10:18:41AM -0600, Nathan Torkington wrote:
> Piers Cawley writes:
> > The idea here is to allow people to get ideas on the lists in a rough
> > form where they can get some initial comments (which may blow the
> > 'real' RFC out of the water...). There should be some very s
Piers Cawley writes:
> The idea here is to allow people to get ideas on the lists in a rough
> form where they can get some initial comments (which may blow the
> 'real' RFC out of the water...). There should be some very strict
> rules about how soon the 'real' RFC arrives though.
Why do you nee
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
With the deadline for new RFCs fast approaching I've got a couple or
three RFCs that I won't have time to get properly written in the time
available, and I'm sure I'm not alone.
Therefore, I propose that we be allowed to submit RFC prototypes of
the form:
=head1 TITLE
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
1 - 100 of 115 matches
Mail list logo
