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 enoug
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 ?
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]>
> a>I think this was already discussed once and then it was proposed to
> a>attach a property to characters of the string
> a>
> a> sub peek_at_sky {
> a>
> a> my Color @numbers
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 hereb
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
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 :
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 an
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")
{
give
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 sa
Matthijs van Duin writes:
>
> >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 s
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
Larry Wall writes:
>
> I think it's also a mistake to give C 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
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 "
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:
>
> 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 cl
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:
> 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 attri
Joe Gottman writes:
>
>Not really. A variable declared with can be accessed from
> anywhere in the program, just by redeclaring it or calling it with the
> "package::" syntax.A variable declared with can be accessed outside
> its scope only if the user returns a reference to it.
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
Damian Conway writes:
>
> Not equivalent at all. C<$foo~>bar> means "append $foo to the argument list
> of subroutine C". C means "make C<$foo> the invocant for method
> ".
>
> 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
Luke Palmer writes:
> I don't think so. Rather, that becomes:
>
> him.hit(I);
>
> And to clarify, you should probably format it like this:
>
> hit him: I;
>
> But computer languages aren't generally used to specify past tense
> anyway
>
why priperties are sort of ... becau
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;
>
Damian Conway writes:
> Famous last words. ;-)
>
>
> > Was it ever decided what C would look like with multiple streams?
>
> for zip(@x, @y, @z) -> $x, $y, $z {...}
>
> and its operator version:
>
> for @x ¦ @y ¦ @z -> $x, $y, $z {...}
>
>
> > Maybe we could just use
Luke Palmer writes:
> > Date: Mon, 9 Dec 2002 06:00:40 +0100
> > From: Stéphane Payrard <[EMAIL PROTECTED]>
>
> > Damian:
> > > so it's easy to build up more complex right-to-left pipelines, like:
> > >
> > > (@foo, @bar) :=
> > > part [/foo/, /bar/],
> > > so
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 ha
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 )
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
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 ali
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
31 matches
Mail list logo
