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
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;
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 $().
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
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
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
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
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
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
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.
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.
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
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;
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
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
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
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
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
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
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
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:
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
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 )
{
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
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
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
26 matches
Mail list logo
