is static?
Uri Guttman
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.
so a simple is static trait on those variables would allow them to be
declared inside the sub itself. an = or is default would work only the
first time the sub is called or at compile time.
and any subs that would want to share those vars could be nested inside
the same parent sub.
the p5 way should still work if you need the multiple subs to be all
visible (in whatever scope).
maybe i missed this one in apoc6 too. my brane is hurting too much to
do a proper search. :)
uri
--
Uri Guttman ------ u...@stemsystems.com -------- 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
Dave Whipp
> talking about nested subs brought up another related idea, static (not
> on the stack) lexicals inside subs.
Doesn't C<our> give you this?
Dave.
--
http://dave.whipp.name
Joe Gottman
----- Original Message -----
From: "Dave Whipp" <da...@whipp.name>
To: <perl6-l...@perl.org>
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 C<our> 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
Paul
>
> 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
Larry Wall
:
: ----- Original Message -----
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
Mlazzaro
> 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! C<static> 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
Uri Guttman
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.
Arcadi Shehter
>
> 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
Smylers
> 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
Larry Wall
: 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
Damian Conway
> : sub foo() {
> : has $s //= 0;
> : $s ++ ;
> : }
> :
> : print foo, foo, foo;
This is interesting, but I think it would be a mistake to give C<has> two
unrelated meanings -- and I think we'd have to stretch our concepts of objects
a little too far to consider these two meanings related. (Yes, *I* can easily
stretch my mind to envisage the "attributes of a subroutine", but should
everyone else have to?)
Futhermore, this approach opens another vermiferous can. I would argue that
C<//=> is the wrong way to initialize it, since that effectively prevents
C<undef> values from being used with such variables.
Curiously we have already felt the lack of an assign-on-non-existence
initializer elsewhere...for optional parameters. Perhaps we have not yet have
gone far enough in mirroring the various levels of reality that a value can
aspire to:
Function Assign unless...
true ||=
defined //=
exists hmmmmmmmm
One is almost tempted by something like C<??=>. Well, almost.
But back to the topic of discussion. I have argued for some considerable time
that this "static variable" *functionality* is extremely useful and much
tidier than the current alternative:
{ my $s = 0;
sub foo() {
$s++;
}
}
But using Yet Another Declarator is, I believe, the wrong approach.
The variable $s is a regular lexical variable in every respect, save one: it
has the unusual trait that is retained from call to call of its surrounding code.
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
Yes, the names are all considerably longer than a C<has> declarator, but I see
that as a bonus. Persistent behaviour by a lexical is unusually enough that it
ought to be loudly and clearly marked.
Oh, and note that I very deliberately did not suggest C<is static>!
Damian
Uri Guttman
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 C<undef> 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 C<has> 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 C<is 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.
Damian Conway
> 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
Uri Guttman
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? :-)
Joshua Hoblitt
> >> 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
--
Matthijs Van Duin
> Function Assign unless...
>
> true ||=
> defined //=
> exists hmmmmmmmm
>
>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!
Aaron Crane
> 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/
Paul
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
Paul
Are you serious?
That's completely unnecessary, but so is
$a ||= 1;
I *LIKE* it!!! =o)
Arcadi Shehter
> 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
Paul
> 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".
David Landgren
[...]
> 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
Michael Lazzaro
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
Michael Lazzaro
> 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
Austin Hastings
>>>>> "DC" == Damian Conway <dam...@conway.org> 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 C<undef> values from being
DC> used with such variables.
> has $s = 0 ;
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> C<is 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 -- C<our> means "common", which is just exactly what
C<static> 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
Austin Hastings
--- Michael Lazzaro <mlaz...@cognitivity.com> 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
Piers Cawley
> 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
Arcadi Shehter
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
Arcadi Shehter
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
Arcadi Shehter
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
Arcadi Shehter
>
> 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
Larry Wall
: 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
Damian Conway
> Gee, if static var makes a subroutine stateful, maybe it's just:
>
> state $s = 0;
That's very nice, and (unlike C<has>) 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
Larry Wall
:
: >: sub foo() {
: >: has $s //= 0;
: >: $s ++ ;
: >: }
: >:
: >: print foo, foo, foo;
:
: This is interesting, but I think it would be a mistake to give C<has> two
I think it's also a mistake to give C<my> 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
Uri Guttman
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.
Damian Conway
> I think it's also a mistake to give C<my> 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
C<where> 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 C<where> 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 C<has>.
> this $foo = 0;
> here $foo = 0;
> block $foo = 0;
> static $foo = 0; ;-)
I still think C<prop> 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
Angel Faus
>
> 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
Larry Wall
: Is this equivalent to "prof $foo = 0"? If it is not, I would claim
:-)
: 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
Arcadi Shehter
>
> I think it's also a mistake to give C<my> 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;
>
in this example
sub a {
state $x ;
my $y ;
my sub b { ... } ;
...
}
how "my sub b" is different from "state $x" from the point of view of
scope ?
when scope of "sub a" is left, $y variable is notifyed about it --
its value is lost .
is "sub b" somehow notifyed when scope of "sub a" is left. ???
I mean , for example , that one of its ( sub b ) BIGLETTER block can
fire and change its ( sub b ) state variables. Is there some crucial
difference between scope of $y and &b ?
in other words,
what is a difference between where $x , $y and &b lives .
and how these places behave dynamically -- when lexical scope is
entered or left. ???
>
> 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...
>
do I understand correctly , that "has" introduce a block property that
is used by "new"-like methods ??? or it is a property of class that
"posess" that block. ???
actually , the same question about "state" - does it introduce the
property of an enclosing block or a property of a sub "posessing" that
block -- or am confused and these two things are the same ???
> 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"...
do you mean here a variable that is seen only in the current lexical
scope but invisible in any of inner lexical scopes. ??? ( or this was
just a joke ?...)
thanks,
arcadi
Matthijs Van Duin
>in this example
>
>sub a {
> state $x ;
> my $y ;
> my sub b { ... } ;
> ...
>}
>
>how "my sub b" is different from "state $x" from the point of view of
>scope ?
Actually, all three have the same scope, but they have different lifetime.
Each invocation of sub a has fresh $y and &b variables, but keeps the same
$x every time.
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.
Arcadi Shehter
>
> 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.
>
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
Matthijs Van Duin
> 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)
Arcadi Shehter
>
> >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)
so, the only problem here is that the closure of "sub b" will be
evaluated only once and the following exemple will work ?
sub a {
state $x;
state sub b { ... } ;
my $y;
&b = sub { state $z ; return $x++ + $y++ + $z++ ; }
return &b; # is a \ before &b needed?
}
also , is that correct ?
sub new_counter($start=0) {
return sub {
state $cnt = $start;
return ++$cnt;
}
}
our &counter = new_counter ;
our &another_counter = new_counter ;
print counter, counter, another_counter, another_counter ;
#prints: 1, 2, 3, 4
thanks,
arcadi
Arcadi Shehter
>
> 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 .
Austin Hastings
--- arcadi shehter <fear...@figaro.weizmann.ac.il> 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
Piers Cawley
> 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
Matthijs Van Duin
>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.
I've been thinking about it, but it depends on semantics. I personally
don't think that the behaviour of "state" inside a block should depend
on whether or not that block uses lexical variables of the surrounding
scope. So I think 'state' should - semantically speaking - be a property
of the surrounding lexical block, and therefore be shared amoung all
instances of &b in this situation.
>>> state $x;
>>> my $y;
>>> state sub b { state $z ; return $x++ + $y++ + $z++ ; }
>
>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.
it can't close over $y: b is state, so it's the same for each invocation of
the sub, while $y is different for each invocation.
if you want b to close of $y, making b state makes no sense... you should
use 'my sub b' instead in that case.
Larry Wall
:
: --- arcadi shehter <fear...@figaro.weizmann.ac.il> wrote:
: > 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.
Depends on when the initialization is done.
: 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?
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).
A START-time initialization would certainly prevent the optimizer from
returning a constant closure above, whereas an init done at BEGIN,
CHECK, or INIT time would result in a constant closure, or maybe an
error if the compiler determines that you're initializing with a
value that is undefined before the first call.
: (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.)
Certainly.
Larry
Jonathan Scott Duff
> 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?
-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu
Dan Sugalski
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
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Matthijs Van Duin
>Since I'd as soon not encourage this, how about INSTANTIATE? Nice and
>long and therefore discouraging. :)
Nothing a macro can't fix :-D
Larry Wall
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
Dan Sugalski
>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...
Arcadi Shehter
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
Michael Lazzaro
On Wednesday, March 19, 2003, at 08:30 AM, Larry Wall wrote:
> 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...
<snip>
> 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.
That's where that particular thread ended -- from there, it diverged
into a subthread about C<state> behavior within nested subs/closures.
Ignoring the closure parts, and getting back to the more generic idea
of C<state>:
Assuming we have a static-like scope called C<state>, one can
definitely see the use of having an assignment variant for "not yet
initialized" or "doesn't yet exist", the proposed spelling of which was
C<::=>. That gives us:
state $baz = 0;
state $baz ::= 'blah'; # if doesn't "exist" or not
"initialized"
state $baz //= 'blah'; # if $baz is undefined
state $baz ||= 'blah'; # if $baz is false
state $baz &&= 'blah'; # if $baz is true
state $baz ??= 'blah' :: 'blarp'; # if $baz is true|false
Of course, for C<state> scoped vars, C<::=> is the only one that makes
much sense, and C<::=> doesn't make much sense for lexical vars. (One
could argue that C<=> should just mimic C<::=> for C<state>-scoped, but
I'm not going to.)
---
OK, so tying that back in to A6... people have suggested extending //=
and/or ::= into signatures. The more I think about it, the better I
like this approach, and the more justified it seems. Right now we have:
sub foo($x = 0) {...} # same as C<$x is default(0)>
to set the $x param to 0 _if it was not specified by the caller_. But
it is certainly possible to extend the initialization capabilities to
be more robust:
sub foo($x = 'blah') {...} # wrong: use one of the below
sub foo($x ::= 'blah') {...} # same as C<$x is default('blah')>
sub foo($x //= 'blah') {...} # sets $x whenever $x is undefined
sub foo($x ||= 'blah') {...} # sets $x whenever $x is false
The utility of this is that it gives the signature significantly more
control over the initialization of individual parameters, regardless of
the actual function/method "implementation". Maybe sigs _should_ be
able to make certain assertions about their arguments, and even
adjustments to them, before they hit the 'real' implementation.
There has been some debate about the power that sigs should be given.
Specifically, I'm thinking of the old "how do you make an assertion
upon an argument" debate of a few months ago, and the terror of
ten-line-long function sigs with assertions attached to the various
parameters. But it's largely a false debate, I would argue: if you
want all possible implementations of a given function/method to share
the same precise parameter assertions, they _should_ be specified in
one place, not in twenty. (subs are objects, have inheritance, etc...
more on this later). But TMTOWTDI, if that's not your style.
Anyway, I can definitely see merit in allowing those particular
constructs for the sake of significantly smarter sigs. I can see
_practical_ uses for C<::=>, C<//=>, and <||=> -- enough so that they
probably should be differentiated, and that I would even propose the
C<=> spelling, in sigs, be dropped as ambiguous/meaningless.
?
MikeL
Jonathan Scott Duff
> But it is certainly possible to extend the initialization capabilities
> to be more robust:
>
> sub foo($x = 'blah') {...} # wrong: use one of the below
> sub foo($x ::= 'blah') {...} # same as C<$x is default('blah')>
> sub foo($x //= 'blah') {...} # sets $x whenever $x is undefined
> sub foo($x ||= 'blah') {...} # sets $x whenever $x is false
While this looks pretty in email, it makes me wonder what the ::
operator does outside of regular expressions and how that operator
interacts with ??::
And don't forget these other argument initializations:
sub foo($x &&= 'blah') {...} # sets $x whenever $x is true
sub foo($x += 1) {...} # add 1 to whatever $x given
sub foo($x -= 1) {...} # subtract 1 to whatever $x given
sub foo($x *= 2) {...} # multiply by 2 whatever $x given
sub foo($x /= 2) {...} # divide by 2 whatever $x given
sub foo($x ~= "foo") {...} # Append "foo" to whatever $x given
Depending on how you're bent, the default() property starts to look
pretty good at this point. :-) (with the others relegated to be the
body of the sub)
Paul
> sub foo($x ~= "foo") {...} # Append "foo" to whatever $x given
Oops. :)
That should be
> sub foo($x .= "foo") {...} # Append "foo" to whatever $x given
> sub foo($x ~= "foo") {...} # smart-test $x against "foo"
I assume the second would provide a boolean response.
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Michael Lazzaro
On Tuesday, March 25, 2003, at 11:08 AM, Jonathan Scott Duff wrote:
> On Tue, Mar 25, 2003 at 10:42:39AM -0800, Michael Lazzaro wrote:
>> But it is certainly possible to extend the initialization capabilities
>> to be more robust:
>>
>> sub foo($x = 'blah') {...} # wrong: use one of the below
>> sub foo($x ::= 'blah') {...} # same as C<$x is default('blah')>
>> sub foo($x //= 'blah') {...} # sets $x whenever $x is undefined
>> sub foo($x ||= 'blah') {...} # sets $x whenever $x is false
>
> While this looks pretty in email, it makes me wonder what the ::
> operator does outside of regular expressions and how that operator
> interacts with ??::
Well, := is the binding operator, and ::= is the "compile-time" binding
operator. For some definition of "compile-time"(?)... I'm not sure
whether it can be reused for this "init-time" purpose or not. So ::=
does what := does, but does it sooner. :-)
It has been proposed on several occasions that
$foo ??= 'baz' :: 'zap';
be equiv to
$foo = ($foo ?? 'baz' :: 'zap');
But I don't think ??= and ::= conflict in any (technical) way.
> And don't forget these other argument initializations:
>
> sub foo($x &&= 'blah') {...} # sets $x whenever $x is true
> sub foo($x += 1) {...} # add 1 to whatever $x given
> sub foo($x -= 1) {...} # subtract 1 to whatever $x given
> sub foo($x *= 2) {...} # multiply by 2 whatever $x given
> sub foo($x /= 2) {...} # divide by 2 whatever $x given
> sub foo($x ~= "foo") {...} # Append "foo" to whatever $x given
True, most of those are not useful. But the ones that potentially are
(::=, //=, ||=), should we support them? It would seem that all three
of those notions are quite often used, even in quickndirty code.
I'm arguing for these three defaulting options in particular, but my
more encompassing argument is the wrapper-like notion that signatures
should be able to specify assertions, invariants, and initializations
that may then be "inherited" by all implementations of that
function/method.
Placing such extensive capabilities in the sig is especially useful if
we can 'typecast' subs, as others have pointed out.
class mysub is sub(...big long signature...) returns int {...}
sub foo is mysub {
# actual implementation goes here
}
sub bar is mysub {
# same signature, different function
}
If ...big long signature... contains initializations and assertions
that are required to be shared by all sub implementations, than it
makes the sig a quite powerful thing. Sure, a complex sig could be
pretty big. But it's one big thing, as opposed to repeating the same
assertions in N implementations.
MikeL
Jonathan Scott Duff
>
> On Tuesday, March 25, 2003, at 11:08 AM, Jonathan Scott Duff wrote:
>
> > On Tue, Mar 25, 2003 at 10:42:39AM -0800, Michael Lazzaro wrote:
> >> But it is certainly possible to extend the initialization capabilities
> >> to be more robust:
> >>
> >> sub foo($x = 'blah') {...} # wrong: use one of the below
> >> sub foo($x ::= 'blah') {...} # same as C<$x is default('blah')>
> >> sub foo($x //= 'blah') {...} # sets $x whenever $x is undefined
> >> sub foo($x ||= 'blah') {...} # sets $x whenever $x is false
> >
> > While this looks pretty in email, it makes me wonder what the ::
> > operator does outside of regular expressions and how that operator
> > interacts with ??::
>
> Well, := is the binding operator, and ::= is the "compile-time" binding
> operator.
Interesting. When juxtaposed against //= and ||= it looks more like
"bind unless already bound" to me.
> I'm arguing for these three defaulting options in particular, but my
> more encompassing argument is the wrapper-like notion that signatures
> should be able to specify assertions, invariants, and initializations
> that may then be "inherited" by all implementations of that
> function/method.
Don't we already have the pre() trait and PRE block for this?
> Placing such extensive capabilities in the sig is especially useful if
> we can 'typecast' subs, as others have pointed out.
>
> class mysub is sub(...big long signature...) returns int {...}
> sub foo is mysub { ... }
> sub bar is mysub { ... }
>
> If ...big long signature... contains initializations and assertions
> that are required to be shared by all sub implementations, than it
> makes the sig a quite powerful thing. Sure, a complex sig could be
> pretty big. But it's one big thing, as opposed to repeating the same
> assertions in N implementations.
From A6:
sub Num foo (int $one, Str *@many) { return +@many[$one] }
is short for saying something like:
sub foo is signature( sig(int $one, Str *@many) )
is returns( sig(Num) )
will do { return +@many[$one] }
So, it seems to me that we might be able to do something like this:
$sig = sig(...big long signature...);
&presub = { ...initializations, etc. ... };
sub foo is signature($sig) is pre(&presub) { ... }
sub bar is signature($sig) is pre(&presub) { ... }
Resisting assignment in signatures (for now),
Damian Conway
initialize-if-non-existent operator.
I mean, it happens in the wrong phase (compile-time, not run-time) and it does
the wrong thing (binding, not assignment).
For example:
sub foo {
state $count ::= 0; # $count bound to constant zero
$count++; # Error, can't modify constant
...
}
Or:
sub bar ($start, ?$end ::= $start+1) {...} # $end bound to 1.
# ($start is undef
# at compile-time)
I think that all we need to do is to mentally distinguish "assignment" from
"initialization":
my $x = 1; # initialization
$x = 1; # assignment
and say that initialization happens only on declarations and only once, at the
very beginning of the lifetime of a variable. Thus:
state $count = 0; # initialization: happens only once
$count = 1; # assignment: happens every time
We then simply define the "=" in:
sub foo ( ?$bar = $baz ) {...}
to be an initialization (since it's on the declaration of the parameter).
If the parameter has already be bound to some other container, then that other
container isn't at the start of its lifetime, so the initialization doesn't
occur. If it hasn't been bound during the call, then it's just starting its
existence and the initialization does occur.
And I don't think that allowing 20 different types of assignment in the
parameter list of a subroutine actually helps at all. Especially since the
vast majority of parameters in Perl 6 will be constant.
Damian
Matthijs Van Duin
> my $x = 1; # initialization
> $x = 1; # assignment
Woo, C++ :-)
Considering 'our' merely declares a lexical alias to a package var, how
do we initialize package vars?
Jonathan Scott Duff
>
> sub foo ( ?$bar = $baz ) {...}
>
> to be an initialization (since it's on the declaration of the
> parameter). If the parameter has already be bound to some other
> container, then that other container isn't at the start of its
> lifetime, so the initialization doesn't occur. If it hasn't been bound
> during the call, then it's just starting its existence and the
> initialization does occur.
>
> And I don't think that allowing 20 different types of assignment in
> the parameter list of a subroutine actually helps at all. Especially
> since the vast majority of parameters in Perl 6 will be constant.
But does allowing even one "type of assignment" help? I'm thinking that
something like
sub foo (?$bar is init($baz)) { ... }
is better than an assignment with slightly different semantics than
usual.
Of course, I also think that instead of "state" we should do something
like this too:
sub CallMe {
my $count is kept is init(1);
print "you've called me $($count++) times\n";
}
Boy am I glad Larry is the language designer. :-)
Jonathan Scott Duff
> On Wed, Mar 26, 2003 at 09:19:42AM +1100, Damian Conway wrote:
> > my $x = 1; # initialization
> > $x = 1; # assignment
>
> Woo, C++ :-)
>
> Considering 'our' merely declares a lexical alias to a package var, how
> do we initialize package vars?
The first time they are assigned to, it's an initialization :-)
Mark Biggar
> I don't see how ::= (compile-time-bind) can be used as the
> initialize-if-non-existent operator.
>
> I mean, it happens in the wrong phase (compile-time, not run-time) and
> it does the wrong thing (binding, not assignment).
The only case I can think of where is might be useful is with a
optional parameter with an "is rw" trait, so you could provide an
default binding. Possible example:
sub myprint(+$file is IO:File is rw ::= IO:STDOUT, *@stuff) {...}
open f ">/a/d/v/f/r";
myprint file => f, "Hello World!\n"; # goes to f
myprint "Differnet World!\n"; # goes to IO:STDOUT
although maybe what I really want is := instead.
--
Mark Biggar
ma...@biggar.org
mark.a...@attbi.com
Michael Lazzaro
On Tuesday, March 25, 2003, at 03:35 PM, Mark Biggar wrote:
> sub myprint(+$file is IO:File is rw ::= IO:STDOUT, *@stuff) {...}
>
> open f ">/a/d/v/f/r";
> myprint file => f, "Hello World!\n"; # goes to f
> myprint "Differnet World!\n"; # goes to IO:STDOUT
As a side note... that sig will not do the behavior you've described.
You instead want this:
> sub myprint(*@stuff, +$file is IO:File is rw ::= IO:STDOUT) {...}
The named parameter +$file has to go behind the positional *@stuff in
the signature, but still goes _before_ *@stuff in the actual call.
(Insert image of a five-year-old me jumping up and down on a chair,
pointing my finger, saying "see! see! I told you people would do that!")
MikeL
Damian Conway
> sub myprint(+$file is IO:File is rw ::= IO:STDOUT, *@stuff) {...}
Should be:
sub myprint(*@stuff, +$file is IO:File is rw ::= $*OUT) {...}
> although maybe what I really want is := instead.
I suspect so. The binding of a parameter is most definitely run-time, so :=
seems to make better sense.
One *might* argue that ::= means that $file was *pre*-bound to $*OUT, and the
binding is overridden whenever it is actually passed by name, but that then
prevents run-time computation of bound defaults. Unless you allow := as well.
However I still think we're probably multiplying entities unnecessarily.
Damian
Michael Lazzaro
On Tuesday, March 25, 2003, at 02:19 PM, Damian Conway wrote:
> And I don't think that allowing 20 different types of assignment in
> the parameter list of a subroutine actually helps at all. Especially
> since the vast majority of parameters in Perl 6 will be constant.
Twenty types of _initialization_. :-D
Seriously, tho, I'm not sure I understand the constantness part.
sub foo($x = 1) {...} # A6 syntax
I read the above as saying $x is indeed constant, but if it's not
explicitly placed by the caller, we're going to pretend the caller
passed us a 1. Likewise, I read
sub foo($x //= 1) {...}
as saying the value stored in $x is a constant, but if the caller
passed an undefined value (or didn't pass anything at all), we're going
to instead pretend they passed us a (still-constant) 1. I'm not sure
why that violates any rules.(?)
As a marginal bonus, perhaps an assertion-style
sub foo($x //= 1) {...}
optimizes to be faster, runtime, than
sub foo($x) { $x //= 1; ... }
when passing a constant in $x, e.g C<foo(5)> or C<foo('BLAH')>, since
it can optimize out the assertion at compile-time?
MikeL
Damian Conway
> Seriously, tho, I'm not sure I understand the constantness part.
>
> sub foo($x = 1) {...} # A6 syntax
sub foo(?$x = 1) {...}
> I read the above as saying $x is indeed constant, but if it's not
> explicitly placed by the caller, we're going to pretend the caller
> passed us a 1.
No. I read that as: $x is a constant variable. If the caller passes an
argument (by position or name) then that argument is bound to $x. If they
don't pass a suitable argument, then $x is *not* bound, but simply initialized
to 1.
> Likewise, I read
>
> sub foo($x //= 1) {...}
>
> as saying the value stored in $x is a constant, but if the caller passed
> an undefined value (or didn't pass anything at all), we're going to
> instead pretend they passed us a (still-constant) 1. I'm not sure why
> that violates any rules.(?)
//= means "assign to lvalue unless lvalue is defined". So I read that as:
$x is a constant variable. Bind the corresponding argument to $x and then
assign 1 to it if its value is undef. But the container bound to $x is bound
as a constant, so it *can't* be assigned to.
I guess we could say that, in a parameter declaration, //= means "Bind the
lvalue (i.e. the parameter). If the bound value is undef, unbind the lvalue,
and then initialize it with the rvalue".
But that's horribly complex.
Damian
Paul
> You instead want this:
> > sub myprint(*@stuff, +$file is IO:File is rw ::= IO:STDOUT) {...}
> The named parameter +$file has to go behind the positional *@stuff in
> the signature, but still goes _before_ *@stuff in the actual call.
*sigh*
I haven't been the sharpest tool in the shed today, and I know that the
usual cases will be simpler, and that I'll get used to it with use
until it makes sense and comes naturally.....
But in the meantime, I kinda hafta agree.
It's burning my brain.
Paul
--- Damian Conway <dam...@conway.org> wrote:
> However I still think we're probably multiplying entities
> unnecessarily.
A beautiful if somewhat understated reference to Occam's Razor.
While the synoptic synthesis of the writing of William of Occam is
often translated into English as "One should not multiply entities
needlessly", it's more colloquially stated as "the simplest answer is
usually best".
So why am I multiplying words? :)
Ok. I agree with Damian (which is usually a safe thing to say anyway,
lol...)
Damian Conway
>> my $x = 1; # initialization
>> $x = 1; # assignment
>
>
> Woo, C++ :-)
Low blow, Matthijs! ;-)
Not *exactly* the same, but the same line of thought, yes.
> Considering 'our' merely declares a lexical alias to a package var, how
> do we initialize package vars?
We don't. We assign to them in a BEGIN block. :-)
Damian
Smylers
> On Wednesday, March 19, 2003, at 08:30 AM, Larry Wall wrote:
>
> > We don't have a word for "START" right now. It's somewhat equivalent
> > to
> >
> > state $foo //= 0
> >
> > unless $foo gets undefined, I suppose.
>
> Assuming we have a static-like scope called C<state>, one can
> definitely see the use of having an assignment variant for "not yet
> initialized" or "doesn't yet exist", the proposed spelling of which was
> C<::=>.
I'm unconvinced by the need for a cryptic way to distinguish undefined
from uninitialized. Damian argued in favour of not being able to store
C<undef> in arrays that have some some other, explicit, default value.
I think his argument was that C<undef> is the value to indicate the lack
of a meaningful value, and that we shouldn't be encouraging people to
overload C<undef> with other meanings by making it easy to distinguish
it from a lack of their being a value.
If that applies there, I think it should apply here too.
Or, at least, if we want to make such a distinction here it should be
because we come up with good examples where the distinction is useful,
doing something that couldn't easily be achieved in some other way --
and that that usefulness is thought to outway the additional complexity
of having another assignment operator in the language and having to
distinguish it when teaching or learning Perl.
Smylers
Michael Lazzaro
>> Likewise, I read
>> sub foo($x //= 1) {...}
>> as saying the value stored in $x is a constant, but if the caller
>> passed an undefined value (or didn't pass anything at all), we're
>> going to instead pretend they passed us a (still-constant) 1. I'm
>> not sure why that violates any rules.(?)
>
> //= means "assign to lvalue unless lvalue is defined". So I read that
> as:
> $x is a constant variable. Bind the corresponding argument to $x and
> then assign 1 to it if its value is undef. But the container bound to
> $x is bound as a constant, so it *can't* be assigned to.
OK, I buy that, I think. But does that mean that fixing edge cases in
your arguments doesn't work at all, i.e. you can't even do this?
sub foo(?$x) {
$x //= 1; # if they passed an undef, init it to 1
...
}
or that you have to say it like this?
sub foo(?$x) {
my $x = $x // 1; # hide $x param using a non-const C<my>?
...
}
MikeL
Damian Conway
> OK, I buy that, I think. But does that mean that fixing edge cases in
> your arguments doesn't work at all, i.e. you can't even do this?
>
> sub foo(?$x) {
> $x //= 1; # if they passed an undef, init it to 1
> ...
> }
That's right. It's an error. You need:
sub foo(?$x is copy) {
$x //= 1; # if they passed an undef, init it to 1
...
}
> or that you have to say it like this?
>
> sub foo(?$x) {
> my $x = $x // 1; # hide $x param using a non-const C<my>?
> ...
> }
That won't work either, since the name of the lexical variable C<$x> is
introduced immediately in Perl 6, so the C<$x> on the lhs is the lexical one
from the rhs, not the parameter.
Damian
Michael Lazzaro
> Michael Lazzaro writes:
>> Larry Wall wrote:
>>> We don't have a word for "START" right now. It's somewhat equivalent
>>> to
>>> state $foo //= 0
>>>
>>> unless $foo gets undefined, I suppose.
>>
>> Assuming we have a static-like scope called C<state>, one can
>> definitely see the use of having an assignment variant for "not yet
>> initialized" or "doesn't yet exist", the proposed spelling of which
>> was
>> C<::=>.
>
> I'm unconvinced by the need for a cryptic way to distinguish undefined
> from uninitialized.
> Or, at least, if we want to make such a distinction here it should be
> because we come up with good examples where the distinction is useful,
> doing something that couldn't easily be achieved in some other way --
> and that that usefulness is thought to outway the additional complexity
> of having another assignment operator in the language and having to
> distinguish it when teaching or learning Perl.
I suppose my own most common example is a hash representing a cache...
it's entirely possible for C<undef> to be calculated and cached, but
that doesn't mean the cache entry is invalid and should be recalculated
every time -- a nonextant key would mean the cache entry is invalid.
{
$cache.{ $key } = $cache.load($key)
if not exists $cache.{ $key };
$cache.{ $key };
}
In my own experiences, code similar to the above is awfully common. An
assign-if-not-present form (at least for hashes, but in a magical fairy
world, for arrays/params/whatever, too) such as:
$cache.{ $key } __= $cache.load($key);
would be a lot cleaner, and maybe a little faster, since it's testing
C<$cache.{ $key }> once instead of -- what, 2.5 or 3 times, I guess,
depending on how you count it?
Your mileage may vary, of course -- I must confess I need the undefined
vs. noexists distinction all the time, but it's quite possible I code
weirdly compared to other people. :-/
MikeL
Arcadi Shehter
>
> 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