Re: Mutating methods
Larry Wall writes: Despite the severe overloading problems, it's really gonna be hard to do much better than $topic ? (.a + .b + .c) my dog $spot ?= .new; @array?.[.min .. .max] And I do think people would rebel at using Latin-1 for that one. I get enough grief for «...». :-) Larry How about - which is not overloaded by boolean connotations and is sort of ? turned by 90 degrees . $topic- (.a + .b + .c) my dog $spot- = .new @array- .[.min .. .max] arcadi
Re: Mutating methods
Date: Fri, 12 Mar 2004 12:01:10 -0800 Larry Wall wrote:
It's really a pity that question mark is already so overloaded with
boolean connotations, because
$dog? .bark
would really be the best postfix operator in ASCII for this.
People would probably end up writing
my Dog $spot ?= .new;
as an idiom. And
@array?[.min .. .max]
would be the way to get a topicalized subscript.
some time in the past there was a talk about ... ?? ... :: ... operator being
a combination of two binary : ?? and :: . But I dont know the ruling.
If one factorize trinary ??:: to two binary operators,
?? could act a postfix topicalazer while :: becomes binary
operator :
$a :: $b evaluates to left or right argument according to true/false property of the
_current topic_
something like infix:::($a,$b){ given CALLER::_ { when .true return $a ; return $b }
but it evaluate $b only
if necessary.
Arcadi
Re: printf-like formatting in interpolated strings
Luke Palmer writes:
As far as the syntax, the () and {} don't make a lot of sense with
regard to the rest of the language. We could either utilize the
string/numeric context distinction that already exists in {} and []
for subscripting, or we could always use () in analog to $().
I'd like to have that dollar in there somewhere, actually.
The value in hex is \Fx$( expression ).
Or something. That is kinda clunky, though. Maybe just a
stringification adverb, albeit verbose (but more versatile):
The value in hex is $( expression where format('x') )
No, I actually think that should be a property. In fact, one that has
been discussed before:
The value in hex is $( expression but formatted('x') )
That's actually my favorite so far.
-Edwin
Luke
maybe the analogy with quotelike expressions in p6 could be usefull
so that $ inside string are (sort of ) quotelike operators.
this is unambiguos if single : cannot be a beginning of variable
name.
value is $:3int( $value ) or $:5.3float( $value )
but maybe cleaner way is to have a predefined function which can be
passed modifyers
value is \F:3int[ $value ] or \F:5.3float[ $value ]
or just
value is \F[as='3int', $value ] or \F[as='5.3float', $value ]
arcadi
Re: Ruminating RFC 93- alphabet-blind pattern matching
Yary Hluchan writes:
a = arcadi shehter [EMAIL PROTECTED]
aI think this was already discussed once and then it was proposed to
aattach a property to characters of the string
a
a sub peek_at_sky {
a
a my Color @numbers = peek_with_some_hardware;
a
a my $say_it = join map { 1 but color($_) } @numbers ;
a return $say_it ;
a }
a
a
a rule color { (.) { let $0 := $1.color } }
a
a $daylight = peek_at_sky =~ /color+/; # is something in sky
That works and isn't too bad, a quick fix with some interesting
possibilities. Should be an example in the documentation. Still,
the RFC that opened this discussion opens a different way-
http://dev.perl.org/rfc/93.html
http://www.perl.com/pub/a/2002/06/04/apo5.html?page=17#rfc%20093:%20regex:%20support%20for%20incremental%20pattern%20matching
Once a user-defined sub can hand characters to rexen- it could hand
anything over (floats, refs, etcetera). It's an opportunity ripe
for exploitation.
sorry , it was proposed to be like that
sub peek_at_sky {
my Color @numbers = peek_with_some_hardware;
my Str@words = map { 1 but color($_) } @numbers
my $say_it is from( @words ) ;
return $say_it ;
}
rule color { (.) { let $0 := $1.color } }
$daylight = peek_at_sky =~ /color+/; # is something in sky
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: Ruminating RFC 93- alphabet-blind pattern matching
Austin Hastings writes:
On the other hand, let's suppose that you've got a vast array of
floating point data:
my float @seti = {...evidence of intelligence, somewhere...};
It's a fair question to ask how to retarget the rexengine to use @seti
as the input stream. (I hereby declare that if anyone ever writes a
grammar to do stock-picking, I thunk it first! :-)
I'm guessing that the right way is to replace the low-level operators,
but what are they?
rule color { (.) ( $1.isa(Colorific) ) }
$daylight = peek_at_sky =~ /color/; # is something in sky
Colorific?
Alternatively, there may be a lower-level stream object that could be
replaced:
grammar Rainbow
{
let Rex::get_one := read_float_from_array;
# ...
}
I think this was already discussed once and then it was proposed to
attach a property to characters of the string
sub peek_at_sky {
my Color @numbers = peek_with_some_hardware;
my $say_it = join map { 1 but color($_) } @numbers ;
return $say_it ;
}
rule color { (.) { let $0 := $1.color } }
$daylight = peek_at_sky =~ /color+/; # is something in sky
arcadi
Re: Conditional Creturns?
Damian Conway writes:
given baz(@args) { return $_ when defined }
given baz(@args) { return $_ when $_ 0 }
# etc.
since we have 2 forms of return -- return and leave , may be we
can make return also to be a topicalizer for the rest of experssion
, and then :
return baz(@args) when $_ $_ 0 ;
return baz(@args) when defined ;
return baz(@args) when true ;
but then inside given we will have to use leave :
given $x {
leave baz(@arg) when 5 # compare with $x
return bar(@arg) when 5 # compare with rezult of bar(@arg)
}
or maybe we have to have anothre name for return which also
topicalize.
arcadi
Re: This week's Perl 6 Summary
Piers Cawley writes:
is static?
Discussion of static/state variables continued. Arcadi Shehter wondered
if it made sense to attach but properties to closures. I confess I
didn't really understand what he was driving at. Austin Hastings and
Actually, I was confused , thinking that state declare trait (is
property ) of the closure , and that could explain examples before
that letter in the thread. But then it became clear that state declare
property ( but property ) of the closure - in the sence that it is born
anew every time closure is created. But then , it is still unclear ,
how one should look at closure - as a variable , as a value , or both.
also , From the post of Larry Wall ,
{...
state $a = INIT/FIRST/ENTER/... { ... } ;
...}
force evaluation of the whole closure at the time prescribed by
INIT/FIRST/ENTER/... .
this is similar to behaviour in perl5:
sub a{ my $x = shift ; my $y ; return sub { INIT{$y=1}; $x+$y } }
print a(1)-(), a(2)-() ; #print 22
so , yes, state creates but property of the closure , but its
initialization controlls when and how many times that closure will be
created.
arcadi
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
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?
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?
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?
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: Why Cmap needs work (was Re: L2R/R2L syntax)
Thomas A. Boyer writes:
Michael Lazzaro wrote:
*Now*, what to do about the fantastic magic that pointy-sub provides?
The _spectacular_ win would be if we could just recognize an optional
parameter list as part of a block.
map @a : ($a,$b) {...} # params + closure = closure with params?
for @a : ($a,$b) {...}
So that anywhere you had a closure, you could put a paramlist in front
of it. Not likely we could get that to work, since best-case scenario
it would probably barf on $a and $b being undefined before it ever got
to the closure. But it might be possible, at the expense of some
parser complexity.
I sertainly can do it like taht :
map @a : {...} is sig($a,$b)
for @a : {...} is sig($a,$b)
or
map @a : sub($a,$b) {...}
for @a : sub($a,$b) {...}
or
@a ~ map sub($a,$b) {...}
It also seems that the difference between map and for may be twisted
as follows : map apply particular closure to several ( possibly one )
array , while for takes particular array ( which may have possibly
passed some pre -zipping/-weaving) and apply pour it to several (
possibly one ) closures.
if we assume that for can accept as its last arguments sequence one or
more closures than with the existing pointy sub meaning of - we can
have
for @a - ( $x ){ ... }
- ( $y ){ ... }
- ( $z ){ ... } ;
and , is unnecessary after the curly for the same reason it is
unnecessary after @a.
since grep/map/and_friends are just subroutines this naturally gives
piping behaviour :
for @a - ( $x ){ ... } #this is map
,grep - ( $y ){ ... } #this is grep
,sort - ( $a,$b ){ ... } ; #this is sort
this is similar to the old then suggestion of Damian Conway
@a then map - ( $x ){ ... } #this is map
then grep - ( $y ){ ... } #this is grep
then sort - ( $a,$b ){ ... } ; #this is sort
arcadi
Re: L2R/R2L syntax
Damian Conway writes:
Not equivalent at all. C$foo~bar means append $foo to the argument list
of subroutine Cbar. Cfoo.bar means make C$foo the invocant for method
bar.
Curiously enough, the confusions I'm hearing over this issue are, to me, the
strongest argument yet for using Andy's | and | symbols instead.
Damian
Proposal :( but may be this is just part of the above mentioned
confusion:)
* we probably should distinguish between
+ pseudo-pipes ( I spell them as : and : )
+ and right- and left- assignment operators ( I
spell them ... = $var and $var = ... ) .
these should be aware of distinction between assignment and
binding -- so probably there have to be 2 forms of each ???
* : and : should be thought of ( and probably actually are ) just
( special ) __commas__ in the following sense :
@a : sort { ... }#== sort { ... } @a:
@a : join ... #== join ... @a:
sort { ... } : @a #== sort { ... } @a:
join ... : @a #== join ... @a:
so it seems that ( already discussed ) redunduncy of : can be solved
by saying that
* : is doing to the _following_ term _the_same_thing_ ( makes it an
adverb ) as what : is doing to the _preceding_ term --- so : is sort
of prefix form special comma : .
that means that : is prefix adverbial comma - and the verb is
to be found _before_ the : comma .
* : is different . it makes the _preceding_ term an adverb --- but
the corresponding verb have to be searched _after_ the : comma .
it seems that all the distinction between methods and subroutines is
now handled if methods and subroutines know how to handle adverbial
arguments. ( but this does not allow to place _usual_ arguments
before the subroutine/method -- so probably there have to be another
comma )
It seams that with this in mind and usual precedence rules we can
make multimethods enjoy the l2r notations.
( $square : init ) :
( $circle : init ) : do_something
do_something : ($square : init)
: ($circle : init)
arcadi
Re: L2R/R2L syntax
Damian Conway writes:
Buddha Buck wrote:
Perl 5 allows you to do:
$object-meth1-meth2-meth3; # Perl5 chained method, L2R
Perl 6 will also allow you to do:
$data ~ sub1 ~ sub2 ~ sub3;# Perl6 chained subs, L2R
Perl 5 allows you to to:
sub3 sub2 sub1 $data; # Perl5 chained subs, R2L
Perl 6 will also allow you to do:
meth3 ~ meth2 ~ meth1 ~ $Xbject # Perl 6 chained methods, R2L
All four syntaxes will be available in Perl 6, modulo the fact that '-'
is now spelled '.'
The additional functionality that when the last sub or method in the ~
and ~ is a variable an assigment is done is a convenience issue.
will something like that work ? and how ~ distinguish between = and
:= ?
@source ~ part [
/foo/,
/bar/,
/zap/ ]
~ (@foo,@bar,@zap)
the issue is : what happens if function returns more than one
variables .
It seems that it is not very bad idea to have some special (lexical )
variable similar to $0 for regexes that is set after
grep/part/sort/or_may_be_something_userdefined have done its work and
then ( here $0 is a placeholder for that variable ) :
@source ~ part [
/foo/ = @foo,
/bar/ = @bar
/zap/ = @zap ] ;
$0{'@foo'} ~ map { ... } ~ @foo;
$0{'@bar'} ~ map { ... } ~ @bar;
$0{'@zap'} ~ map { ... } ~ @zap;
but maybe that may be stilll shortened . the idea ( maybe bad ) is to
have named or numbered (pseudo)pipes similar to having named or
numbered arguments.
@source | part [
/foo/ = foo,
/bar/ = bar
/zap/ = zap ]
|foo map { ... } | @foo,
|bar map { ... } | @bar,
|zap map { ... } | @zap ;
So |foo is undone by perl arranging temporal variable after the
action of part and then feeding this temporal variable to the rest of
pipeline. that also means that |foo remembers the return values
_only_ from the thing on its _closest_ left .
then something like that can be made to work :
@source | grep { ... }
|ok map { ... } | @foo,
|nok map { ... } | @bar ;
I am not sure this is a good solution
but I think that purge and L2R-R2L threads of this maillist have to
be more close somehow.
arcadi
Re: L2R/R2L syntax (was Re: Everything is an object.)
Damian Conway writes:
Unary ~ would (by analogy to unary dot) append the current topic to the
argument list of its operand.
Thus, your examples become simply:
given @list {
~ grep /bad!/ ~ @throw;
~ grep /good/ ~ @keep;
}
And:
given @list {
~ grep length == 1 ~ @onecharthings;
~ grep [0..29] ~ @numberslessthan30;
~ grep /^\w+$/ ~ @words;
~ grep $_%2==0 ~ @evennumbers;
}
Damian
but if I dont want to force @list in scalar context ???
since ~ and friends are _pure_ grammar while given is not ,
probably we can have unary postfix ~ ( or |~ )
{
@list ~ ; # ( or @list |~ ; )
~ grep length == 1 ~ @onecharthings;
~ grep [0..29] ~ @numberslessthan30;
~ grep /^\w+$/ ~ @words;
~ grep $_%2==0 ~ @evennumbers;
}
as a way to multiplex @list
arcadi
Re: Status Summary; next steps [x-bayes][x-adr]
Larry Wall writes: Note that the true property is not the same as the true function. This tells me that properties may need their own namespace distinct from either subs or classes. (We've talked about defining properties as subs or classes, but either way is problematic. If we have a Ctrue class we can't parse a Ctrue unary operator correctly.) Brent Dax summarized sometime ago: ## TERMOPERATORDOUBLE OPERATOR ## ## $ scalar sigil ## @ array sigil ## % hash sigil modulo ##sub sigil junction and** logical and ## = assignment comparison ## \ get reference ## .. method call** method call** range constructor ## ? force to bool* ** trinary operator ## ## , list composer list composer ## ; statement end statement end ## : super-comma package ## separator, ## trinary operator ## how about : as a sigil for properties . my $x is :constant arcadi
Re: Dynamic scoping (take 2)
so these two are equivalent ???
{
my $x is yours ;
my $y is yours ;
my $z is yours ;
1...
sub_a ;
2...
}
sub sub_a ( ; $x is yours, $y is yours ) { ...3... } ;
- same as -
# ( here no special meaning for is yours -- just another property )
{
my $x is yours ;
my $y is yours ;
my $z is yours ;
1...
#alias %MY to topic so that it can be fetched from sub_a by is given
$_ ::= \%MY ;
sub_a ;
2...
}
sub sub_a (;$x is yours,
$y is yours ) is given($CALLER_SYMB)
{
#alias variables from $CALLER_SYMB to the local variables if
#requested
$SUB_SYMB ::= \%MY ;
for $SUB_SYMB.keys {
if $SUB_SYMB{$_}.yours
and $CALLER_SYMB{$_}.yours
{
$SUB_SYMB{$_} ::= $CALLER_SYMB{$_} ;
}
} ;
$CALLER_SYMB = undef ; #but better if this happens at compile time
# -- probably this have to be forced with
#BEGIN
3...
} ;
arcadi
Re: Dynamic scoping (take 2)
If I misunderstood you -- correct me. It seems that all you worry
about is that you want some variable be seen in several subroutines
.. you propose a mechanism of passing them between desired subroutins
by default through all the dynamical chain of sub calls connecting
them. It seems , on the other hand , that there is already existing
and ( to my taste ) simpler mechanism of making several subroutines (
and in general -- any lexical scopes ) share *the same* variable --
package ... ;
sub a { our $x is private ; ... } ; #...but see below ...
sub b { our $x is private ; ... } ;
so $x is *package* variable that can be seen *only* from a and b.
it plays the role of mailbox : a can put there whatever it want to
pass to b . b should know about it ( and it knows because it
declares $x inside its body ) and should fetch whatever it wants.
it seems that this mechanism is cleaner and clearer and .. more
intuitive.
although...
on the second thought I have a feeling that I am pulling is private
property too much -- this way of using it was not discussed in Exe3.
so probably we should invent the property that does exactly that :
this variable is package *but* it is seen only from *several* lexical
scopes , something like this :
package ... ;
sub a { our $x is shared ; ... } ;
sub b { our $x is shared ; ... } ;
we can even prescribe which lexical scope is allowed to change it :
package ... ;
sub a { our $x is shared is rw; ... } ;
sub b { our $x is shared is ro; ... } ;
but maybe this is abuse for rw and ro here -- so this should be
package ... ;
sub a { our $x is shared(rw) ; ... } ;
sub b { our $x is shared(ro) ; ... } ;
also there is one thing that bothers me about even the original is
private property : what if my package is *really big* and I have in
two distant places two function that each want its own static
variable that they declare as Exe3 prescribe as
our $var is private;
but since I dont remember about having two such subs I can happen to
give them the same name - so that naively they will be aliased to the
same package variable . Now, with is private that is , probably not
a problem , because compiler can notice this and complain about it .
but If I want to pull similar mechanism for *sharing* variables --
this becomes a problem -- compiler cannot know that I wanted to share
one variable $x between aub A and sub B and *another* variable (
which I mistakenly called $x too ) between sub C and sub D . In this
case it will share $x between *all four* subs. I dont know how to
stop this source of errors . currently . but anyway that is what
bothered me with is private property.
anyway, my feeling is that once it is necessary to pass variable far
enough it is clearer to do it with globals -- which are restricted to
be seen only in the restricted set of lexical scopes.
arcadi .
Me writes:
In summary, I am proposing that one marks
variables that are to be automatically
passed from sub to sub with 'is yours'
where appropriate.
An example of what I'm suggesting follows.
Code with brief comments first then explanation.
{
my $_; # $_ can't be touched
# unless it is passed
# to a sub explicitly.
my $foo;# same for $foo
my $baz is yours; # $baz will automatically
$baz = 10; # be passed to /directly/
# called subs that ask
# explicitly for $baz.
waldo($foo);
}
sub waldo ($b ; $baz is yours)
{ print $baz; emer; }
sub emer (;$baz is yours(no))
{ print $baz; qux; }
sub qux { ... }
Running this prints '1010'. Here's why:
A property exists that can mark any lexical
as yours. When a variable is marked yours
it is automatically passed to any directly
called sub (not nested subs) that mentions
it appropriately.
The automatic $_ (available without
declaring with a 'my') is marked yours
by default.
All other (ie declared) lexicals are, by
default, not yours, hence guaranteed to be
private lexicals unless explicitly passed
to a sub. This is safer than the current
perl 6 design in which use of $CALLER::,
and even builtins and subs that merely
use the topic, might accidentally clobber
one of my lexicals at any time.
Once execution reaches the body of waldo,
there is a new lexical called $baz that is
bound to the lexical with the same name in
the body of the caller.
The Cis yours in waldo's sig has two
effects:
1. It requires that any /caller/ has a
variable of the same name marked as
yours or must pass a variable/value
using the named arg syntax for that
arg name;
2. It propogates the marking of $baz as
a yours marked variable for any sub
called from this, the body of waldo.
Once execution reaches the body of emer,
there is a new
Re: Dynamic scoping (take 2)
I think , ( on the second reading of your post ) , that your proposal of my $x is yours is logically very similar to my proposal of our $x is shared but your proposal is cleaner if I understand it as follows ( although I like more shared instead of yours for that purpose ) : instead of aliasing the lexical variable variable $x to the variable of the same name in the *current package* is yours *create* a new (secret) symbol-table that is remembered by compiler to be associated with variable $x and *aliases* $x to the variable of the same name in that (secret) symbol-table . *Any* other instances of $x is yours *alias* $x to *the same* variable $x in that (same) secret symbol-table. I do understand that strictly speaking you proposal is *very* different -- since you want only those function that will *ever* call each other ( not necessarily directly ) to share ( by default ) some variable -- so you propose dynamic (???) sharing . I propose *static* sharing -- but in practice they are *the same* -- the only difference is that I may happen to make two functions that *never* call each other ( or never happen to be in the same dynamic scope ) to share the same variable . But I am in controll of this ( If I am carefull lI will not do it -- and share variables only between those functions that it makes sence to share between ). my point is that static sharing is simpler to understand ( to me ) and it is a simpler concept -- just some mailbox variable that hangs somewere above the battlefield that only several people can access . dynamic sharing is like a *red* message that have to be passed ( secretly ) every time a soldier have it happens to *meet* another soldier that know that it have to receive *red* message. and I am not talking about implementation . arcadi
Re: Dynamic scoping (take 2)
Me writes:
4. Autoargs are conceptually simpler than
shared variables, for both newbies and
experts. But clearly this is subjective. :
thats exactly the point where I tryed to improve. Think of me as a
newbe ( which I am ) -- If I understand your proposal , I can explain it to
myself through the sort of shared variable :
$x is yours
tells that $x is aliased to variable in some secret scope symbol
table that ( the table ) is shared between caller and callee
also, another way :
$x is yours
is like saying that all functions that will ever call each other (
that is, if in my programm A calls B and B calls C and ... , then I
will croup them in a group that ever call each other ) and
which each have a declaration $x is yours may be thought
of as being in special common *enclosing* lexical scope , at the top
of which there is a declaration
my $x ;
so they all *share* the same variable .
I think the effect here is the same as what you are saying .
but may be I am wrong.
also , there is another question :
{
my $x is yours = 1;
a ;
print $x # print 1 or 5 ?
}
sub a { $x is yours ; $x = 5 ; }
( in my formulation it prints 5 ) .
so the question is : is is yours variable assigned or aliased in the
callee scope ? probably I missed this from your explanations .
probably we should have both , and then is yours mechanism is more
general .
also , anothre question . if is shared isn't thread safe , is static
scoping using
our $x is private ;
thread safe ??
arcadi .
