This week's Perl 6 Summary

[Piers Cawley]

The Perl 6 Summary for the week ending 20021110
Far off in distant Newark a figure, muttering something about `Leon
Brocard', shambles across a railway bridge and makes its way into a
waiting room. Time passes. After a while, a train arrives and the figure
shambles on board, takes its seat, pulls a laptop from its bag and
starts to type. This is what it types: `=head1 The Perl 6 Summary for
the week ending 20021110'.

Yes, it's time for another update on the japes and tomfoolery from the
world of Perl 6. We start, as usual, with perl6-internals.

  The Myth of Fingerprints
At the end of the previous week, Gregor posted an outline of his
proposal for fixing the fingerprinting issue with dynamic loading. (The
fingerprinting issue is that 'old' .pbc files may break big time when
run on newer Parrots. Ideally we'd like Parrot to refuse to run such
files *before* bad things happen. It's proposed that this be done by
adding `fingerprints' to .pbc to allow for identification by Parrot.)
Leopold Tötsch wasn't at all sure about Gregor's approach, pointing out
that it would have massive speed implications, and lo, the thread got
dragged off in the direction of a discussion of optimizing Parrot for
speed. How did that happen then?

http://makeashorterlink.com/?T12252F62

  "on_exit" not portable
Andy Dougherty pointed out that Solaris doesn't have "on_exit", which is
used by Parrot to clean up after itself, and suggested that
interpreter.c be reworked to use "atexit". However, SunOS has on_exit
but doesn't have atexit. It's a quandary. Josh Wilmes suggested
implementing "Parrot_on_exit()" and "Parrot_exit()" in platform.c and
half promised a patch (unless somebody beat him to it.) Leo Tötsch and
Nicholas Clark both said, essentially "Nice idea, go do it."

Dan chimed in, pointing out that the current "on_exit" behaviour seemed
to be there as a workaround for bugs in exceptions, and that fixing
those was probably the better idea. Leo turned off the 'on_exit' stuff,
just as Josh was sending a patch implementing the Parrot_* functions. I
think that, as we now stand, we're back to doing exit cleanup, but using
the portable Parrot_* functions.

http://makeashorterlink.com/?F53246F62

http://makeashorterlink.com/?G14231F62

  Should memory be washed?
Peter Gibbs was unsure of the guarantees given by "Parrot_allocate" and
friends regarding the contents of the memory supplied. Apparently, some
code appears to assume that it will get pre-washed memory, while other
code does its own cleaning. Which is right? Leo Tötsch reckons that the
current behaviour (memory is zeroed at allocation time) should be
guaranteed. Dan wasn't so sure that this was a good idea if we go for a
`malloc like' scheme and thought that it could be argued that it was a
bug for any code to assume that the memory it got was zeroed.

Eventual consensus was that the basic allocator should not guarantee
zeroed memory, but that there should be a set of allocator functions
that *do* return zeroed memory. Leo checked in a patch to that effect.

Then they started talking about performance.

http://makeashorterlink.com/?X15224F62

  "string_set" is back
Leopold Tötsch has added a 'string_set' function which allows strings to
be recycled instead of having to create new strings every time. This can
lead to substantial speed gains when used appropriately. This led to a
discussion on when it was appropriate to use non destructive assignment
and when to use a destructive set. Somewhat to my surprise, nobody has
yet suggested the lispish "set" is non destructive, "set!" is
destructive split, allowing the Parrot coder to choose. Looks like I
just suggested it here.

http://makeashorterlink.com/?M26225F62

Meanwhile, over in perl6-language
Amazingly, the main topic of conversation this week wasn't the dreaded
operator thread...

  Unifying invocant and topic naming syntax
Allison Randal has written an article about Perl 6 topics for perl.com.
`Ralph' read this and didn't appear to like it very much, particularly
the "sub foo ($bar) is given($baz) { ... }" syntax which sets $baz to
the value of the caller's topic. (If you're not sure what I'm talking
about, now would be a good time to read Allison's article. Topics are
great, you'll like them.) Ralph wanted to do "sub foo ($baz : $bar is
topic) { ... }", and supplied several further, terser and terser
declaration forms, "method f ($self : $c : $a*, $b) {...}" anyone?

Allison thought Ralph was barking up the wrong tree, and explained the
thinking behind the topic related syntax and pointed out that Ralph
appeared to be conflating two `independent but interacting features'
with his proposal, but Ralph didn't give up that easily. Eventually,
after

Re: on Topic

[fearcadi]

Me writes:
 > Sorta. To quote an excellent summary:
 > 
 > "Topic is $_". 
 > 
 > 
 > 
 > > is $_ always lexical variable.
 > 
 > Yes.
 > 
 > 
 > > Or I can have $MyPackage::_ ?
 > 
 > You can copy or alias any value.
 > 

so if I understand correctly , 

Every topicalizer defines a topicalizer scope in which there is
implicit declaration 

my $_ ; 

and then lexical $_ ( implicitely ) is bound to ( or assigned to )
whatever it should in this particular topicalizer. And from that on $_
is just another lexical variable .

Question(s) : 

with no "use strict vars" any "just another variable" is taken by perl as
being global -- it is implicitly "our $just_another_var;" (???) 
about any lexical veriable ( just_another_variable ) Perl have to be
explicitly informed as being such . is $_ just_another_variable in
that respect too ??? 

in other words , what happens if I just use $_ ( that is , without
previous declaration ) *outside any topicalizer* ?

* will it be implicitly "our $_" ( probably not , because it is
  always lexical )
or  * will it be implicitely "my $_" -- class/package lexical 
or  * will it be error to just use it without declaration  
   * with "use strict vars" 
   * with "no strict vars " 

will  it be an error to declare it as "our $_" ; 

and to repeat the question from previous post , 
what will perl do when it see 

$My_Package::_ = 1 ; 


???




thanks , arcadi . 

Re: Superpositions and laziness

[Peter Haworth]

On Tue, 12 Nov 2002 21:11:36 +, Piers Cawley wrote:
> Michael Lazzaro <[EMAIL PROTECTED]> writes:
> > On Friday, November 8, 2002, at 07:03 AM, Adam D. Lopresto wrote:
> >> I still prefer "cached", which sounds less lingo-ish than "memoized"
> >> but reads better than "same" ("Same as what?").
> >
> > Insert obligatory reference to Eiffel here, which IIR uses the word
> > "once":

But that means "once per system", not "once per unique argument list".

-- 
Peter Haworth   [EMAIL PROTECTED]
Interesting trivia: If you took all the sand in North Africa and spread
it out... it would cover the Sahara desert.

Re: Continuations

[Peter Haworth]

On Tue, 12 Nov 2002 14:30:24 +, Peter Haworth wrote:
> So to get the same yield context, each call to the coroutine has to be from
> the same calling frame. If you want to get several values from the same
> coroutine, but from different calling contexts, can you avoid the need to
> wrap it in a closure?

I'm an idiot. Why not make the closure a coroutine itself?

  sub consume(@bar){
my $next=sub{ yielf $_ for @bar; return; };
while my $val = $next() {
  do_stuff($val,$next);
}
  }

>   sub do_stuff($val,$next){
> ...
> if $val ~~ something_or_other() {
>   my $quux = $next();
>   ...
> }
>   }
> 

-- 
Peter Haworth   [EMAIL PROTECTED]
"The term `Internet' has the meaning given that term in
 section 230(f)(1) of the Communications Act of 1934."
-- H.R. 3028, Trademark Cyberpiracy Prevention Act

Re: Meta-operators

[fearcadi]

Timothy S. Nelson writes:
 >  Hi all.  I hope this hasn't been discussed before.  I Googled for 
 > "perl6 meta-operators" and found nothing; likewise practically 
 > nothing searching the perl6-language archive for meta-operators.  
 > 
 > Question: are there any plans to have user-defined meta-operators in perl6?  
 > 
 > Explanation: By meta-operators, I mean operators which operate on other 
 >  operators (much as APL operators do to APL functions).  I'm thinking 
 >  it'd be widely useful in the core; it'd do a lot of the digraphs (like 
 >  += and those), and I can think of uses for it outside the core too.  
 > 
 >  Anyway, do we get them?  


there was some discussion in the thread under 

but there was no "last word" about it. either this is something perl
*trivially* will have due to its powerful grammar capabilities or it
is something perl will *avoid* to dwell in , or ... 

but it is interesting if perl will ( or already is ) be able to do
something like 

sub operator:tensor:[] ( Code &op  is parsed( ... ) , 
 Array|Hash|Scalar @a , 
 Array|Hash|Scalar @b )
{ ... return array/hash/whatever  of  @a[i] op @b[k] for  all pairs (i,k) }   
   
if that or something like that is possible , we will not need vector
operators "built in" the language  -- they will be just one of the 

sub operator:v:[] ( Code &op  is parsed( ... ) , 
 Array|Hash|Scalar @a , 
 Array|Hash|Scalar @b )
{ ... return array/hash/whatever  of  @a[i] op @b[i] for  
  all i present in both arrays ( if intersection ) or 
  all i present in one or another  array ( if union )  
}

but I dont know . Just wishes from someone who dont see the whole
picture .

arcadi .

Re: This week's Perl 6 Summary

[fearcadi]

Piers Cawley writes:
 > 
 >   FMTWYENTK about ":="
 > Bravely declining to expand the acronym in his subject, arcardi posted a
 > summary of his current understanding of the behavior of ":=", the

its "far more then what you ever need to know"
and after Damian Conway answer it becomes JEOWYNTK - 
"just enough of what you ever need to know" .

( is it ??? ) 

arcadi . 

Re: Unifying invocant and topic naming syntax

[Larry Wall]

On Mon, Nov 11, 2002 at 11:48:06PM -0600, Me wrote:
: Are placeholders only usable with anonymous
: subs, or named subs too?

Placeholders are not intended for use with named subs, since named
subs have a way of naming their parameters in a more readable fashion.
However, it may well fall out that if you say

sub foo { $^b <=> $^a }

it would effectively mean the same thing as

sub foo ($a, $b) { $b <=> $a }

But note that there's no placeholder equivalent for a forward declaration:

sub foo ($a, $b) { ... }

: Switching briefly to currying, can one curry
: a method?

Hmm.  We can allow what makes sense.  I suppose a class should be
allowed to curry one of its own methods on any non-invocant parameter,
since that's just equivalent to defining a new method in the same class.
(Generally, outside of a class, if you want to make the signatures of
the methods look different, the standard way is to derive a new class.)

Currying on the invocant is different, since it essentially turns
a method into a subroutine, and treats a class as a mere module.
This could be construed as antisocial.  However, as a special case,
one might often want to curry a set of methods to assume a particular
invocant.  But the syntax for that should probably involve the class
rather than the individual methods.  Saying

use DB_Connection.assuming(self => new DB_Connection)

could import all of DB_Connection's public methods into the current
class or module as subroutines, and then you don't have to do the
sort of I'm-a-class-no-I'm-a-module shenanigans that modules like
CGI currently do.

Larry

Re: on Topic

[Larry Wall]

On Wed, Nov 13, 2002 at 03:11:32PM +0200, [EMAIL PROTECTED] wrote:
: so if I understand correctly , 
: 
: Every topicalizer defines a topicalizer scope in which there is
: implicit declaration 
: 
: my $_ ; 
: 
: and then lexical $_ ( implicitely ) is bound to ( or assigned to )
: whatever it should in this particular topicalizer. And from that on $_
: is just another lexical variable .

Yes.

: Question(s) : 
: 
: with no "use strict vars" any "just another variable" is taken by perl as
: being global -- it is implicitly "our $just_another_var;" (???) 
: about any lexical veriable ( just_another_variable ) Perl have to be
: explicitly informed as being such . is $_ just_another_variable in
: that respect too ??? 

$_ is always a lexical.  Every file scope has an implicit "my $_" at the top.
Every nested scope either sets up its own lexical $_ or aliases to an outer $_.

: in other words , what happens if I just use $_ ( that is , without
: previous declaration ) *outside any topicalizer* ?

There is no "outside any topicalizer" from that standpoint.  However,
$_ does start off undefined in an implicit topicalizer, and we may
well disallow "break" to such an implicit topicalizer at file scope,
and maybe at subroutine scope.

: * will it be implicitly "our $_" ( probably not , because it is
:   always lexical )

Correct, $_ is always lexical.  But...

: or  * will it be implicitely "my $_" -- class/package lexical 

There's no such thing as a "class/package lexical".  I think you
mean file-scoped lexical here.

: or  * will it be error to just use it without declaration  
:* with "use strict vars" 
:* with "no strict vars " 
: 
: will  it be an error to declare it as "our $_" ; 

No, in this case, $_ is still considered a lexical, but it just happens
to be aliased to a variable in the current package.

: and to repeat the question from previous post , 
: what will perl do when it see 
: 
: $My_Package::_ = 1 ; 

It'll set the $My_Package::_ variable to 1, I presume.  Whether that
has any influence on the value of $_ depends on how $_ is currently
aliased.  But the name $_ will always be interpreted according to the
lexical definitions set up by "my" and "our" (including the implicit
outer "my").

Larry

Re: Superpositions and laziness

[Larry Wall]

On Fri, Nov 08, 2002 at 08:35:00PM +1100, Damian Conway wrote:
: What you want are conversion-to-(num|str|bool) methods:
: 
:   sub a_pure_func(Num $n) returns Num {
:   class is Num {
:   has Num $cache;
:   sub value { $n * $n }
:   method operator:+ ($self:) { +($cache //= value ) }
:   method operator:~ ($self:) { ~($cache //= value ) }
:   method operator:? ($self:) { ?($cache //= value ) }
:   }.new
:   }

Just a nit, but those are probably prefix: rather than operator:, since
we may need more clues than just the arguments to distinguish:

prefix:
infix:
postfix:
circumfix:   (or should that really be outfix:?)

Larry

Re: Superpositions and laziness

[Larry Wall]

On Tue, Nov 12, 2002 at 09:03:22PM +, Piers Cawley wrote:
: Hang on, couldn't you rewrite things to not use the cache?
: 
: class is $class {
:   sub value { &func(*@args) }
:   method operator:+ ($self is rw:) { +($self = value) }
:   method operator:~ ($self is rw:) { ~($self = value) }
:   method operator:? ($self is rw:) { ?($self = value) }
: }.new
: 
: I don't know if I hope that works or hope it fails miserably. 
: 
: Also note that, if you were feeling sufficiently lazy with numbers,
: you could define the set of binary operators for your deferred
: numbers:
: 
:   method operator:+ ($self: Num $other) is lazy { +($self) + $other }
:   method operator:* ($self: Num $other) is lazy { +($self) * $other }
:   method operator:/ ($self: Num $other) is lazy { +($self) / $other }
:   method operator:- ($self: Num $other) is lazy { +($self) - $other }
: 
: Or would that just be evil, Bad And Wrong?

I believe the correct term is "opaque".  And I don't mean that
in the good sense...

Larry

More junctions

[Luke Palmer]

When junctions collapse, is that reflected back in the original
junction, as it should be (QM-wise)?

$foo = 1 | 2 | 4
print $foo;
# Foo is now just one of (1, 2, 4); i.e. not a junction

If so, what is perl going to do about the computationally expensive
entanglement thingy?

$x = 0 | 1;
$y = 0 | 1;
$z = $x * $y; 

print $z; # 0 with 0.75 probability and 1 with 0.25
# If 0 was printed, then $x | $y == 0
# If 1 was printed, then $x & $y == 1

Here, are $x and $y collapsed yet, or are they still in an entangled
superposition?

Luke

Re: Unifying invocant and topic naming syntax

[Nicholas Clark]

Apologies for raising the dead (horse)

On Thu, Nov 07, 2002 at 03:27:51PM -0600, Me wrote:
> Damian:
> > ["it" will be passed to about 5% of subs,
> >  regardless of whether the context is your
> >  10 line scripts or my large modules]
> 
> If the syntax for passing "it" to a sub
> remains as verbose as it currently is,
> you are probably right that "it" won't
> be used to achieve brevity! I think it's
> a pity given that the core point of "it"
> is to achieve brevity.
> 
> Why do you think your estimate of Perl 6
> usage of "it" is so much lower than is
> true for the standard Perl 5 functions?

If a subroutine explicitly needs access to its invocant's topic, what is so
wrong with having an explicit read-write parameter in the argument list that
the caller of the subroutine is expected to put $_ in?

It makes it clear.

If I understand all this correctly, as is, this "access caller's topic"
is an unrestricted licence to commit action at a distance.

Accessing the caller's topic is the default in perl5. And there is still a
steady stream of bugs to p5p where core perl modules are doing something
(typically a while loop) which tramples on $_, and so makes something go
wrong in their caller. (possibly several levels down)

(And for that matter the "obvious" solution of local ($_) in perl5 is also
action at a distance if $_ is tied, as local is an immediate fetch and a
store at end of scope. Special case local on $_ ?)

Nicholas Clark
-- 
perl6 better than perl (this week)?   http://www.perl.org/advocacy/spoofathon/
[Alledgedly some judging activity soon. Yeah, right. Pull the other one]

Re: Unifying invocant and topic naming syntax

[Luke Palmer]

> Date: Wed, 13 Nov 2002 20:34:49 +
> From: Nicholas Clark <[EMAIL PROTECTED]>
> 
> 
> If a subroutine explicitly needs access to its invocant's topic, what is so
> wrong with having an explicit read-write parameter in the argument list that
> the caller of the subroutine is expected to put $_ in?
> 
> It makes it clear.
> 
> If I understand all this correctly, as is, this "access caller's topic"
> is an unrestricted licence to commit action at a distance.
> 
> Accessing the caller's topic is the default in perl5. And there is still a
> steady stream of bugs to p5p where core perl modules are doing something
> (typically a while loop) which tramples on $_, and so makes something go
> wrong in their caller. (possibly several levels down)
> 
> (And for that matter the "obvious" solution of local ($_) in perl5 is also
> action at a distance if $_ is tied, as local is an immediate fetch and a
> store at end of scope. Special case local on $_ ?)

Indeed.  And also mind that many (IIRC all, but I could be wrong)
Perl5 builtins used $_ as the I, and if a parameter was
supplied it would use that.

My favorite was from ages ago:

sub bar(;$foo //= $_) {...}

'Course that could be mistaken for defaulting to the current $_ in
C's lexical scope.  Regardless, IMO it is better style to always
use $_ as just a default, rather than a requirement.  Is there a good
reason to have subs like this:?

sub bar($foo) is given($baz) {...}

Or, if you stick with Perl5 convention, and I imagine this is what
people will expect from the builtins at least:

sub bar($foo; $baz) is given($baz) {...}

That duplicated parameter looks strange, and people will be wary of
using it that way (as I was).  I don't know what it looks like, but it
doesn't look like $baz gets $_ if not, well, C.

Luke

Re: More junctions

[Deborah Ariel Pickett]

Luke wrote:
> When junctions collapse, is that reflected back in the original
> junction, as it should be (QM-wise)?
> 
> $foo = 1 | 2 | 4
> print $foo;
> # Foo is now just one of (1, 2, 4); i.e. not a junction
> [...]

Just a sanity check, but is this kind of behaviour something we still
want from junctions?  If we're trying to get away from the whole
"Quantum Superposition" name, why do we want to still have an implicit
collapse on $foo when it's used in certain contexts?  To collapse like
this doesn't make sense unless you're still thinking in quantum terms.

Perhaps the above should just print JUNCTION(0x1234) or something, like
the other built-in types do.  If you really want to collapse the
superposition, use an explicit collapse($foo) or observe($foo) or
pick($foo) or whatever you want to call it.

Just a thought from someone vaguely in the Cozens Camp.

-- 
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
 "The city lights shine seaward, swirling in a trance, her eyes upon the water
   alone in her last dance." - _Oh Life (There Must be More)_, Alan Parsons

Re: This week's Perl 6 Summary

[Deborah Ariel Pickett]

>   Supercomma!
> [snip]
> Larry then confessed that he was thinking of changing the declaration of
> parallel for loops from:
>   for @a ; @b ; @c - $a ; $b ; $c {...}
> to something like:
>   for parallel(@a, @b, @c) - $a, $b, $c {...}

Assuming that semicolon is no longer going to be a supercomma in these
situations, does that mean that we C addicts can have C back to do
the kinds of loops that we mean when we say "for loops"?  I really
don't much like the C keyword.

  for ($i = 1; $i < 10; $i++) { ... }

(Or is there still some syntactic ambiguity that I haven't thought of?)

-- 
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
 "The city lights shine seaward, swirling in a trance, her eyes upon the water
   alone in her last dance." - _Oh Life (There Must be More)_, Alan Parsons

Re: More junctions

[Smylers]

Deborah Ariel Pickett wrote:

> Luke wrote:
>
> > $foo = 1 | 2 | 4
> > print $foo;
> > # Foo is now just one of (1, 2, 4); i.e. not a junction
> 
> Just a sanity check, but is this kind of behaviour something we still
> want from junctions?
> 
> Perhaps the above should just print JUNCTION(0x1234) or something,
> like the other built-in types do.  If you really want to collapse the
> superposition, use an explicit collapse($foo) or observe($foo) or
> pick($foo) or whatever you want to call it.

That sounds the least scary behaviour: it may not do anything
particularly useful by default but at least it's obvious what's
happened.  Having C Huffman-encoded to nothing at all sounds
unnecessary for those that need it.

> Just a thought from someone vaguely in the Cozens Camp.

That, however, does sound scary -- I didn't know Simon had gone into the
holiday resort market.  Is The Cozens Camp anything like Butlins?

Smylers

re: This week's Perl 6 summary

[Damian Conway]

Deborah Ariel Pickett wrote:

> Assuming that semicolon is no longer going to be a supercomma in these
> situations, does that mean that we C addicts can have C back to do
> the kinds of loops that we mean when we say "for loops"?

I hope not.


> I really don't much like the C keyword.
>
>   for ($i = 1; $i < 10; $i++) { ... }
>
> (Or is there still some syntactic ambiguity that I haven't thought of?)

No. It's more a cognitive ambiguity.

One of the goals was to reduce (or preferrably eliminate) syntactic homonyms
in Perl 6. You'll notice that one of the Cs has been renamed to C.
And one of the Cs has become C. And I sincerely hope that the Cs
and Cs will be similarly disambiguated.

For several discussions of why this particular feature of natural languages
*doesn't* map well onto programming languages, see:

	http://www.csse.monash.edu.au/~damian/papers/#Human_Factors_in_Programming_Languages
	

Damian (an unrepentant homonymophobic)

Access to caller's topic (was Re: Unifying invocant and topic naming syntax)

[Me]

> "access caller's topic" is an unrestricted
> licence to commit action at a distance.

Right.

Perhaps:

 o There's a property that controls what subs
   can do with a lexical variable. I'll call
   it Yours.

 o By default, in the main package, topics are
   set to Yours(rw); other lexicals are set to
   not Yours.

 o A mechanism exists for a sub to bypass this
   access control for use with library routines.

--
ralph

Re: on Topic

[fearcadi]

Larry Wall writes:
 > Correct, $_ is always lexical.  But...
 > 
 > : or  * will it be implicitely "my $_" -- class/package lexical 
 > 
 > There's no such thing as a "class/package lexical".  I think you
 > mean file-scoped lexical here.

ooo, now I understand : *scope* is orthogonal concept to class/module
symbol-tables . scope is related only to ( current ) lexical
symbol-table. and the outmost scope is file scope . all other ( inner
) lexical scopes are enclosed by  closure braces wheither it is a
definition of class , subroutine or loop . 

 > 
 > : will  it be an error to declare it as "our $_" ; 
 > 
 > No, in this case, $_ is still considered a lexical, but it just happens
 > to be aliased to a variable in the current package.
 > 

which variable ? it seems that "our $_" is something like that (???)

my $_ # implicit -- at the beginning of file ( or actually any other
  # lexical scope
.. 
..
..
our $_ ; # translated to : our $Main::_ := $_ ; 
..# or $_ := $Main::_ 
..
..
???

( i have in mind that "our $thing " is something like this : "dont
worry , $thing is variable from current package ) 

but that would be strange , because I thaought that my/our manipulate
names in symbol-table , while aliasing is compleatly orthogonal to
that. or "our $_" is just special case with perl making additional
magic . 

 > aliased.  But the name $_ will always be interpreted according to the
 > lexical definitions set up by "my" and "our" (including the implicit
 > outer "my").
 > 


arcadi 

Re: Unifying invocant and topic naming syntax

[Andrew Wilson]

On Wed, Nov 13, 2002 at 08:34:49PM +, Nicholas Clark wrote:
> If a subroutine explicitly needs access to its invocant's topic, what is so
> wrong with having an explicit read-write parameter in the argument list that
> the caller of the subroutine is expected to put $_ in?

It's the difference between this:

print;

and this:

print $_;

It is as far as I'm concerned exactly what topic is all about.  It let's
you write subroutines that behave like builtins with respect to $_.  I
think it's generally intended to be used like so:

sub my_print is given($default) {
  my @args = @_ // $default;
  ...
}

i.e. only doing stuff with $_ if no explicit parameters are passed.

> It makes it clear.
> 
> If I understand all this correctly, as is, this "access caller's topic"
> is an unrestricted licence to commit action at a distance.
> 
> Accessing the caller's topic is the default in perl5. And there is still a
> steady stream of bugs to p5p where core perl modules are doing something
> (typically a while loop) which tramples on $_, and so makes something go
> wrong in their caller. (possibly several levels down)

I don't think that'll be a massive problem with this.  It's not the same
thing at all because $_ is now lexical it's not passed to stuff you call
unless it specifically asks for it.  This will eliminate the trampling
over $_ several levels down.  Needlessly messing with caller's $_ will
become like not using strict or warnings.  Occasionally useful but
generally frowned on in a "don't do that" kind of way.

andrew
-- 
Gemini: (May 21 - June 21)
Disappointment is yours when you overestimate the power of the
human spirit.



msg12018/pgp0.pgp
Description: PGP signature

Re: on Topic

[Larry Wall]

On Thu, Nov 14, 2002 at 04:28:17AM +0200, [EMAIL PROTECTED] wrote:
:  > 
:  > : will  it be an error to declare it as "our $_" ; 
:  > 
:  > No, in this case, $_ is still considered a lexical, but it just happens
:  > to be aliased to a variable in the current package.
:  > 
: 
: which variable ? it seems that "our $_" is something like that (???)
: 
: my $_ # implicit -- at the beginning of file ( or actually any other
:   # lexical scope
: . 
: .
: .
: our $_ ; # translated to : our $Main::_ := $_ ; 

No, that's backwards.

: .# or $_ := $Main::_ 

More like that, except a new lexical name is introduced as with "my".

: ( i have in mind that "our $thing " is something like this : "dont
: worry , $thing is variable from current package ) 

Well, it has that effect, but it does so by pretending it's a lexical.

: but that would be strange , because I thaought that my/our manipulate
: names in symbol-table , while aliasing is compleatly orthogonal to
: that. or "our $_" is just special case with perl making additional
: magic . 

No special magic.  For any variable, saying

package P;
our $foo;

is very much like

my $foo ::= $P::foo

Larry

Re: More junctions

[Luke Palmer]

> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> From: Deborah Ariel Pickett <[EMAIL PROTECTED]>
> Date: Thu, 14 Nov 2002 09:05:16 +1100 (EST)
> Cc: [EMAIL PROTECTED]
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
> 
> Luke wrote:
> > When junctions collapse, is that reflected back in the original
> > junction, as it should be (QM-wise)?
> > 
> > $foo = 1 | 2 | 4
> > print $foo;
> > # Foo is now just one of (1, 2, 4); i.e. not a junction
> > [...]
> 
> Just a sanity check, but is this kind of behaviour something we still
> want from junctions?  If we're trying to get away from the whole
> "Quantum Superposition" name, why do we want to still have an implicit
> collapse on $foo when it's used in certain contexts?  To collapse like
> this doesn't make sense unless you're still thinking in quantum terms.
> 
> Perhaps the above should just print JUNCTION(0x1234) or something, like
> the other built-in types do.  If you really want to collapse the
> superposition, use an explicit collapse($foo) or observe($foo) or
> pick($foo) or whatever you want to call it.

You want these two subs to behave differently, then?

sub foo($x) {
if ($x != 4) {
print "Not four\n";
}
if ($x == 4) {
print "Four\n";
}
}
sub oof($x) {
if ($x != 4) {
print "Not four\n";
}
else {
print "Four\n";
}
}

If given 3 | 4, foo would print "Not Four\nFour\n", while oof would
print "Not four\n".

It seems that collapsation on examination is somewhat essential to
logical flow, when substituting a junction for a solid value.  A piece
of code could certainly "be ready" for junctions (using C and
C), but if not, very obscure bugs could surface (like this
one) when a junction is trying to behave like a real value.

I don't know how much this would come up in practice, but I do see it
as an issue.  The question is:  are junctions more useful if they do
or don't collapse upon examination?

Luke

RE: More junctions

[Brent Dax]

Luke Palmer:
# sub foo($x) {
# if ($x != 4) {
#   print "Not four\n";
# }
# if ($x == 4) {
# print "Four\n";
# }
# }
# sub oof($x) {
# if ($x != 4) {
# print "Not four\n";
# }
# else {
# print "Four\n";
# }
# }

More simply, !($x == 4) is no longer exactly equivalent to ($x != 4).

# I don't know how much this would come up in practice, but I 
# do see it as an issue.  The question is:  are junctions more 
# useful if they do or don't collapse upon examination?

Actually, this suggests to me a flaw in the != operator, not a flaw in
junctions.  We should probably make != exactly equivalent to the
negation of ==; this implies that when != gets a junction the type of
junction is reversed (any becomes all, all becomes any).  This is much
scarier than it sounds--it's a lot like the !(x || y) == (!x && !y)
rule.

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)