Re: is static? -- Question
Larry Wall writes: Er, how would LEAVE detect that this was the *last* time you're ever going to call this routine? On the other hand, if we renamed FIRST and LAST to ENTER and LEAVE, then FIRST would become available to mean my very first time... and LAST will mean just before the GC wipe closure out ?? arcadi
Re: is static? -- Question
--- arcadi shehter [EMAIL PROTECTED] wrote: Larry Wall writes: Er, how would LEAVE detect that this was the *last* time you're ever going to call this routine? On the other hand, if we renamed FIRST and LAST to ENTER and LEAVE, then FIRST would become available to mean my very first time... and LAST will mean just before the GC wipe closure out ?? Wouldn't that be DESTROY? (Obviously not unless it's an object, but) __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com
Re: is static? -- Question
suppose I want this behaviour :
sub new_counter($start=0) {
my $cnt = $start;
my sub incr {
++$cnt;
};
my sub decr {
--$cnt;
};
return sub (str $how=incr)
{
given $str {
when /incr/ incr ;
when /decr/ decr ;
}
}
and then has allows me to do that .
sub new_counter($start=0) {
has $cnt = $start;
has sub cnt {
$cnt;
};
has sub incr {
++$cnt;
};
has sub decr {
--$cnt;
};
return 1; # this is 1 with properties
}
and then :
our $cnt = new_counter ;
$cnt.incr
$cnt.decr
$cnt.cnt
this does not seem to give second unrelated meaning to has.
but, actually, I dont know .
arcadi
Re: is static? -- Question
Matthijs van Duin writes:
A nice example is:
sub a {
state $x;
my $y;
my sub b { return $x++ + $y++; }
return b; # is a \ before b needed?
}
Every call to sub a will return a different closure. The $x in each closure all
refer to the same variable. Each closure's $y however is different and
independent.
does it make any sence to attach but properties to closure ?
if $x is a trait (is property ) of block associated with sub a ,
is it correct to think of $x,$y as but properties of the block
associated with sub b ?
is there any chance for this to work :
sub new_counter($start=0) {
return sub {
prop $cnt = $start; #this is opposite to state
#which sets trait of the block ,
#so presumably , this is created
#anew every time closure is created
return ++$cnt;
}
}
our counter = new_counter ;
our another_counter = new_counter ;
print counter, counter,
another_counter, another_counter ;
#prints: 1 2 1 2
arcadi .
Re: is static? -- Question
--- arcadi shehter [EMAIL PROTECTED] wrote:
Matthijs van Duin writes:
A nice example is:
sub a {
state $x;
my $y;
my sub b { return $x++ + $y++; }
return b; # is a \ before b needed?
}
Every call to sub a will return a different closure. The $x in
each closure all refer to the same variable. Each closure's $y
however is different and
independent.
does it make any sence to attach but properties to closure ?
if $x is a trait (is property ) of block associated with sub a ,
is it correct to think of $x,$y as but properties of the block
associated with sub b ?
is there any chance for this to work :
sub new_counter($start=0) {
return sub {
prop $cnt = $start; #this is opposite to state
#which sets trait of the block ,
#so presumably , this is created
#anew every time closure is created
return ++$cnt;
}
}
Interesting notion. However, given that $cnt is static, this seems
like one of those places where a good optimizer might always return the
same sub -- treating the entire thing as a constant expression.
So this is really a kind of semantic question: does the sub on the rhs
always imply run time consideration, or might a sub-expr be considered
a constant and be folded?
(This has interesting implictations for simple generators, since the
above syntax is short and sweet, while the usual make it an object
implementation looks stupid and ungainly.)
=Austin
our counter = new_counter ;
our another_counter = new_counter ;
print counter, counter,
another_counter, another_counter ;
#prints: 1 2 1 2
arcadi .
Re: is static? -- Question
Matthijs van Duin [EMAIL PROTECTED] writes:
On Sat, Mar 22, 2003 at 10:24:09PM +0200, arcadi shehter wrote:
sub a {
state $x;
my $y;
my sub b { state $z ; return $x++ + $y++ + $z++ ; }
return b; # is a \ before b needed?
}
will all b refer to the same $z ?
yes, they will
Are you sure about that. If state is declaring a lexically scoped
alias to a property of the block/sub, then each invocation of a will
generate a different block/sub b, which implies that the various b
instances won't share the same $z property.
does it mean that this is legitimate sub a {
state $x;
my $y;
state sub b { state $z ; return $x++ + $y++ + $z++ ; }
return b; # is a \ before b needed?
}
No, since you can't refer to $y in that sub (perl 5 actually allows
you to do that but gives a warning 'Variable %s will not stay
shared' - but I hope perl 6 will simply give a compile-time error)
Personally I would hope that it would correctly close over
$y. Especially if, as you claim, $z would be shared by all values of
b. Otherwise there's no way to get that particular behaviour.
--
Piers
Re: is static? -- Question
At 12:05 PM -0600 3/24/03, Jonathan Scott Duff wrote: On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote: The purpose of a state variable is to keep state across multiple calls to the same scope, so I'd say the proper semantics on closures is to treat the generation of a closure as a new block with new state properties. The most useful initialization semantics appear to be just in time, that is, on first actual call to the generated closure. START time in my previous message, though I'm still unhappy with that name. FIRST would be better, but that's taken (this week). ENTER? Possibly with a corresponding LEAVE? Argh, more semantics to deal with. Since I'd as soon not encourage this, how about INSTANTIATE? Nice and long and therefore discouraging. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: is static? -- Question
On Mon, Mar 24, 2003 at 01:37:01PM -0500, Dan Sugalski wrote: Since I'd as soon not encourage this, how about INSTANTIATE? Nice and long and therefore discouraging. :) Nothing a macro can't fix :-D -- Matthijs van Duin -- May the Forth be with you!
Re: is static? -- Question
On Mon, Mar 24, 2003 at 12:05:13PM -0600, Jonathan Scott Duff wrote: : On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote: : The purpose of a state variable is to keep state across multiple calls : to the same scope, so I'd say the proper semantics on closures is : to treat the generation of a closure as a new block with new state properties. : The most useful initialization semantics appear to be just in time, : that is, on first actual call to the generated closure. START time : in my previous message, though I'm still unhappy with that name. : FIRST would be better, but that's taken (this week). : : ENTER? Possibly with a corresponding LEAVE? Er, how would LEAVE detect that this was the *last* time you're ever going to call this routine? On the other hand, if we renamed FIRST and LAST to ENTER and LEAVE, then FIRST would become available to mean my very first time... Ahem. Let us not dwell on the Freudian aspects of all this... Larry
Re: is static? -- Question
At 10:34 AM -0800 3/24/03, Larry Wall wrote: On Mon, Mar 24, 2003 at 12:05:13PM -0600, Jonathan Scott Duff wrote: : On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote: : The purpose of a state variable is to keep state across multiple calls : to the same scope, so I'd say the proper semantics on closures is : to treat the generation of a closure as a new block with new state properties. : The most useful initialization semantics appear to be just in time, : that is, on first actual call to the generated closure. START time : in my previous message, though I'm still unhappy with that name. : FIRST would be better, but that's taken (this week). : : ENTER? Possibly with a corresponding LEAVE? Er, how would LEAVE detect that this was the *last* time you're ever going to call this routine? The only thing I can think of is to map it to the closure's DESTROY method and call it when the closure gets GC'd. On the other hand, if we renamed FIRST and LAST to ENTER and LEAVE, then FIRST would become available to mean my very first time... Ahem. Let us not dwell on the Freudian aspects of all this... Put down that cigar, Larry... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: is static? -- Question
Matthijs van Duin writes:
A nice example is:
sub a {
state $x;
my $y;
my sub b { return $x++ + $y++; }
return b; # is a \ before b needed?
}
Every call to sub a will return a different closure. The $x in
each closure all refer to the same variable. Each closure's $y
however is different and independent.
and what if
sub a {
state $x;
my $y;
my sub b { state $z ; return $x++ + $y++ + $z++ ; }
return b; # is a \ before b needed?
}
will all b refer to the same $z ?
does it mean that this is legitimate
sub a {
state $x;
my $y;
state sub b { state $z ; return $x++ + $y++ + $z++ ; }
return b; # is a \ before b needed?
}
and what does it mean ?
arcadi
Re: is static? -- Question
On Sat, Mar 22, 2003 at 10:24:09PM +0200, arcadi shehter wrote:
sub a {
state $x;
my $y;
my sub b { state $z ; return $x++ + $y++ + $z++ ; }
return b; # is a \ before b needed?
}
will all b refer to the same $z ?
yes, they will
does it mean that this is legitimate
sub a {
state $x;
my $y;
state sub b { state $z ; return $x++ + $y++ + $z++ ; }
return b; # is a \ before b needed?
}
No, since you can't refer to $y in that sub (perl 5 actually allows you to
do that but gives a warning 'Variable %s will not stay shared' - but I
hope perl 6 will simply give a compile-time error)
--
Matthijs van Duin -- May the Forth be with you!
Re: is static?
block. Perhaps we should just go with that: property $foo = 0; Or whatever word we choose, I don't care: prop $foo = 0; What about: prof $foo; $foo = 0; Is this equivalent to prof $foo = 0? If it is not, I would claim this to be a major violation of the principle of minor surprise. Maybe it would be saner to use: prop $foo is default(0); Otherwise the mythical unwarned user would think that $foo = 0 is executed on every call to the subroutine. -angel
Re: is static?
On Wed, Mar 19, 2003 at 01:18:48PM +0100, Angel Faus wrote:
: Is this equivalent to prof $foo = 0? If it is not, I would claim
: this to be a major violation of the principle of minor surprise.
:-)
: Maybe it would be saner to use:
:
: prop $foo is default(0);
I suspect you mean
prop $foo is init(0);
since default probably brings to mind //= semantics.
: Otherwise the mythical unwarned user would think that $foo = 0 is
: executed on every call to the subroutine.
Well, people *will* write
state $foo = 0;
The question is what that should mean, and which major set of people
we want to give the minor surprise to, and how much effort we want
to expend in training to avoid the surprise in the first place.
There's something to be said for keeping = as assignment outside
of sigs. But it's not clear whether that = is part of a sig...
And there really are a number of possible gradations of meaning:
state $foo = BEGIN { x() } # compile time
state $foo = CHECK { x() } # delayed compile time
state $foo = INIT { x() } # process start time
state $foo = START { x() } # on first call to func?
state $foo = FIRST { x() } # before each call (bad)
Most use will be to init with a compile-time constant, so I suppose
we could train people to just say:
state $foo ::= 0;
We don't have a word for START right now. It's somewhat equivalent to
state $foo //= 0
unless $foo gets undefined, I suppose.
Larry
Re: is static?
On Tue, Mar 18, 2003 at 01:53:59PM +1100, Damian Conway wrote: Function Assign unless... true||= defined //= exists h One is almost tempted by something like C??=. Well, almost. Nonono.. ??= is already for conditionals ofcourse :-) $a ??= $b :: $c; -- Matthijs van Duin -- May the Forth be with you!
Re: is static?
Smylers writes:
I don't find the Perl 5 approach ugly: I actually like it, because it does
exactly what it looks like it's doing, and doesn't require learning any
special syntax or keyword.
To have a variable exist beyond outside a sub, you declare it outside that
sub. To prevent that variable being accessed from anywhere else, you put
it in a block. It's simple yet provides the power you need, and it's
completely obvious what's going on.
I disagree that it's simple.
#! /usr/bin/perl -lw
use strict;
print id();
{
my $next = 17; # the first ID is 17
sub id {
return $next++;
}
}
Unfortunately, that completely fails, because the block containing the
declarator hasn't been evaluated the first time you call the sub. So you
get 0 as the answer (because ++ is sufficiently magic). It can be fixed by
making the block a BEGIN block, but suddenly it doesn't seem so simple. It
doesn't help that when you do this in a module, you probably don't see the
problem (because 'use Foo;' effectively does a require in a BEGIN block).
I'd argue that the requirement for BEGIN when you want a so-called-static
variable in your main program (and you define the sub after using it) makes
this approach less than simple.
In addition, I don't think it 'provides the power you need'. With the Perl5
approach, you can't have so-called-static variables scoped to anything other
than (a group of) subroutines -- they can't be scoped to a loop within a
sub, for example.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
survey page? [OT, was Re: is static?]
Merely for the one small thing I might possibly contribute Would it be useful to have a convenient place to do polls? I suspect there already is one somewhere, but I'm unaware of it. I don't want to undermine the authority of the core planning team, but thought they might like to have a simple way to survey for things that are more preference than major issue. I think all in all the correspondence on these issues has been pretty positive. I've seen a couple of people think about flames, and instead respond like adults. (It makes me happy. :) I was just wondering if it would be helpful if I set up a web page where the team could give me some alternatives to post, and folk could submit their preferences. I suspect that there are already plenty of ways to do that, and that my offer is weak, lol Personally, I prefer just hashing it out in the list. But it was a thought. Paul __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: is static?
$a ??= $b :: $c; Are you serious? That's completely unnecessary, but so is $a ||= 1; I *LIKE* it!!! =o) __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: is static?
Larry Wall writes:
Another question is whether a class containing methods containing
has would be confusing. The $s vs $.s distinction seems to help
a bit there. That would seem to imply that
class foo {
has $s;
has $.t;
}
declares a class attribute vs an instance attribute. But I don't
really like using the same keyword for two different scopes. And
I'd rather use the $s vs $.s distinction to indicate whether
accessor methods should be autogenerated, if we even allow has $s.
I can think of class attributes as persistent environment for
methods ( just code ) inside it .
its interesting that the problem we are discussing is just that -
supply a way to specify persistent environment for subroutines(s) (
and probably any closure ) -- but dont call it class ( and surrounding
block is also sort of nameless class ???).
its interesting that central to the objects is persistent data that
each object carries with it -- and code is in some sence secondary --
only a way to manipulate that data.
now, subrutines (not methods ), because they are not explicitely
associated with particular data are just code . they are born every
time they are called and die as soon as they finish. they dont have
state variables. and persistent otside environment is the only way to
keep this state.
probably its right that every persistent piece of environment for the
nearby subroutines should
be a class.
somehow this polarity between data and code is disturbing to me .
anyway -- practical suggestion :
class foo {
env $s;
has $.t;
}
sub foo() {
env $s ??= 0;
$s ++ ;
}
Still, if anything that is not a class considers itself to be a
class with a singleton object, then the distinction between
class variables and instance variables is moot, and has could
be taken to refer to that singleton object's values.
probably any block have to be able to have its private persistent
environment . and this is how code can make its step toward data.
arcadi
Re: is static?
sub foo() {
env $s ??= 0;
$s ++ ;
}
Although I still prefer calling it a trait on the data, I must admit
that I like env...perhaps even better than is retained.
Well, maybe not. But it's a cool thought that it's the environment.
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Re: is static?
Damian Conway wrote:
[...]
Hence, I would argue, one ought to simply mark it with a trait:
sub foo() {
my $s is retained = 0;
$s++;
}
Other possible trait names:
is kept
is preserved
is permanent
is reused
is saved
is stored
is restored
is irrepressible
I expected to see 'is persistent' as a possible name. Or does that
denote serialisation too much? Would people read
sub foo() {
my $s is persistent = 0;
$s++;
}
as meaning that the value of $s is saved across program invocations?
David
Re: survey page? [OT, was Re: is static?]
On Tuesday, March 18, 2003, at 06:49 AM, Paul wrote: Merely for the one small thing I might possibly contribute Would it be useful to have a convenient place to do polls? I suspect there already is one somewhere, but I'm unaware of it. I don't want to undermine the authority of the core planning team, but thought they might like to have a simple way to survey for things that are more preference than major issue. The (now very outdated!) POOC pages at http://cog.cognitivity.com/perl6/ have polls attached to each recipe. If nothing else, let me know and I can easily add a few. They contain the caveat that you must register to vote, as a way to prevent ballot stuffing. The POOC polls were an experiment. They tentatively demonstrated that (a) while hundreds of people visited those pages, pretty much NONE of them voted, and (b) we all like bitching a heck of a lot more than we like deciding. ;-) So dunno. We might try a few, but I'm not sure the results would be very useful. The design team has proven repeatedly that they have a terrific handle on the various issues, and there's been quite a few things that, if left to the prevailing popular opinion, would have led to distinctly the WRONG decision being made. The most productive (though not necessarily painless!) approach I've personally witnessed is when the design team muses about ideas, the list argues back and forth for a while, then the design team comes down with an Edict From On High that takes those issues into account. If people are *really* convinced it's wrong, the argument continues for a while, but it usually gets shut down when most of the list is satisfied that all the arguments have been heard. As much as people hated it, I think the P6 Operators thread was *quite* beneficial. It lead to the saving of ^ xor, and the hyper syntax, and quite a few other improvements, and got things pinned down squarely. I wouldn't mind seeing more of that level of disciplined debate, but it's difficult to pull off. MikeL
Re: is static?
Damian wrote: Hence, I would argue, one ought to simply mark it with a trait: FWIW, I personally think this is _absolutely_ the right approach. Using a trait is a very visible, very obvious way to say what's going on that is probably easier to remember than adding another keyword to the [my|our|temp|let] group. While I, too, immediately understood what 'has' meant, I can't help but feel many people won't get it. As others have pointed out, the problem with 'static' is not only that (a) it has too many C++ meanings, but (b) the word itself implies 'constant', not 'persistent'. I would really, really like for us to not use that already-abused word. is retained is preserved is kept These three, I think, show the most promise. Or the linguistically dubious is once, maybe. The others like is saved/stored/restored might be taken for serialization-style persistence. David Landgren wrote: I expected to see 'is persistent' as a possible name. Or does that denote serialisation too much? I think so... I thought about that too, but I think persistent is becoming synonymous with serialized stored these days. MikeL
Re: is static?
--- Uri Guttman [EMAIL PROTECTED] wrote:
DC == Damian Conway [EMAIL PROTECTED] writes:
DC Larry wrote:
: sub foo() {
: has $s //= 0; : $s ++ ;
: }
: : print foo, foo, foo;
DC Futhermore, this approach opens another vermiferous can. I
DC would argue that C//= is the wrong way to initialize it,
DC since that effectively prevents Cundef values from being
DC used with such variables.
so don't put the //= 0 there and it will be undef. in fact why would
the // be needed if you can just do:
has $s = 0 ;
also i think has implies a class level attribute here which is not
the
same in my mind as
my $s is static = 0 ;
which is private to the sub (and any nested subs).
DC Hence, I would argue, one ought to simply mark it with a trait:
my use of is static was a trait. i chose 'is' for that reason. it was
a compile time trait that the var was to be allocated (and optionally
initialized) only once and it would be not on the stack and would
keep
its value between calls to foo().
DC sub foo() {
DC my $s is retained = 0;
DC $s++;
DC }
DC Other possible trait names:
DC is kept
DC is preserved
DC is permanent
DC is reused
DC is saved
DC is stored
DC is restored
DC is irrepressible
DC Yes, the names are all considerably longer than a Chas
DC declarator, but I see that as a bonus. Persistent behaviour by
DC a lexical is unusually enough that it ought to be loudly and
DC clearly marked.
DC Oh, and note that I very deliberately did not suggest
DC Cis static!
but that is a good name IMO. $s is static vs dynamic (on the
stack). the other overloaded meanings of static from c/c++ are
baggage we can drop.
What other meanings?
static int foo = 0; /* File scope private symbol. */
static int func() /* File scope private symbol. */
{
static char buf[100]; /* Function scope permanent lexical symbol. */
/* ... */
}
From where I sit, the static-inside-a-function meaning is the only
overloaded one, in that it suggests that the lexical symbol with
function scope also has file-level allocation (which in fact it does in
most implementations).
I see two uses for static being discussed:
1: static as a synonym for is private:
our $shared is private = 0;
sub x() { ... $shared ... }
sub y() { ... $shared ... }
And let's face it -- Cour means common, which is just exactly what
Cstatic means. Maybe we should bring back common as a keyword
-since formats are out of core, FORTRAN is underrepresented in P6.
2: static as a synonym for call-spanning private symbol:
sub x()
{
static $x = 0;
print $x++;
}
x; # prints 0
x; # prints 1
There are some interesting questions that haven't been asked about
scope yet.
For instance: Is there an incompatibility between package scope and
program scope?
If I say
macro static($name, $traits) is parsed(/however/)
{
$OUTER_SCOPE::declare($name, $traits);
}
Then there's the suggestion that unloading a package would, for static
declarations with package scope, destroy the variable.
Whereas if static points to program scope (e.g., by inserting a
globally scoped symbol with a mangled name) then it won't be destroyed
when the package is unloaded. Viz:
macro static($name, $traits) is parsed(/however/)
{
::declare(__ ~ Package() ~ __ ~ Function() ~ __ ~ $name,
$traits);
}
So, what should static (function scope, call-spanning) variables
actually do?
=Austin
Re: is static?
--- Michael Lazzaro [EMAIL PROTECTED] wrote: Damian wrote: Hence, I would argue, one ought to simply mark it with a trait: FWIW, I personally think this is _absolutely_ the right approach. Hear him! I don't think anyone disagrees that staticness is a trait. (After all, even the folks that pull for static will be pulling for just that -- a storage class specifier.) As others have pointed out, the problem with 'static' is not only that (a) it has too many C++ meanings, but (b) the word itself implies 'constant', not 'persistent'. I would really, really like for us to not use that already-abused word. Frankly, this is a weak argument. Especially, as Larry points out, since this will be one of the first macros out there. is retained is preserved is kept These three, I think, show the most promise. Or the linguistically dubious is once, maybe. The others like is saved/stored/restored might be taken for serialization-style persistence. Of the three, kept has problems since we're looking at a keep verb someplace. I'd recommend preserved. David Landgren wrote: I expected to see 'is persistent' as a possible name. Or does that denote serialisation too much? I think so... I thought about that too, but I think persistent is becoming synonymous with serialized stored these days. Yeah. Persistent is accurate, but has been preempted for use in the offline-storage context of persistence. =Austin
Re: survey page? [OT, was Re: is static?]
Michael Lazzaro [EMAIL PROTECTED] writes: As much as people hated it, I think the P6 Operators thread was *quite* beneficial. It lead to the saving of ^ xor, and the hyper syntax, and quite a few other improvements, and got things pinned down squarely. I wouldn't mind seeing more of that level of disciplined debate, but it's difficult to pull off. What I hated about the P6 Operators thread was the repetitiveness. And having to summarize it. That was definitely painful. -- Piers
Re: is static?
Damian Conway writes:
on the second thought : its quite strange ( though cute ) that
currently the only way to make lexical persistent variable is based on
garbage collector. it is referenced -- hence it is kept.
may be it have to be more explicit like that
sub counter(){
daemon $s;#( or : my $s is daemon; )
INIT{ $s = 0 } ; # ???
$s++;
}
or
sub counter()
will have { BigInt $s } # have actually populate attributes of
# the associated daemon object
will init { $s = 0} # sort of constructor for the daemon
{
$s++;
}
I think that something like
daemon $s ;
makes it clear that $s keeps its value somwere in the shadow .
arcadi
Re: is static?
Larry Wall writes:
I guess the real question would be, is it an overall simplification to
allow has anywhere? There *is* an object out there representing each
abstract closure (pre-instantiation), but it's a bit of a stretch from
Every block is a closure to Every block is a closure that is also
an object except that the object in question doesn't participate in
the closure's closure, as it were.
On the other hand, it's the block itself that is that abstract
pre-closure object, so running it the other way would mean stretching
our minds into thinking has always sets block properties, and that
every object is a funny kind of block.
after reading this I realize that current meaning of has is really
quite strange... I would rather call it serve ( see below )
one can think of class / object attributes in the following way (
soryy, may be its too handwaving, but I have in mind plan9 notion of
every process having its own vision of the namespace , ( and every
block / closure in perl is sort of process ) ) :
class attributes : persistent lexical variables .
Class serve the same copy of it to all its
subs/methods
object attributes : persistent lexical variables .
Class _multiplexes_ them to each
object and each object have its own private instance of it .
so class is in some sence a server of a ( lexical ) namespace .
Class Foo {
has $foo ; # persistent lexical variable -- class attribute
serve $bar; # every instance of Class Foo will have its own private
# version of $bar -- object attribute
# or may be this.
multiplex $bar; # but this is longer
...
}
so now it is clear _who_ has and serve : the surrounding block (
marked by Class Foo ) _has_ ( persistent ) $foo lexical and it _serve_
private $bar instance to each object .
since its all about ( lexical ) namespaces ...
method new return an object to which class serve a private
copy of all variable marked by serve ( or multiplex ??? )
I dont know how classes and objects work now inside , but probaly
in the spirit of class is just any block which have some sort
of label / mark ( and Class Foo is just one of that kind ) may have a
new method . in that case the thing returned have private copyes of
variables labeled by serve and access to all has variable and
methods/subs defined inside.
counter: {
has $a;
serve $.cnt;
my sub count(){ .cnt++ }
my sub new() {
$a++ ; # a counter of counters
ret new counter ; # this a default new method
}
}
$x = counter.new ;
$x.count ;
just ( veryy fuzzy ) thoughts ...
arcadi
Re: is static?
on the second thought : its quite strange ( though cute ) that
currently the only way to make lexical persistent variable is based on
garbage collector. it is referenced -- hence it is kept.
this brings to the following : every subroutine may have a
daemon object of some sort associated with it , which will keep
state of the subroutine. so every subroutine is a method of its
daemon object . actually , one can think of any subroutine that way
, whatever the way the persistency of these
variables is actually realized.
it seems that there have to be a clear visual
difference between my variables and
these daemon varibles.
so :
sub counter(){
daemon $s;( or : my $s is daemon; )
INIT{ $s = 0 } ;
$s++;
}
or
sub counter()
will have { BigInt $s } # have actually populate attributes of
# the associated daemon object
will init { $s = 0} # sort of constructor for the daemon
{
$s++;
}
I think that something like
daemon $s ;
makes it clear that $s is an attribute of an object associated with
that subroutine.
and subroutine may be probably replaced by closure
Class Foo {
our $a ;
my $b ;
daemon $c ;
}
arcadi
Re: is static?
Larry Wall writes:
Larry Wall writes:
I guess the real question would be, is it an overall simplification to
allow has anywhere? There *is* an object out there representing each
abstract closure (pre-instantiation), but it's a bit of a stretch from
Every block is a closure to Every block is a closure that is also
an object except that the object in question doesn't participate in
the closure's closure, as it were.
after reading this I realize that current meaning of has is really
quite strange... I would rather call it serve ( see below )
one can think of class / object attributes in
the following way ( I have in mind plan9 notion of every process
having its own vision of the namespace , ( and every block / closure
in perl _is_ in some sence process ) ) :
object attributes : persistent lexical variables .
Class _multiplexes_ them to each
object and each object have its own private instance of it .
class attributes : persistent lexical variables .
Class serve the same copy of it to all its
subs/methods
so class is in some sence a server of a namespace .
Class Foo {
has $foo ; # persistent lexical variable
serve $bar; # every instance of Class Foo will have its own private
# version of $bar
# or may be this.
multiplex $bar;
...
}
so now is clear _who_ has and serve : the surrounding closure (
marked by Class Foo _has_ ( persistent ) $foo lexical and it _serve_ $bar
instance to each object .
since its all about ( lexical ) namespaces ...
method new return an object to which class serve its ( own ) private
copy of all variable marked by serve ( or multiplex ??? )
I dont know how classes and objects work now inside , but probaly
in the spirit of class is just any block which have some sort
of label / mark ( and Class Foo is just one of that kind ) may have a
new method . in that case the thing returned have private copyes of
variables labeled by serve and access to all has variable and
methods/subs defined inside.
counter: {
has $a;
serve $.cnt;
my sub count(){ .cnt++ }
my sub new() { $a++ ; ret new counter }
}
$x = counter.new ;
$x.count ;
just ( veryy fuzzy ) thoughts ...
sorry for this mess ...
arcadi
Re: is static?
On Mon, Mar 17, 2003 at 10:03:29PM -0500, Uri Guttman wrote: : but that is a good name IMO. $s is static vs dynamic (on the stack). the : other overloaded meanings of static from c/c++ are baggage we can drop. Gee, if static var makes a subroutine stateful, maybe it's just: state $s = 0; Larry
Re: is static?
Larry wrote:
Gee, if static var makes a subroutine stateful, maybe it's just:
state $s = 0;
That's very nice, and (unlike Chas) it's verbose enough.
It would also work well for creating class-private shared state.
And for things like loop counters:
while @list {
(state $count = 0)++;
process(splice @list, 0, rand(@list));
}
print Took $count repetitions to process list\n;
Damian
Re: is static?
On Tue, Mar 18, 2003 at 01:53:59PM +1100, Damian Conway wrote:
: Larry wrote:
:
: : sub foo() {
: : has $s //= 0;
: : $s ++ ;
: : }
: :
: : print foo, foo, foo;
:
: This is interesting, but I think it would be a mistake to give Chas two
: unrelated meanings...
I think it's also a mistake to give Cmy two unrelated meanings.
These are not lexically-scoped variables any more than our
variables are, and the fact that they can happen accidentally in
Perl 5 as persistent lexically scoped variables is, er, accidental.
They are lexically scoped aliases to properties of the current block.
Perhaps we should just go with that:
property $foo = 0;
Or whatever word we choose, I don't care:
prop $foo = 0;
have $foo = 0;
this $foo = 0;
here $foo = 0;
block $foo = 0;
static $foo = 0;;-)
But my gut feeling says if it's scoped differently, it had better
have a different introducer. Scope is too important a distinction
to relegate to a trait of the variable, even though it may be one
from a metadata point of view. Particularly since we may want it
to warp that assignment notation into an INIT {} or some such.
Actually has/have is kinda cute:
Each object has...
We all have...
where we all could be taken to mean either all objects or all
invocations of this block. We could use this for class attributes
and they wouldn't show up globally. On the other hand the class's
class object isn't quite the same thing as the class's init block.
But we wouldn't have to tell people that...
Whatever. Important thing is that it has to be out front if it's
a different scope, even if it's not as important a scope as my.
When you think about it, that's why we have brought method,
submethod, multi, etc. out front too. These are just scoping
distinctions important to the dispatcher. But it's important to
human understanding to see that at the beginning. Submethods aren't
as important as either subs or methods, but it would be a mistake to
make submethodism a mere property of either methods or subs.
In the same way, I think it's a mistake to see a block attribute as
either our or my.
Just don't anyone suggest submy...
Larry
Re: is static?
LW == Larry Wall [EMAIL PROTECTED] writes: LW On Mon, Mar 17, 2003 at 10:03:29PM -0500, Uri Guttman wrote: LW : but that is a good name IMO. $s is static vs dynamic (on the stack). the LW : other overloaded meanings of static from c/c++ are baggage we can drop. LW Gee, if static var makes a subroutine stateful, maybe it's just: LW state $s = 0; so that becomes a keyword instead of a trait? or is it sugar that the compiler uses to keep the var around? also is it lexical like my? it should be as otherwise you could just use our. i still like static but that is old c habit for me. in any case others have shown good reason to have something like this vs. the p5 outer block declare. the BEGIN requirement for init before call is something i have run into and is annoying. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: is static?
Larry wrote:
I think it's also a mistake to give Cmy two unrelated meanings.
Yes. I fully concede this point. A declarator is the way to go.
They are lexically scoped aliases to properties of the current block.
Err. Properties or traits? Presumably traits, since they're declared at
compile-time. This feeds rather interestingly into my suggestion that a
Cwhere modifier be a way of setting properties on the call. See below.
Perhaps we should just go with that:
property $foo = 0;
Or whatever word we choose, I don't care:
prop $foo = 0;
I could certainly live with this.
And if we had Cwhere as a mechanism for setting the value of such traits
during a call, we'd get the rather tidy:
foo('bar') where error('fatal');
sub foo($arg) {
return 1 if $arg eq 'bar'
given prop $error {
when 'fatal' { die horribly }
when 'verbose' { warn direly; continue; }
default{ return 0 }
}
}
have $foo = 0;
Please, no. Far too close to Chas.
this $foo = 0;
here $foo = 0;
block $foo = 0;
static $foo = 0;;-)
I still think Cprop is the way to go.
Actually has/have is kinda cute:
Each object has...
We all have...
Yes, cute is exactly the right word for it.
sound of alarm bells ringing
;-)
Damian
Re: is static?
Joe Gottman writes:
Not really. A variable declared with our can be accessed from
anywhere in the program, just by redeclaring it or calling it with the
package:: syntax.A variable declared with my can be accessed outside
its scope only if the user returns a reference to it. A static variable
should be like a my variable except that it is only initialized once and
is not destroyed when it goes out of scope.
Joe Gottman
it's interesting that has have more or less required scope -- its
visible only from object methods and it keeps its value , so maybe
something like this :
sub foo() {
has $s //= 0;
$s ++ ;
}
print foo, foo, foo;
--
arcadi
Re: is static?
Uri Guttman writes: talking about nested subs brought up another related idea, static (not on the stack) lexicals inside subs. the current solution in p5 is to declare them in a surrounding block and that is slightly ugly. and if you want multiple subs to share them they all have to be in that block. I don't find the Perl 5 approach ugly: I actually like it, because it does exactly what it looks like it's doing, and doesn't require learning any special syntax or keyword. To have a variable exist beyond outside a sub, you declare it outside that sub. To prevent that variable being accessed from anywhere else, you put it in a block. It's simple yet provides the power you need, and it's completely obvious what's going on. Obviously I'd be free to continue doing it this way in Perl 6, but if there's an explicit language feature for doing this then it'd probably make my code seem odd to do so. And merely by having such a feature it's again increasing the amount of Perl that has to be learnt for reading other people's code. Smylers
Re: is static?
On Sun, Mar 16, 2003 at 04:22:27PM +0200, arcadi shehter wrote:
: it's interesting that has have more or less required scope -- its
: visible only from object methods and it keeps its value , so maybe
: something like this :
:
: sub foo() {
: has $s //= 0;
: $s ++ ;
: }
:
: print foo, foo, foo;
That's a *very* interesting idea, but I would have to convince myself
that we're not merely overloading has the way C overloaded static.
I suppose I could convince myself that there is some permanent subish
descriptor object that can have the attribute.
Another question is whether a class containing methods containing
has would be confusing. The $s vs $.s distinction seems to help
a bit there. That would seem to imply that
class foo {
has $s;
has $.t;
}
declares a class attribute vs an instance attribute. But I don't
really like using the same keyword for two different scopes. And
I'd rather use the $s vs $.s distinction to indicate whether
accessor methods should be autogenerated, if we even allow has $s.
Still, if anything that is not a class considers itself to be a
class with a singleton object, then the distinction between
class variables and instance variables is moot, and has could
be taken to refer to that singleton object's values.
I guess the real question would be, is it an overall simplification to
allow has anywhere? There *is* an object out there representing each
abstract closure (pre-instantiation), but it's a bit of a stretch from
Every block is a closure to Every block is a closure that is also
an object except that the object in question doesn't participate in
the closure's closure, as it were.
On the other hand, it's the block itself that is that abstract
pre-closure object, so running it the other way would mean stretching
our minds into thinking has always sets block properties, and that
every object is a funny kind of block.
I dunno. Probably people wouldn't think about has on that level.
People are pretty good at overloading resolution without finding
deep connections between the different uses of the word.
Larry
Re: is static?
DC == Damian Conway [EMAIL PROTECTED] writes:
DC Larry wrote:
: sub foo() {
: has $s //= 0; : $s ++ ;
: }
: : print foo, foo, foo;
DC Futhermore, this approach opens another vermiferous can. I would argue
DC that C//= is the wrong way to initialize it, since that effectively
DC prevents Cundef values from being used with such variables.
so don't put the //= 0 there and it will be undef. in fact why would the
// be needed if you can just do:
has $s = 0 ;
also i think has implies a class level attribute here which is not the
same in my mind as
my $s is static = 0 ;
which is private to the sub (and any nested subs).
DC Hence, I would argue, one ought to simply mark it with a trait:
my use of is static was a trait. i chose 'is' for that reason. it was a
compile time trait that the var was to be allocated (and optionally
initialized) only once and it would be not on the stack and would keep
its value between calls to foo().
DC sub foo() {
DC my $s is retained = 0;
DC $s++;
DC }
DC Other possible trait names:
DC is kept
DC is preserved
DC is permanent
DC is reused
DC is saved
DC is stored
DC is restored
DC is irrepressible
DC Yes, the names are all considerably longer than a Chas declarator,
DC but I see that as a bonus. Persistent behaviour by a lexical is
DC unusually enough that it ought to be loudly and clearly marked.
DC Oh, and note that I very deliberately did not suggest Cis static!
but that is a good name IMO. $s is static vs dynamic (on the stack). the
other overloaded meanings of static from c/c++ are baggage we can drop.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: is static?
Uri Guttman wrote: but that is a good name IMO. $s is static vs dynamic (on the stack). I don't think that names that describe implementation are nearly as good as names that describe behaviour. Not in a Very High Level Language, like Perl. other overloaded meanings of static from c/c++ are baggage we can drop. As is this meaning. ;-) Damian
Re: is static?
DC == Damian Conway [EMAIL PROTECTED] writes: DC Uri Guttman wrote: but that is a good name IMO. $s is static vs dynamic (on the stack). DC I don't think that names that describe implementation are nearly as DC good as names that describe behaviour. Not in a Very High Level DC Language, like Perl. to me static IS a behavior. its value is static from call to call. other overloaded meanings of static from c/c++ are baggage we can drop. DC As is this meaning. ;-) none of your alternative names struck a bell with me. i sense your thesaurus powers are weakening, obi-wan. maybe some klingon or latin term would be better? so we shall agree to disagree until we can have a proper duel. on the beach at boca, perhaps? :-) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: is static?
to me static IS a behavior. its value is static from call to call. other overloaded meanings of static from c/c++ are baggage we can drop. I can see the potental for alot of ambiguaty between the meaning of 'is Static' and 'is Constant' (unless your a c/c++ programmer so your mind is already warped). IF we get a 'is Static' does that mean we get a 'is Automatic' too? :) -J --
Re: is static?
Uri Guttman wrote: talking about nested subs brought up another related idea, static (not on the stack) lexicals inside subs. Doesn't Cour give you this? Dave. -- http://dave.whipp.name
Re: is static?
- Original Message - From: Dave Whipp [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 15, 2003 1:35 PM Subject: Re: is static? Uri Guttman wrote: talking about nested subs brought up another related idea, static (not on the stack) lexicals inside subs. Doesn't Cour give you this? Not really. A variable declared with our can be accessed from anywhere in the program, just by redeclaring it or calling it with the package:: syntax.A variable declared with my can be accessed outside its scope only if the user returns a reference to it. A static variable should be like a my variable except that it is only initialized once and is not destroyed when it goes out of scope. Joe Gottman
Re: is static?
Doesn't Cour give you this? Not really. A variable declared with our can be accessed from anywhere in the program, just by redeclaring it or calling it with the package:: syntax.A variable declared with my can be accessed outside its scope only if the user returns a reference to it. A static variable should be like a my variable except that it is only initialized once and is not destroyed when it goes out of scope. Better to make it a my() with an accessor, and have everything use the accessor... but it *does* slow things down. __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com
Re: is static?
On Sat, Mar 15, 2003 at 08:05:03PM -0500, Joe Gottman wrote:
:
: - Original Message -
: From: Dave Whipp [EMAIL PROTECTED]
: To: [EMAIL PROTECTED]
: Sent: Saturday, March 15, 2003 1:35 PM
: Subject: Re: is static?
:
:
: Uri Guttman wrote:
: talking about nested subs brought up another related idea, static (not
: on the stack) lexicals inside subs.
:
: Doesn't Cour give you this?
:
:
:Not really. A variable declared with our can be accessed from
: anywhere in the program, just by redeclaring it or calling it with the
: package:: syntax.A variable declared with my can be accessed outside
: its scope only if the user returns a reference to it. A static variable
: should be like a my variable except that it is only initialized once and
: is not destroyed when it goes out of scope.
It is likely that if we have is static, the compiler would translate
my $pi is static = 3
to something like
our $foo__Xdeadbeef will init {.set(3)}
I really hate the word static though, which is why I suggested an alternative
once of something like
our $foo is unique;
where is unique (or whatever) monkeys with the name to make it unique. Then
the program representation is closer to what's actually going on.
On the other hand, is static would be instantly recognizable to
C programmers. Maybe they're due for a sop...
It's not like someone isn't going to implement is static the moment
our back is turned anyway...
Larry
Re: is static?
Larry Wall wrote: On the other hand, is static would be instantly recognizable to C programmers. Maybe they're due for a sop... Bah! No sop for them! Cstatic has so many overloaded meanings in C/C++ that who's to say this meaning is really the one that's worth codifying? (I always felt this particular C++ thing was the CS equiv of mind if we call you Bruce?) Besides, you already gave them a huge sop when you have back their xor. How much more can we -- I mean (*ahem*) they -- ask for? MikeL
Re: is static?
LW == Larry Wall [EMAIL PROTECTED] writes:
LW It is likely that if we have is static, the compiler would translate
LW my $pi is static = 3
LW to something like
LW our $foo__Xdeadbeef will init {.set(3)}
LW I really hate the word static though, which is why I suggested
LW an alternative once of something like
LW our $foo is unique;
well, that isn't the same even if you can't guess the name. the name is
still in the symbol table and could be found by scanning the tables. but
then again, we are allowing introspection of my vars too with
caller(). :)
LW where is unique (or whatever) monkeys with the name to make it
LW unique. Then the program representation is closer to what's
LW actually going on.
unique doesn't trigger anything to me. static (as the opposite of
dynamic on the stack) is what i am looking for. c used it inside subs
and outside and to mean different things. in perl it would only be
useful inside a sub to mean it staticly stays the same var from call to
call. we use my in a file scope for the other c use of static so there
is no confusion. in fact i would claim is static should be a compile
time (semantic checking time?) error on a var outside a sub.
LW On the other hand, is static would be instantly recognizable to
LW C programmers. Maybe they're due for a sop...
LW It's not like someone isn't going to implement is static the moment
LW our back is turned anyway...
yep. to many that name already does have a well known (if
slightly^Wheavily overloaded) meaning. we would use only one of those
meanings and stick with it.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
