On Thu, Dec 20, 2007 at 11:35:44AM -0600, Jonathan Scott Duff wrote:
> On Thu, Dec 20, 2007 at 11:23:05AM -0600, Jonathan Scott Duff wrote:
> > Adriano answered #1 I think: $yaml = Q:!c"{ $key: 42 }";
>
> Er, I just looked over the spec again and realized that Q does
> absolutely no interpolation
On Sat, Jan 27, 2007 at 10:23:03AM +0100, Carl Mäsak wrote:
> my $foo;
> # ...later in the same scope...
> my $foo; # illegal Perl5, legal Perl6
No, that's perfectly legal in perl5; it just generates a warning:
use warnings;
my $x = 1;
my $f1 = sub { $x };
my $x = 2;
my $f2
On Wed, Nov 15, 2006 at 11:17:57PM +, Nicholas Clark wrote:
> I thought that allowing undef in my ($a, undef, $b) came in around 5.004ish,
> but I can't find it in perldelta, and I don't have a version compiled to
> test with (or any quick way to compile them, given that pretty much only
> AIX
On Tue, Oct 18, 2005 at 11:06:22AM +0100, Nicholas Clark wrote:
> Likewise. A certain reputable OS vendor's NFS implementation went
> multithreaded, with the result that close() was now where the over quota
> error was reported, rather than the individual writes.
>
> Said reputable OS vendor's own
On Fri, Oct 07, 2005 at 03:46:02PM -0600, Luke Palmer wrote:
> Uh no. Okay, when I said that they "don't close", I guess I meant
> they don't close like anonymous routines do. It works precisely like
> Perl 5's:
>
> sub foo {
> my $foo = 5;
> sub bar {
> return $f
On Sun, Jun 12, 2005 at 06:22:22PM -0500, Rod Adams wrote:
> Well, you could always do something like:
>
>sub foo { my $x = 1; return sub {my $x := $OUTER::x; eval $^codestring} }
In perl5, that would just be
sub foo { my $x = 1; return sub { $x ; eval $_[0]} }
--
You live and learn (a
On Sun, Jun 12, 2005 at 11:26:49PM +0100, Piers Cawley wrote:
> Chip and I have been having a discussion. I want to write:
>
> sub foo { my $x = 1; return sub { eval $^codestring } }
> say foo()("$x");
>
> I claim that that should print 1. Chip claims it should throw a warning
> about bec
On Thu, May 12, 2005 at 09:06:48PM +0100, Benjamin Smith wrote:
> sub foo { my $x; BEGIN { $x = 3 }; say $x }
> foo; foo; foo;
>
> Currently in perl5 and pugs this prints "3\n\n\n".
>
> Should BEGIN blocks be able to modify values in lexical variables that
> don't really exist yet? (People ca
On Wed, Jul 21, 2004 at 04:37:29PM -0700, Larry Wall wrote:
> We allowed/required @foo to interpolate in Perl 5, and it catches a
> certain number of people off guard regularly, including yours truly.
> So I can argue [EMAIL PROTECTED] both ways.
Currently @foo[] is a syntax error. maybe "@foo[]"
On Sat, Jul 17, 2004 at 06:53:28PM +0200, Juerd wrote:
> If an array element knows that it is an array element, this can be
> useful:
>
> for @foo { push @bar, .splice if EXPR }
What happens if the element is an element of more than one array?
--
A power surge on the Bridge is rapidly and c
If hypothetically we *are* going to have a simplfied constant-index hash
access syntax, is there any reason why we can't use a single quote (')
rather than backtick ('), akin to the Perl4-ish package separator,
ie %foo'bar rather than %foo`bar?
On the grounds that personally I hate the backtick
On Sat, Mar 06, 2004 at 06:39:44PM -0800, Larry Wall wrote:
> my @x will begin {...} # at BEGIN time
> my @x will check {...} # at CHECK time (redefined to unit check)
> my @x will init {...} # at INIT time
> my @x will end {...}# at END time
Sorry, perhaps
Did I miss something? Was there ever an apocalyse 7?
Also, why aren't the apocalyses and excegises announced on any of the p6
lists (like, er, perl6-announce for example)?
Yours grumpily,
Dave.
--
My get-up-and-go just got up and went.
On Wed, Jan 21, 2004 at 04:01:43PM -0500, Austin Hastings wrote:
> Perhaps the right way to vectorize the arguments is to delimit them with
> vectorization markers?
>
> @a + >>$b<<
or @a + @$b even!
--
Justice is when you get what you deserve.
Law is when you get what you pay for.
On Thu, Oct 16, 2003 at 01:46:30AM +0100, Simon Cozens wrote:
> [EMAIL PROTECTED] (Larry Wall) writes:
> > But for the time being I'm tied to an IV pole
>
> We got rid of those; they're PMC poles now.
>
> Get well soon,
Ditto!
Dave.
--
Little fly, thy summer's play my thoughtless hand has
ter
On Thu, Oct 02, 2003 at 04:15:06AM -0600, Luke Palmer wrote:
> And to clarify:
>
> sub indexof(Selector $which, [EMAIL PROTECTED]) {
> for zip(@data, 0...) -> $_, $index {
> when $which { return $index }
> }
> }
>
> Which actually creates a closure (well, in th
On Wed, May 28, 2003 at 07:58:37AM -0700, Austin Hastings wrote:
> On a single-CPU box, the OS level threads could easily be used to
> support blocking operations feeding back to async I/O, while all "real
> work" (execution of opcodes) was done in a single thread. Parrot could
> elect to implement
On Tue, May 27, 2003 at 02:05:57PM -0700, Michael Lazzaro wrote:
> If we could think about "threads" not in terms of forkyness, but simply
> in terms of coroutines that can be called in parallel, it should be
> possible to create an implementation of "threading" that had to do a
> whole heck-of-
On Tue, Apr 01, 2003 at 08:44:25AM -0500, Dan Sugalski wrote:
> There isn't any, particularly. We're doing preemptive threads. It
> isn't up for negotiation. This is one of the few things where I truly
> don't care what people's opinions on the matter are.
Sorry, I haven't been following this to
On Tue, Feb 18, 2003 at 10:06:29PM -, Smylers wrote:
> More practically, the length of a list is never interesting: a list by
> definition must be hardcoded into the program so its length is known at
> compile time. Indeed it should be known by whoever typed it in!
Err, no. Eg in perl 5:
On Mon, Feb 03, 2003 at 06:25:09AM -0800, Austin Hastings wrote:
> The only time this doesn't change type (arguably a bad thing in its own
> right) is when you're doing boolean ops. And for those, there exist
> boolean operators.
Changing type is a very Perlish thing to do.
> > How 'bout a shortc
On Fri, Jan 31, 2003 at 05:59:46PM +0100, Leopold Toetsch wrote:
> A lvalue param is not strictly reading, but here has to happen something
> differently - yes:
>
> IMHO some sort of proxy could be passed here, saying: "if you write to
> me, this will be at @a[0]". Or auto-vivify the entry.
Thi
On Tue, Oct 29, 2002 at 02:55:57PM -0500, Uri Guttman wrote:
>
> damian's syntax table and his use of the term vectorizing made me wonder
> why we call his [op] thing a hyperoperator? the word hyper i assume came
> from hyperdimensional. but calling [] the vectorizing (or just vectored)
> op varia
On Wed, Oct 30, 2002 at 06:51:14AM +1100, Damian Conway wrote:
> String complement treats the value as a string then bitwise complements every
> bit of each character.
Is that the complement of the codepoint or the individual bytes?
(I'm thinking utf8 here).
--
Nothing ventured, nothing lost.
On Fri, Oct 25, 2002 at 11:27:54AM -0700, Michael Lazzaro wrote:
> &&||!!//- boolean operations
> &&= ||= !!= //=
> and orxor
Hmmm, given Larry's comments just now about about similar things not
looking similar, I really think | vs ! is a mistake. Fr
On Thu, Aug 01, 2002 at 06:17:11PM -0400, Uri Guttman wrote:
> do these instead:
>
> $bool += 0 ;
> ($x == $y) + 0
or even
$x == $y || 0
--
Never do today what you can put off till tomorrow.
On Thu, Aug 01, 2002 at 06:02:14PM -0400, Miko O'Sullivan wrote:
> It would be really groovy if that expression could be split with the
> delimiters in place, something like this:
>
>@tokens = split _/[?=*-+]/, $sql, keep=>'all';
>
> and get back an array with these values: ('rank', '=', '?'
On Thu, Jul 11, 2002 at 10:37:27PM +0100, Nicholas Clark wrote:
> Is there any specific case where you can't treat
>
> {
> my $foo = 12;
> print $foo;
> my $foo = "ho";
> print $foo;
> }
>
> as
>
> {
> my $foo = 12;
> print $foo;
> {
> my $foo = "ho";
> print $foo;
> }
>
On Thu, Jul 11, 2002 at 02:29:08PM -0400, Dan Sugalski wrote:
> At 7:18 PM +0100 7/11/02, Dave Mitchell wrote:
> >On Thu, Jul 11, 2002 at 10:41:20AM -0400, Dan Sugalski wrote:
> >> The place where you'll run into problems in where you have multiple
> >> variab
On Wed, Jul 10, 2002 at 11:57:02PM -0400, Chip Salzenberg wrote:
> According to Dave Mitchell:
> > Based on what I rememeber from the long threads about this,
>
> Ouch. I gather, then, that nntp.perl.org does not house complete list
> archives, or else the discussion was
On Thu, Jul 11, 2002 at 10:41:20AM -0400, Dan Sugalski wrote:
> The place where you'll run into problems in where you have multiple
> variables of the same name at the same level, which you can do in
> perl 5.
can it?
can you give an example?
--
In England there is a special word which means
On Tue, Jul 09, 2002 at 09:50:26PM -0400, Chip Salzenberg wrote:
Based on what I rememeber from the long threads about this,
>3. Is C<%MY> intended to reflect the PAD?
loosely speaking yes.
>
> 3a. If so, how can one distinguish among the e.g. many C
> variables declared within
On Wed, Jul 03, 2002 at 01:23:24PM -0400, Michael G Schwern wrote:
> Hopefully the Cabal [2] can debunk that.
[snip]
> [2] Of which there is none.
and http://www.perlcabal.com/ doesn't exist, right? ;-)
--
"I do not resent critisism, even when, for the sake of emphasis,
it parts for the time w
On Tue, Jun 04, 2002 at 10:43:02AM +0100, Simon Cozens wrote:
> (Please CC me on replies)
>
> I don't often express many opinions on Perl 6 these days, but I feel I have to
> warn people about what I see as a potential loss of direction.
>
> I'm becoming somewhat disillusioned with Perl 6 these
On Thu, May 02, 2002 at 02:33:42PM -0600, Jim Cromie wrote:
>
> with p5, Ive often written
>
> eval {} or carp "$@ blah";
You generally Don't Want To Do That.
If the eval succeeds, but the last statement in the eval happens to come
out as false, then it'll still carp:
$a = 0; eval { 1 < $a
In the true sprirt of perverseness, why not make loops into functions that
return the number of iterations taken. Then you can have
loop {
}
or die "loop not taken\n";
;-)
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999
On Wed, Apr 17, 2002 at 01:58:05PM -0700, David Wheeler wrote:
> On 4/17/02 1:51 PM, "Dave Mitchell" <[EMAIL PROTECTED]> claimed:
>
> > I hope you're referring to 5.8.x for some x != 0 ??? :-)
>
> Do you know how late in the development process the $code
On Wed, Apr 17, 2002 at 01:09:43PM -0700, David Wheeler wrote:
> Anyone know what the chances are that some enterprising C hacker
> can/will/did get the // and //= operator into Perl 5.8? Seems like it
> wouldn't be a huge deal to add, and I'd love to have it sooner rather than
> later.
I hope yo
On Tue, Apr 16, 2002 at 06:17:24PM -0700, David Wheeler wrote:
> In Exegesis 4, Damian writes:
>
>
> It's important to note that writing:
>
>
> for @a; @b -> $x; $y {...}
> # in parallel, iterate @a one-at-a-time as $x, and @b one-at-a-time as
> $y
>
> is not the same as writing:
>
>
On Sat, Apr 13, 2002 at 05:07:37PM -0700, Larry Wall wrote:
> Of course, one of the big reasons we went with $self was the pun:
>
> my $self = shift;
>
> which we won't have now. Unless we always hide the invocant and
> force you to say
>
> my $self = invocant;
>
> or some such mummer
On Wed, Apr 10, 2002 at 05:47:01PM -0500, Allison Randal wrote:
> I'm in favor of the standardized variable name. It is a restriction, but
> not an onerous one. I've never used anything but $self, and I'm sure it
> would be easy to adapt to whatever else was chosen. Are there any
> statistics avai
> What I don't want to start (and I may have done so anyway) is a simple
> name war. If you feel emotionally attached to "Perl", then fine, so am
> I. But if you feel that there is some compelling logic here that will
> affect the community, I would be very interested.
The reason why it's still
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > If it's an outer-scope lexical, use C{MY}>
>
> Ok, I'm all over the nice new features of Perl6, but darnit,
> "upvar" is one of the primary reasons that TCL is unusable. Please,
> let's not soften the walls of lexical scope. They're there for a
> reaso
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> On Thursday 06 September 2001 08:53 am, Dave Mitchell wrote:
> > But surely %MY:: allows you to access/manipulate variables that are in
> > scope, not just variables are defined in the current scope, ie
> >
>
Here's a list of what any Perl 6 implementation of lexicals must be able to
cope with (barring additions from future apocalyses). Can anyone think of
anything else?
>From Perl 5:
* multiple instances of the same variable name within different scopes
of the same sub
* The notion of intr
"Bryan C. Warnock" <[EMAIL PROTECTED]> mused:
> Consider it like, oh, PATH and executables:
> `perl` will search PATH and execute the first perl found, but 'rm perl' will
> not. It would only remove a perl in my current scope..., er, directory.
But surely %MY:: allows you to access/manipulate v
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> On Thursday 06 September 2001 06:16 am, Dave Mitchell wrote:
> > One further worry of mine concerns the action of %MY:: on unintroduced
> > variables (especially the action of delete).
> >
> > my $x = 100
One further worry of mine concerns the action of %MY:: on unintroduced
variables (especially the action of delete).
my $x = 100;
{
my $x = (%MY::{'$x'} = \200, $x+1);
print "inner=$x, ";
}
print "outer=$x";
I'm guessing this prints inner=201, outer=200
As for
my $x = 50;
{
my $x =
Dan Sugalski <[EMAIL PROTECTED]> wrote
> >my $x = 1;
> >{
> > my $x = 2;
> > delete $MY::{'$x'};
> > print $x;
> > $mysub = sub {$x};
> >}
> >
> >print $mysub->();
> >
> >People seem agreed that print $x should do the equivalent of
> > throw "lexical '$x' no longer in scope
can I just clarify something about delete:
my $x = 1;
{
my $x = 2;
delete $MY::{'$x'};
print $x;
$mysub = sub {$x};
}
print $mysub->();
People seem agreed that print $x should do the equivalent of
throw "lexical '$x' no longer in scope"
rather than printing 1, but what s
Garrett Goebel <[EMAIL PROTECTED]> wrote
> From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> > sub Foo::import {
> > my %m = caller(1).{MY}; # or whatever
> > %m{'$x'} = 1;
> > }
...
> > sub f {
> > my $x = 9;
> >
If there is to be a %MY, how does its semantics pan out?
for example, what (if anything) do the following do:
sub Foo::import {
my %m = caller(1).{MY}; # or whatever
%m{'$x'} = 1;
}
sub Bar::import {
my %m = caller(1).{MY}; # or whatever
delete %m{'$x'};
}
sub f {
my $x =
Ken Fox <[EMAIL PROTECTED]> wrote:
> You really need to learn what a closure is. There's a very nice book
> called "Structure and Interpretation of Computer Programs" that can
> give you a deep understanding. **
Quite possibly I do. Anyway, I've now got the book on order :-)
> You're speaking in
Ken Fox <[EMAIL PROTECTED]> wrote:
> We must be very careful not to confuse "closure" with "Perl's
> current implementation of closure". You've stumbled onto a bug in
> Perl, not discovered a feature of closures. Perl's "closures"
> were horribly buggy until release 5.004. (Thanks Chip!)
Er, no i
John Porter <[EMAIL PROTECTED]> wrote:
> Dave Mitchell wrote:
> > I think closures are a lot harder (or at least subtler) than people
> > think,
>
> It's hard for me to agree with you, because I've never had *any*
> problems with closures. (And yes, I us
Paul Johnson <[EMAIL PROTECTED]> wrote:
> Try changing your original example from
>
> sub foo {
>
> to
>
> *foo = sub {
>
> and you'll see that everything works "as expected".
add a BEGIN so that instantion happens at the same time that a named
sub would be:
BEGIN { * foo = sub { } }
> I guess you missed where I suggested that putting "my" on that
> declaration is also counter-sensical, not to mention redundant.
> "my" implies a brand-spanking-new lexical variable attached
> to this very scope. The semantics of "outer" (or "closed"...)
> can be defined to imply a lexical var
Paul Johnson <[EMAIL PROTECTED]> wrote:
> Actually, foo() is not a closure. A closure is an anonymous subroutine
> and foo() clearly has a name.
Damain's definition of a closure includes named subs:
"In Perl, a closure is just a subroutine that refers to one or more lexical
variables declared o
Piers Cawley <[EMAIL PROTECTED]> wrote:
> > {
> > my $x = "bar";
> > sub foo {
> > # $x # <- uncommenting this line changes the outcome
> > return sub {$x};
> > }
> > }
> > print foo()->();
>
> Well, I would expect it to output 'foo' on both occasions, and I'm
> more than a l
Just thought I'd run the following up the flagpole to see if anyone
laughs at it
Closures are useful, powerful things, but they can also be
dangerous and counter-intuitive, espcially to the uninitiated. For example,
how many people could say what the following should output,
with and without
Damian Conway <[EMAIL PROTECTED]> wrote:
>> There are a number of properties "built into" Perl 6. Nearly all of these
>> properties don't make sense across the board - eg, a scalar won't have a
>> dimension, a hash won't prompt, etc.
>>
>> So given the two different sets that y
> Out of morbid curiosity (since I'm working on documentation), given the
> program that the following program generates:
>
> #!/your/path/to/perl -w# perl 5.6.1
> my @l = ('a' .. 'g');
> my $my = 0;
>
> for my $v (@l) {
>my @a = map { "\$$v .= '$_'" } @l;
>$a[$my++] = "my $a[$my]"
Damian Conway <[EMAIL PROTECTED]> wrote
>> > >my $a is true = 0; # variable property
>> > >my $a = 0 is true; # variable property
>> > >my ($a) = 0 is true;# value property
>> >
>> > Wow. Totally ETOOCONFUSING.
>
> Briefly: We want the Perl 6 runtime to be an equivalent of the Microsoft
> CLR, so that if you can somehow get bytecode onto it - from whatever
> language - you can run it. So we've got some bytecode that perl can run.
> Now think about what B::Deparse does.
I knew the intention was to go the
Just a quick obeservation:
Given the radicalness of the changes suggested by apo 2, I think it's
fair to say that the proportion of Perl 5 code that will run unchanged
on a Perl 6 interpreter will be heading into single-figure percentages.
While I personally think this will be price well worth pa
And there was me thinking the shiny ball must be a camel dropping
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> Somewhat tangentially: this reminds me of a message a week ago or so
> (can't find it anymore in my inbox) which proposed writing C (or C++)
> code for Perl 6 so that "modern CPU architectures are happy" (no
> pipeline stalls because of "if"-s, etc.)
67 matches
Mail list logo
