On Sunday, March 23, 2003, at 07:15 PM, Leopold Toetsch wrote:
Dan Sugalski wrote:
While I'm all for the macros (yeah, I know, debugger stepping issues
and all)
I don't get that. What debugger issues? I changed some vtable calls in
the iterator code and didn't see any differences during debu
Leopold Toetsch wrote:
After the overwhelming amount of f'ups to my proposal:
Still :)
One more comment:
The iterator class is intended to pass almost every method on to the
aggregate, e.g.
+PMC* getprop (STRING* key) {
+return ((PMC *)SELF->data)->vtable->getprop(INTERP,
+
Dan Sugalski wrote:
While I'm all for the macros (yeah, I know, debugger stepping issues and
all) I'd rather this be:
VTABLE_getprop(...
Done.
Attached is the new variant.
leo
--- parrot/lib/Parrot/Vtable.pm Fri Jun 21 21:00:02 2002
+++ parrot-leo/lib/Parrot/Vtable.pm Mon Mar 24 10:40:27
David Storrs <[EMAIL PROTECTED]> writes:
> Greetings all,
>
> Ok, it took me several days to get through A6, and I'm not caught up
> on all the mail yet (though I've tried to skim so I don't repeat
> someone else's question). I'm left with a bunch of questions; can
> anyone answer the following:
On Mon, Mar 24, 2003 at 03:23:21PM +, Piers Cawley wrote:
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
Piers,
Apologies...I actually put them into one mail deliberately, because I
didn't want to burn more mindspace than necessary...people could skim
all my questions at once, answer those they were interested in, and be
done. I didn't think about how this would impact the summaries.
In future, I'll
On Mon, Mar 24, 2003 at 06:29:10AM -0800, Austin Hastings wrote:
:
: --- arcadi shehter <[EMAIL PROTECTED]> wrote:
: > is there any chance for this to work :
: >
: > sub new_counter($start=0) {
: > return sub {
: > prop $cnt = $start; #this is opposite to "state"
: >
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
At 12:05 PM -0600 3/24/03, Jonathan Scott Duff wrote:
On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote:
The purpose of a state variable is to keep state across multiple calls
to the same scope, so I'd say the proper semantics on closures is
to treat the generation of a closure as a new
On Mon, Mar 24, 2003 at 01:37:01PM -0500, Dan Sugalski wrote:
Since I'd as soon not encourage this, how about INSTANTIATE? Nice and
long and therefore discouraging. :)
Nothing a macro can't fix :-D
--
Matthijs van Duin -- May the Forth be with you!
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 genera
At 10:34 AM -0800 3/24/03, Larry Wall wrote:
On Mon, Mar 24, 2003 at 12:05:13PM -0600, Jonathan Scott Duff wrote:
: On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote:
: > The purpose of a state variable is to keep state across multiple calls
: > to the same scope, so I'd say the proper sem
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
--- arcadi shehter <[EMAIL PROTECTED]> wrote:
> Matthijs van Duin writes:
> >
> > A nice example is:
> >
> > sub a {
> > state $x;
> > my $y;
> > my sub b { return $x++ + $y++; }
> > return &b; # is a \ before &b needed?
> > }
> >
> > Every call to sub a will return
Matthijs van Duin <[EMAIL PROTECTED]> writes:
> On Sat, Mar 22, 2003 at 10:24:09PM +0200, arcadi shehter wrote:
>> sub a {
>> state $x;
>> my $y;
>> my sub b { state $z ; return $x++ + $y++ + $z++ ; }
>> return &b; # is a \ before &b needed?
>> }
>>
>>
>>will all &b refer t
David Storrs <[EMAIL PROTECTED]> writes:
> Piers,
>
> Apologies...I actually put them into one mail deliberately, because I
> didn't want to burn more mindspace than necessary...people could skim
> all my questions at once, answer those they were interested in, and be
> done. I didn't think about
# New Ticket Created by "3WMail Guest"
# Please include the string: [perl #21679]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21679 >
This patch implements a bunch of things for languages/perl6/
including:
1.) use Modul
And what happens if a programmer wants to have two different variables,
of two different types, with the same name, such as @data and %data?
Without sigils, it cannot be done.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL P
18 matches
Mail list logo
