Re: Concerns about {...code...}
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, so it would be more like this:
$yaml = Q:qq:!c{ $key: 42 };
or perhaps
$yaml = qq:!c{ $key: 42 };
To me they look like abominations. Is there any pressing need to have code
interpolate, other than for simple convenience?
--
You may not work around any technical limitations in the software
-- Windows Vista license
Re: Remember: Outlaw to declare a lexical twice in the same scope
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 = sub { $x };
printf f1=%d f2=%d x=%d\n, $f1-(), $f2-(), $x;
which gives
$ perl588 /tmp/p
my variable $x masks earlier declaration in same scope at /tmp/p line 6.
f1=1 f2=2 x=2
--
But Pity stayed his hand. It's a pity I've run out of bullets,
he thought. -- Bored of the Rings
Re: List assignment question
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 is so stable that early perls compile unmodified. Probably someone will tell me that VMS is also good enough, for 5.002 or later) $ perl-5322 -we'my ($x,undef,$y) = 1..3' Can't declare undef operator in my at -e line 1, near ) = Execution of -e aborted due to compilation errors. $ perl545 -we'my ($x,undef,$y) = 1..3' $ -- There's something wrong with our bloody ships today, Chatfield. -- Admiral Beatty at the Battle of Jutland, 31st May 1916.
Re: $value but lexically ...
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 $foo;
}
return \bar;
}
I don't think I've ever seen that used in Perl 5. Closing over that
$foo doesn't mean anything.
Well strictly speaking it means that bar() captures the first instance of
foo()'s $foo, which isn't often very useful.
--
The Enterprise successfully ferries an alien VIP from one place to another
without serious incident.
-- Things That Never Happen in Star Trek #7
Re: How much do we close over?
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 because of timely destruction. My claim is that a closure should
close over the entire lexical stack, and not simply those things it uses
statically. Chip claims the opposite, arguing that timely destruction
implies that this is absolutely the right thing to do. It's also
quicker.
I'm with Chip on this one. In fact, year ago I specifically fixed
bleedperl so that it gives this runtime warning:
$ perl592 -we 'sub f { my $x; sub { eval q($x)} } f()-()'
Variable $x is not available at (eval 1) line 2.
But dammit, I'm doing runtime evaluation of code strings, I don't care about
quicker.
You may be using slow evals, but other fast code may not be. Should the
closure in
sub foo { my $x = 1; return sub { 1 } }
also capture the current instance of $x? You are basically condeming any
code that creates any closure, however simple, to basically hang on to
just about any data that has ever existed, in the vague hope that maybe,
just maybe, some day some code may use an eval and make use of that data.
If it's not the default can it please be mandated that there be some way of
doing:
sub foo { my $x = 1; return sub is lexically_greedy {eval $^codestring} }
in other words, some way of declaring that a subroutine wants to hang onto
every lexical it can see in its lexical stack, not matter what static analysis
may say.
I have no opinion on that.
--
This is a great day for France!
-- Nixon at Charles De Gaulle's funeral
Re: How much do we close over?
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 (although usually you just live).
Re: BEGIN and lexical variables inside subroutines
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 can use state after all to get a
variable which does exist early enough for them to modify.)
Is there some kind of prototype pad (and lexicals) available inside
the BEGIN block, rather than a full runtime pad?
In perl5, the first instance of a lexical exists from the moment of
compilation through till first exit from the enclosing scope during
exection. If this wasn't the case then lots of closure-related stuff
wouldn't work, eg
{
my $count = 0;
sub inc { $count++ }
sub dec { $count-- }
}
...
--
print+qq$}$$/$s$,[EMAIL PROTECTED],$:$.$q$^$,[EMAIL
PROTECTED];$.$q$mif+map{m,^\d{0\,},,${$::{$'}}=chr($+=$||1)}q10m22,42}6:[EMAIL
PROTECTED];^2dg3q/s=~m*\d\*.*g
Re: String interpolation
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[] in Perl6 could be what @foo is in Perl5? And I mean a literal '[]', not @foo[expression-that-returns-an-empty-list] Dave -- You never really learn to swear until you learn to drive.
Re: backticks
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 :-)
--
That he said that that that that is is is debatable, is debatable.
Re: Magic blocks (was: Compile-time undefined sub detection)
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 I wasn't paying close enough attention, but suddenly we've
leaped from oddly named subs that get called at interesting times, to
array variables with oddly-named properties (or attributes, or whatever).
Je ne comprend pas :-(.
Dave.
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.
Whither Apocalypse 7?
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.
Re: The Block Returns
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 terminated with extreme prejudice. (with apologies to William Blake)
Re: The Block Returns
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 theory at least) on line 2
for the for loop, but the return inside of it returns from indexof.
Which is actually very, very nice.
So the question is: What happens when indexof isn't on the call chain,
but that inner closure is?
But how can the inner closure be called if not via indexof?
--
To collect all the latest movies, simply place an unprotected ftp server
on the Internet, and wait for the disk to fill
Re: Cothreads
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 threading on its own. In fact, if consistency of execution is a design objective, it probably should. And on a multiple CPU box...? -- Never do today what you can put off till tomorrow.
Re: Cothreads
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-a-lot less duplication of state, etc. Things outside the scope of the thread group would automatically be shared(?), things inside the thread group would not be shared unless explicitly marked as such. Which, if I read it right, is what you proposed too, but with a slightly different syntax. That _might_ make threads a heck of a lot faster upon creation/startup, and a lot less bulky in general. But underneath, these pretty coroutiney/virtual-threads still have to to be implemented in terms of the underlying OS's real threads, so parrot will have to start being really clever applying locks and mutexes all over the place to all those outer bits that are shared etc. So while you may get a cleaner high-level interface to threading behaviour, I don't think you're gonna gain speed and or bulkiness. But I could be wrong. Stranger things have been known :-) -- Blaming Islam for 911 is like blaming Christianity for Oklahoma City.
Re: How shall threads work in P6?
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 too closely - but is it the intention to support the 5.005, or the ithreads model (or both? or neither?). -- To collect all the latest movies, simply place an unprotected ftp server on the Internet, and wait for the disk to fill
Re: Arrays, lists, referencing
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: $value = (1,2, @ARGV,3,4)[$i] That's a list, and its length is not known at compile time. Dave. -- Nothing ventured, nothing lost.
Re: Shortcut: ?=
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 shortcut for that, something like this: $var ?= 1 : 0; Isn't this the same as C$var = 1; ? No for example, maps to 0. A better example: $var ??= 'succeeded' :: 'failed'; -- You're so sadly neglected, and often ignored. A poor second to Belgium, When going abroad. Monty Python - Finland
Re: Arrays: Default Values
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.
This is what Perl 5 does at the moment:
$ perl5.8.0 -MDevel::Peek -e 'sub f{Dump($_[0])}; f($a[9])'
SV = PVLV(0x8177118) at 0x8166a74
REFCNT = 1
FLAGS = (GMG,SMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x816e7e0
MG_VIRTUAL = PL_vtbl_defelem
MG_TYPE = PERL_MAGIC_defelem(y)
TYPE = y
TARGOFF = 9
TARGLEN = 1
TARG = 0x817ad88
SV = PVAV(0x8183bd4) at 0x817ad88
REFCNT = 2
FLAGS = ()
IV = 0
NV = 0
ARRAY = 0x0
FILL = -1
MAX = -1
ARYLEN = 0x0
FLAGS = (REAL)
However, I think this is clumsy and overly complex; since Perl6 allows us
to declare parameters rw or whatever, I think it should always autovivify
unless we know the param is read-only (or in-only, or whatever the correct
terminology is).
--
There's something wrong with our bloody ships today, Chatfield.
Admiral Beatty at the Battle of Jutland, 31st May 1916.
Re: Perl6 Operator List, Damian's take
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.
Re: vector vs. hyper
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 variant makes much more sense.
I vote for 'vector' too. I also really like the [] idea.
--
print+qq$}$$/$s$,$*${$}$g$s$$.$q$,$:$.$q$^$,$$*$~$;$.$q$mif+map{m,^\d{0\,},,${$::{$'}}=chr($+=$||1)}q10m22,42}6:17*2~2.33;^2$g3q/s=~m*\d\*.*g
Re: Perl6 Operator List
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. From a distance, (14 inches in my case), they really do look almost indistinguable. (IMHO) -- Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony. Dennis - Monty Python and the Holy Grail.
Re: perl6-language@perl.org
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', '=', '?')
But that raises a problem: what if the expression is this (note the spaces):
rank = ?
In that case I would want the = and ? but I wouldn't want the spaces. A
slightly different option could keep just stuff in parens:
tokens = split _/\s*([?=*-+])\s*/, $sql, keep='parens';
But perl5 already does this:
$ perl -le 'print join |, split /\s*([?=*-+])\s*/, rank = ?'
rank|=||?
$
Dave.
--
You live and learn (although usually you just live).
Re: perl6-language@perl.org
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.
Re: What's MY.line?
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 the last sunshine of the summer. That word is spring.
Re: What's MY.line?
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 not on p6-language ... ? don't know about nntp, but see for example, http:[EMAIL PROTECTED]/msg08203.html -- You live and learn (although usually you just live).
Re: What's MY.line?
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 variables of the same name at the same level, which you can do in perl 5. can it? Yes. can you give an example? [localhost:~] dan% perl my $foo = 12; print $foo; my $foo = ho; print $foo; 12ho[localhost:~] dan% ah, I see what you mean. I hope that'll be a syntax error rather than just a warning in perl6. -- Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony. Dennis - Monty Python and the Holy Grail.
Re: What's MY.line?
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;
}
}
Well, it B*gg*rs up %MY::
The currently planned semantics are:
{
my $x;
exists %MY::{'$x'}; # true;
}
and
{
my $x;
{
exists %MY::{'$x'}; # false
}
}
so consider:
{
my $x;
my $dup;
my $dup;
exists %MY::{'$x'}; # true?
}
which invisibly becomes
{
my $x;
my $dup;
{
my $dup;
exists %MY::{'$x'}; # false?
}
}
--
But Sidley Park is already a picture, and a most amiable picture too.
The slopes are green and gentle. The trees are companionably grouped at
intervals that show them to advantage. The rill is a serpentine ribbon
unwound from the lake peaceably contained by meadows on which the right
amount of sheep are tastefully arranged. Lady Croom - Arcadia
Re: What's MY.line?
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 Cmy $foo
variables declared within the current function?
It was decreed that %MY only sees stuff in the inner-most lexical scope
(so the Perl6 version of a pad is 'bigger' than what %MY sees):
{
my $x = 1;
{
exists %MY::{'$x'}; # false
print %MY::{'$x'}; # undef
print $x; # 1
%MY{'$x'} = 2;
print %MY::{'$x'}; # 2
print $x; # 2
{
exists %MY::{'$x'}; # false
print %MY::{'$x'}; # undef
print $x; # 2
}
}
exists %MY::{'$x'}; # true
print %MY::{'$x'}; # 1
print $x; # 1
}
3b. If not, how are lexical adjustments to C%MY unwound? Or are
they? If they're not, I can actually see the idea that could be
part of the base utility of C%MY.
I think the main intent of %MY:: is to allow import() to lexically affect
the caller, ie
sub import {
caller(1).MY{'foo'} = sub { ... };
}
(for some vague handwaving interpretation of caller() and MY)
Dave.
--
My get-up-and-go just got up and went.
Re: Perl 6, The Good Parts Version
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 with reality. Winston Churchill, House of Commons, 22nd Jan 1941.
Re: Half measures all round
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 days; sometimes because it's too radical, more often than not because it's not radical enough, and quite often because it's more than a year behind schedule and still slipping. But that last point is by the by; with three people now working full-time on it, I'm sure we can expect it any day now. What's really actually letting me down with it is the half-measures we're applying. We seem to be trying to please everyone, and it's not going to work; indeed, it's going to end up presenting a burden to the implementors. Let's take an example. One of the major points of Perl 6, and one of its major attractions for me, was that we finally put the backwards compatibility ghost to rest. We can do brave, new, exciting things, without worrying about needing to maintain obscure pieces of functionality. Yey! Except that we can't do that any more; we've constrained ourselves to faithfully regressing to Perl 5 when we see a package declaration. Why? Because we're scared. package parses Perl 5 is a sop to people who don't want to program in Perl 6, and we're worried about losing those people. One word: CPAN. (Okay, that was three words.) It will be a long, long time before all the CPAN modules are rewritten in Perl 6. In the meantime, Perl 6 code has to be able to use Perl 5 modules, or it will be crippled, and probably stillborn. Having said that, I have real, real doubts that Perl 6 will ever be able to execute Perl 5 code natively. Its not just a case a writing a new parser and some P5-specific ops; P5 has so many special features, boundary conditions and pecularies, that to get P6 to execute P5 is a task equivalent to reimplementing P5 from scratch. I'm wondering if instead, we continue to maintain the P5 src tree, and embed P5 within P6 (embed in the sense of Apache and Mod_perl). Sick and ugly, but maybe more practical than the alternatives. It also means that the P6 src doesn't have to be saddled with knowing (much) about P5. Eventually of course the P5 bit would have to be thrown away. Dave. -- There's something wrong with our bloody ships today, Chatfield. Admiral Beatty at the Battle of Jutland, 31st May 1916.
Re: eval {} or carp blah: $@
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 } or carp
$a = 0; eval { 1 / $a } or carp
will both carp
--
My get-up-and-go just got up and went.
Re: Loop controls
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 or so.
Re: Cfor loop variations
On Tue, Apr 16, 2002 at 06:17:24PM -0700, David Wheeler wrote:
In Exegesis 4, Damian writes:
blockquote
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:
for a, b - $x, $y {...}
# sequentially iterate a then b, two-at-a-time as $x and $y
/blockquote
Now, I love that the for loop can do both of these things, but the subtlety
of the difference in syntax is likely, IMO, to lead to very difficult-
to-find bugs. It's very easy to miss that I've used a comma when I meant to
use a semicolon, and vice versa. And what's the mnemonic again?
Personally I really hate the use of the semicolon here - it's
counter-intuitive to everything you expect from semicolons in the 'C'
stable of languages (and English too) - ie my brain groups the terms in
for a; b - $x; $y {...}
like
for [@a]; [@b - $x]; [$y] {...}
rather than
for [@a; b] - [$x; $y] {...}
Maybe we should have something like
for a - $x; b - $y {...}
Instead.
This has the advange of being writeable as the following for clarity:
for
a - $x;
b - $y
{
But hey, what do I know - I'm not a linguist or language designer :-)
--
But Pity stayed his hand. It's a pity I've run out of bullets, he
thought. - Bored of the Rings
Re: // in Perl 5.8?
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 you're referring to 5.8.x for some x != 0 ??? :-)
--
print+qq$}$$/$s$,$*${$}$g$s$@$.$q$,$:$.$q$^$,$@$*$~$;$.$q$mif+map{m,^\d{0\,},,${$::{$'}}=chr($+=$||1)}q10m22,42}6:17*2~2.3@3;^2$g3q/s=~m*\d\*.*g
Re: Unary dot
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 mummery. But that seems a bit retro. But now we have endless possibilities for $self.ish $self.less $self.centred $self.obsessed etc. -- But Sidley Park is already a picture, and a most amiable picture too. The slopes are green and gentle. The trees are companionably grouped at intervals that show them to advantage. The rill is a serpentine ribbon unwound from the lake peaceably contained by meadows on which the right amount of sheep are tastefully arranged. Lady Croom - Arcadia
Re: Perl6 -- what is in a name?
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 Perl is that it is a relatively small
learning effort to write Perl 6 code using Perl 5 idioms. Eg $foo{bar}
becomes %foo{bar}, '.' becomes '_' etc, but the end code is still
largely recognisably Perl.
Contrast this to an experienced Perl 5 coder trying to pick up Python
or Ruby from scratch. A different order of magnitude altogether.
Clearly there's all the optional new stuff in Perl 6 which is strange and
needs learning, but that's no different from Perl 4 coders having to
get up to speed on refs, OO, and all the other 'strange' stuff that
Perl 5 introduced. (eg think how strange $self-SUPER::bar([qw(a b)])
was to Perl 4 coders.)
So in purely technical terms, I think Perl 6 is close enough to Perl 5
to keep the name.
In marketing terms, we absolutely must keep the name. If you're a fan
of Coke, are you more likely to switch to Cherry Coke (tm)(c)(r)(etc),
or new cherry fizzo drink, bottled in the same factory that makes
Coke(tm)(c)(r)(etc) ;-)
Just MHO.
%MY:: (was Re: Perl 6 - Cheerleaders?)
Aaron Sherman [EMAIL PROTECTED] wrote:
If it's an outer-scope lexical, use Ccaller-{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
reason.
The main motivating factor for %MY:: is so that 'use Foo' allows Foo
to modify the lexical scope of its invoker, as opposed to Perl 5 where
it has to modify the whole package to import symbols.
Clearly this is a Good Thing.
As to whether other uses of %MY:: are Good Things, see previous discussions
ad nauseum on -internals and -language.
Re: What's up with %MY?
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
my $x = 100;
{
print $MY::{'$x'};
}
I would expect that to print 100, not 'undef'. Are your expectations
different?
Yes. I would expect that to print 'undef'. '$x' doesn't exist as a key in
%MY::
I think any further discussion hinges on that.
Yes. My expectations are different. My expectations are exactly like my
previous PATH example.
my $x = 100;
{
$MY::{'$x'} = 200; # Equivalent to 'my $x = 200'
print $x;
}
print $x;
That should print 200, and 100, should it not?
You are creating a lexical in the current scope, and assigning it the value
of 200. You are not finding a currently existing $x and assigning it the
value of 200, resulting in 200 / 200.
But let's be a little more pragmatic about it, shall we? Look beyond the
fire and brimstone for a moment. As Dan said, we can already screw up your
entire world. So other than a couple clever hacks from Damian, how will
they be used?
I think you're confusing me with Ken Fox! At the moment, I'm just trying
to eke out of Damian what the precise semnatics of %MY:: will be, since
there are lots of possibilities. I'll join Ken in the Hellfire and Damnation
stakes after I've got a fixed target to aim at ;-)
Okay, personally I like the idea that %MY:: doesn't affect the values
or visibility (much) of outer scopes, since there's less
action-at-a-distance going on. The main drawback is that users may
find it counter-intuitive that you can't substitute $x in an expression
with %MY::{'$x'} and get the same result. But I guess they'll just
have to read the man page properly :-)
Anyway, in any particular scope, a variable $x can be in one of three states:
A) not defined, so '$x' refers to an outer lexical or global
B) defined but not introduced, and '$x' similarly refers to the outer value
(if any)
C) defined and introduced; '$x' refers to the local value.
Any manipulation of $::MY{'$x'} at compile or run time will have certain
effects in each of those 3 cases. Here's what I think all the permuations
should be.
... = %::MY{'$x'}
-
A,B: returns undef; C: returns ref to $x.
In no case is $x autovivified.
%::MY{'$x'} = \...
---
A@compile: equivalent of my $x=...
A@run: probably equivalent to my $x=..., but we need to decide if affects
the visibility of previously compiled references to $x:
$x = 1; # package var
sub f { caller().{MY}{'$x'} = 2 if $_[0] }
sub g {
f(1);
$x; # does this see the lexical or the package var?
}
B,C: sets the lexical '$x' to the new value
delete %MY::{'$x'}
--
A,B: NOOP
C: marks the lexical as deleted. Any subsequent ...=$x or $x=...
give a runtime error; subsequent ...=%MY::{'$x'} returns undef, while
a subsequent %MY::{'$x'}=... resurrects the variable with a new value.
RE: What's up with %MY?
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 = 100;
{
my $x = (delete %MY::{'$x'}, $x+1);
print inner=$x, ;
}
print middle=$x, ;
}
print outer=$x;
If delete 'reexposes' an outer version of that variable, then I'd speculate
the output would be
inner=51, middle=50, outer=50
Re: What's up with %MY?
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;
{
my $x = (%MY::{'$x'} = \200, $x+1);
print inner=$x, ;
}
print outer=$x;
I'm guessing this prints inner=201, outer=200
Perhaps I missed something, but %MY:: refers to my lexical scope, and not my
parents, correct?
Why isn't this inner=201, outer=100?
Because on the RHS of a 'my $x = ...' expression, $x is not yet in scope
(ie hasn't been introduced), so
my $x = 100; { my $x = $x+1; print $x }
prints 101, not 1 - the $x in the '$x+1' expression refers to the $x in the
outer scope.
I was just trying to confirm whether similar semantics apply to the use of
%MY:: - ie when used where a lexical has been defined but not yet introduced,
does %MY{'$x'} pick up the inner or outer lex?
I especially wanted to confirm whether delete %MY{'$x'} will delete the outer
$x because the inner one isn't yet quite in scope.
what lexicals do?
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 introduction - a variable that has been defined but does
not yet mask an outer var, eg my $x = 1; { my $x = $x+1; ... }
* an inner sub referring to a lexical in a lexically enclosing outer sub
- ie closures.
* eval - ie delayed compilation of an inner sub with restored scope
* typed lexicals
* our
New in Perl 6:
* %MY:: dynmaically changing the values and visibility of lexicals
* lexically scoped named subs - so caller(){MY::}{'die'} = mydie does
something useful.
RE: What's up with %MY?
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;
use Foo; # does $x become 1, or $x redefined, or runtime
# error, or ... ?
do you mean Foo::import()? 'use' is handled like:
BEGIN {
require Foo;
Foo::import(@_);
}
So 'use Foo' would modify the caller, which being processed at compile time
would be 'main'. So this would create a my $x in the scope of the main_cv.
Which would then be removed by the later 'use Bar'.
I meant 'use Foo', in the sense of wanting (at compile time) to modify the
lexical state of the place where 'use' appears (ie f()), since this
appears to be the main reason why people wanted the %MY:: feature in the
first place. Hence the or whatever comment in the vague, hand-waving
my %m = caller(1).{MY} bit. Clearly caller() isn't what we want here, but
I'm not quite sure what would be the correct incantation.
RE: What's up with %MY?
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 should print $mysub-() do?
I'd like it to also throw the same error, preferably at clone time.
Comments?
Re: explicitly declare closures???
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 its not a bug - or at least Gurusamy didnt think so.
Closed variables are just local variables. There's nothing special
about refering to a variable from an inner scope. You don't want
to write
sub foo {
my $x;
if (...) { my outer $x; $x = 0 }
else { my outer $x; $x = 1 }
$x;
}
do you? So why make people using closures do it?
The whole point is that closed variables *aren't* 'just local variables'.
The inner $x's in the following 2 lines are vastly different:
sub foo { my $x= ... { $x } }
sub foo { my $x= ... sub { $x } }
In the first line, the two $x's both refer to the same thing. In the
second line, they don't. To all intents and puposes the inner $x in the
2nd line is declaring a new lexical which happens to grab the outer $x's
value at the time the anon sub is instantiated.
The reason why removing the 'middle' $x in the following
{ my $x = 'bar'; sub foo { $x; sub {$x} }}
causes the behaviour to change is that the middle $x implicitly gives
foo() a copy of $x at compile time. When the anon sub is cloned,
it picks up the current value of foo()'s $x. Without the middle $x, the
cloned sub picks up the outer $x instead.
Since the use of a bare lexical in a nested sub to all intents and purposes
introduces new variable, I thought it would help *people* for this to
be explicitly shown. It would also resolve some fuzzy scoping issues
by making things explicit. In the following, should the anon sub grab
foo()'s $x or the outer $x ?
{ my $x = 'bar'; sub foo { {$x}; sub {$x} }}
In bleedperl, the outer $x is grabbed, while the following line causes
foo()'s $x to be grabbed:
{ my $x = 'bar'; sub foo { sub {$x}; {$x} }}
Clearly one of them is a bug, but which one? No one on P5Pers seemed to want
to decide.
Use of an 'outer' declaration would make this explicit:
{ my $x = 'bar'; sub foo { outer $x; sub {$x} } # grab foo's $x
{ my $x = 'bar'; sub foo { {outer $x;} sub {$x} } # grab outer $x
Dave monomania M.
Re: explicitly declare closures???
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 Perl implementation terms. I've already told you
that if Perl acts the way you say it does, then Perl has buggy
closures. You don't need to explain a bug to know that one exists!
Okay, to humour me for a mo', what should the following 2 examples
output if Perl were doing the right thing?
sub pr { print $_[0] || 'undef', \n }
{ my $x = 'X'; sub f {$F = sub {pr $x} }}
f(); $F-();
{ my $y = 'Y'; sub g { pr $y; $G = sub {pr $y} }}
g(); $G-();
Dave.
Re: explicitly declare closures???
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 { } }
and the problem comes back ;-)
Anyway, coming back to my original suggestion:
I think closures are a lot harder (or at least subtler) than people
think, and explicit declarations might help. There again, they might not.
Ah well
Dave M.
Re: properties, revisited
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 you must consider (variable versus value, and hash versus array versus scalar versus filehandle), are properties that are meaningless for some section usable by the user? I would expect so, but Larry's MMV. My personal preference would be for all such properties (traits?) to be reserved across all types - eg using 'prompt' on a hash gives a compile/run time error. This allows the compiler to catch certain types of typo and thinko, and also allows us to expand in future - eg when some P6Per comes up with a bright idea on how prompts can be made applicable to hashes, we dont have the familar argument but we can't do that, it may break code that defines a user property called 'prompt'. PS - I *really* like the traits proposal.
Re: Lexicals within statement conditionals
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];
print shift @a, ;\n{\n,
join (, , @a[@a/2 .. $#a]), if ,
join (, , @a[0 .. @a/2-1]), ;\n;
print EOF;
print $v: \$$v\\n;
}
print $v: \$$v\\n;
EOF
}
__END__
I'm found tests B, C, and D a little surprising. I expected 'befg/acd',
'cefg/abd', and 'defg/abc' (lexical/global answers, respectively).
Although I now understand what it does, I'm still fuzzy on the why and how.
Can someone in the know give a clear enough explanation that I can document?
Its due to the fact that my variables dont come into scope until the
end of the expression in which they are defined. eg
my $a = 8;
{
my $a = $a+1;
print $a; # prints '9', not 1
}
In the expression my $a = ..., the ... is evaluated as if $a has not yet
been defined (in perl5 internals terminology, it hasn't yet been introduced).
So my $a = $a+1 is parsed as my $inner_a = $outer_a + 1.
A similar thing happens with:
my $a = 10;
foreach my $a ($a..$a+5) {
print $a\n; # prints 10..15
}
the new $a doesnt come into scope until the start of the { } block.
In your code,
$b .= 'a';
{
$b .= 'e', $b .= 'f', $b .= 'g' if my $b .= 'b', $b .= 'c', $b .= 'd';
print b: $b\n;
}
print b: $b\n;
A if B is syntactically equivalent to (B) (A) (in fact that's how
the perl 5 parser handles it), so you have
(my $b .= 'b', $b .= 'c', $b .= 'd') ($b .= 'e', $b .= 'f', $b .= 'g')
and the lexical $b doesnt come into scope until the end of that expression.
So the expression is really
(my $inner_b .= 'b', $outer_b .= 'c', $outer_b .= 'd')
($outer_b .= 'e', $outer_b .= 'f', $outer_b .= 'g')
Dave who by coincidence spent the last couple of weekends staring at the
pad code in op.c etc trying to make some sort of sense out of it (and
mostly failing) M.
Re: properties
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. That has been exactly my thought as I have been reading this thread. Actually I think the original is wrong. I would have said: my $a is true = 0; # variable property my $a = 0 is true; # value property my ($a) = 0 is true;# value property Interestingly, one of Larry's earlier examples had it the 'wrong' way round too. $ETOOCONFUSING++ ? Perhaps rather than having a variable/value distinction, we should just state whether a property is preserved over assigns etc, eg my $a is true = 0; # $a is true $a = 0; # $a is now false my $a is sticky true = 0; # $a is true $a = 0; # $a is still true my $b is sticky false = 0; my $a is sticky true = $b; # $a is true, since lh stickiness overrides # rh stickiness As a slight aside, the 'true' property seems slightly confusing. is there a corresponding 'false' propety, which is set, deletes any 'true' propery and vice-versa? Or should we just have a bool property? return 0 is bool(1); return foo is bool(0);
The 5% solution
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 paying, we need to
bear in mind that the eventual syntax and semantics of Perl 6 has got
to be such that the writing of the Perl 5 to 6 translator utility is
still feasable. I dont think the syntax will be too much of a problem
(eg %foo{a} vs $foo{a}), but it will be important that there is always
some way of expressing Perl5-ish semantics in such matters as list context
etc.
$soapbox.dismount or dismount $soapbox or $soapbox-dismount();
Re: The 5% solution
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 B::Deparse route, but I'd worry about perl5 byte-code not being semantically similar to Perl 6 bytecode. There's a lot of implicit assumptions about what an aassign op does, say. But the words suck, teach, eggs and grandma are probably appropriate at this point if suitably re-arranged ;-)
Re: Apoc2 - STDIN concerns ::::: new mascot?
And there was me thinking the shiny ball must be a camel dropping
Re: What can we optimize (was Re: Schwartzian transforms)
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.) Hello? This is a very high-level language we are writing, not a DSP core. Optimizing by choosing good algorithms and data structures, yes, microoptimizing, maybe, only after the code works first, and even then we would be following the mirage since CPU architectures do evolve, and in general, for large codebases, the C compilers are much, much, better in optimizing than humans. Yes, a human can sit down and read the databooks and optimize a simple algorithm to hell and back. But megabytes of source code? Get real. That may have been me: http://archive.develooper.com/perl6-internals%40perl.org/msg02685.html (PDD for coding conventions) The main thrust of that was whether a PDD on coding conventions should have sections on: * Coding style * Naming conventions * Commenting conventions * Portability guidelines * Performance guidelines Based on your comments above (which I hearily agree with), I guess we can safely dispense with that last entry. Dave M.
