On Fri, 09 Jun 2017 12:48:55 -0700, c...@cpan.org wrote:
> Example code:
>
> $ cat bug.p6
> for ^7 {
> my $x = 1;
> 1 andthen print "$x "
> andthen $x = 2
> andthen $x = 3
> andthen $x = 4;
> }
>
> Output:
>
> $ perl6 bug.p6
> 1 4 3 3 3 3 3
>
> We apparently create a c
On Fri, 09 Jun 2017 12:48:55 -0700, c...@cpan.org wrote:
> Example code:
>
> $ cat bug.p6
> for ^7 {
> my $x = 1;
> 1 andthen print "$x "
> andthen $x = 2
> andthen $x = 3
> andthen $x = 4;
> }
>
> Output:
>
> $ perl6 bug.p6
> 1 4 3 3 3 3 3
>
> We apparently create a c
# New Ticket Created by cygx
# Please include the string: [perl #131548]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131548 >
Example code:
$ cat bug.p6
for ^7 {
my $x = 1;
1 andthen print "$x "
On Sun, 20 Jul 2014 10:33:13 -0700, coke wrote:
> S02-names-vars/variables-and-packages.t has several TODO'd tests of
> this sort:
>
> {
> nok foo().defined, "get variable not yet declared using a sub (1)";
> is foo(), 1, "get variable not yet declared using a sub (2)";
> is foo(), 2, "get v
On Sun, 20 Jul 2014 10:33:13 -0700, coke wrote:
> S02-names-vars/variables-and-packages.t has several TODO'd tests of
> this sort:
>
> {
> nok foo().defined, "get variable not yet declared using a sub (1)";
> is foo(), 1, "get variable not yet declared using a sub (2)";
> is foo(), 2, "get v
On 09/03/17 20:38, jn...@jnthn.net via RT wrote:
> On Thu, 09 Mar 2017 07:39:39 -0800, elizabeth wrote:
>> But I’ll settle for a warning / exceptione :-)
> I think these options are worth consideration. I can't think of a false
> positive off hand.
class Test { method tester { say "testest" } }
On Thu, 09 Mar 2017 07:39:39 -0800, elizabeth wrote:
> Yes, this is because classes / roles are not proper closures. And
> yes, I’ve been bitten by this as well.
>
It boils down to roles and classes being compile-time constructs, while
closures are decidedly runtime ones. You can force a role to
# New Ticket Created by Sam S.
# Please include the string: [perl #130965]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130965 >
sub a ($a) {
return True but role {
method foo { $a }
}
}
Yes, this is because classes / roles are not proper closures. And yes, I’ve
been bitten by this as well.
To me, making them proper closures, feels like the correct solution to me. But
I’ll settle for a warning / exceptione :-)
> On 9 Mar 2017, at 16:35, Sam S. (via RT) wrote:
>
> # New Tick
On Tue, Aug 23, 2016 at 10:28:26AM -0700, Will Coleda via RT wrote:
> > Where the expectation is that the first call to the foo will return an
> > undefined value; in nom, it returns 0.
>
> This behavior has been in place for years now, since before Christmas.
>
> Tagging [@LARRY] to get a ruling
On Sun Jul 20 10:33:13 2014, coke wrote:
> S02-names-vars/variables-and-packages.t has several TODO'd tests of
> this sort:
>
> {
> nok foo().defined, "get variable not yet declared using a sub (1)";
> is foo(), 1, "get variable not yet declared using a sub (2)";
> is foo(), 2, "get variable
I rewrote the fudged tests with commit
https://github.com/perl6/roast/commit/c48ef39ea4. They pass now.
I'm closing this ticket as 'rejected.
# New Ticket Created by cygx
# Please include the string: [perl #125160]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=125160 >
The effect can be seen in
https://github.com/cygx/p6-debug/blob/f432d76c2eda9ee53eca89f7e566
skids++ added some tests for this ticket to roast:
https://github.com/perl6/roast/commit/b354a9304f
The declarations with native types don't blow up any longer -- e.g.
$ perl6-j -e 'my (int $a); say "alive"'
alive
The type constraints within the signatures don't work, though:
$ perl6-m -e 'my
On 12 Sep 2014, at 00:05, Rob Hoelz (via RT)
wrote:
> # New Ticket Created by Rob Hoelz
> # Please include the string: [perl #122765]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=122765 >
>
>
> If I have the following
# New Ticket Created by Rob Hoelz
# Please include the string: [perl #122765]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=122765 >
If I have the following code in a module:
my $foo;
INIT $foo = 7;
MoarVM and the JVM prop
# New Ticket Created by Will Coleda
# Please include the string: [perl #122346]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=122346 >
S02-names-vars/variables-and-packages.t has several TODO'd tests of this sort:
{
nok fo
coke (>):
> I expected it to mean "the FIRST time a block is executed".
>
> My workaround was to use a lexical to track if it was the first time
> through the loop or not;
> will stick with that.
[Coke]: doesn't START do exactly what you wanted from FIRST?
r: for 1..10 { my $a = 3; START { say
On Sat May 25 22:32:15 2013, pmichaud wrote:
> On Sat May 25 21:13:26 2013, coke wrote:
> > 23:54 < [Coke]> r: for 1..10 { my $a = 3; FIRST { say $a} }
> > 23:54 <+camelia> rakudo 45ae2d: OUTPUT«(Any)»
> >
> > I would expect that to output "3".
> >
>
> Since the FIRST block is invoked before t
On Sat May 25 21:13:26 2013, coke wrote:
> 23:54 < [Coke]> r: for 1..10 { my $a = 3; FIRST { say $a} }
> 23:54 <+camelia> rakudo 45ae2d: OUTPUT«(Any)»
>
> I would expect that to output "3".
>
Since the FIRST block is invoked before the assignment/initialization,
the output of "Any" seems corr
# New Ticket Created by Will Coleda
# Please include the string: [perl #118179]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=118179 >
23:54 < [Coke]> r: for 1..10 { my $a = 3; FIRST { say $a} }
23:54 <+camelia> raku
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #102414]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=102414 >
12:07 < moritz> nom: my int ($x, $y);
12:07 <+p6eval> nom 642e78: OUTPUT«Lexical '
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #102254]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=102254 >
Noticed by que++ on #perl6:
./perl6
> my int $x = 5
Use of uninitialized value i
On Sat Jul 24 02:08:56 2010, pmichaud wrote:
> Reopening ticket, the tests fail again after the latest changes to
> closures and switching the 'for' statement to use '.map'. There are
> other fixes that need to be made to .wrap, so I suspect this is related.
>
> Pm
Here's the current failure:
$
masak (>):
> $ cat /tmp/test
> class M {
> has M @.ms is rw;
> method s($i=0) {
> $i ~ "[{ map { "{$_.s($i + 1)}" }, self.ms }]"
> }
> }
>
> my $m = M.new;
> my $m2 = M.new;
> $m2.ms = M.new;
> $m.ms = M.new, $m2, M.new;
> say $m.s;
>
> $ perl6 /tmp/test
> 0[1[] 2[3[]] 4[]]
>
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #70469]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=70469 >
$ cat /tmp/test
class M {
has M @.ms is rw;
method s($i=0) {
$i ~ "[{ ma
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #66658]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=66658 >
rakudo: my @subs := (&greet,&meet); for @subs -> $sub {my
$name = $sub.name; say "Wrapp
Now fixed in 9e2b9ad:
$ cat 66280
for 1,3 -> $i {
for $i..4 -> $j { say "$j,$i" };
$i.say;
}
$ ./perl6 66280
1,1
2,1
3,1
4,1
1
3,3
4,3
3
$
Test added to range.t. Closing ticket, thanks!
Pm
# New Ticket Created by Chris Fields
# Please include the string: [perl #66280]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=66280 >
This is a nasty one. Using a Range with a lexical in an inner for
block with nested p
On Tue Nov 25 13:56:09 2008, moritz wrote:
> Rakudo r33193:
>
> > my $x = 5; subset MyInt of Int where { $^num % $x == 0}; my MyInt $a
> = 10; say $a;
> Type mismatch in assignment.
>
> If I use a constant instead of the lexical $x, it works just fine.
>
> There's a test for that in t/spec/S12-
# New Ticket Created by "Dave Whipp"
# Please include the string: [perl #61894]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=61894 >
example:
pugs: my $global = 1; class A { method foo { say "foo =
$global" } }; A.foo
pu
27;my $a = method { say self.WHAT }; class A { method x {
> self.$a() } }; A.new.x'
> invoke() not implemented in class 'Undef'
> [...]
>
Actually it's a different problem. Because this works:
my $a = method { say self.WHAT }; class A { method x($m) { self.$m() }
};
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #60826]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60826 >
Rakudo r33193:
> my $x = 5; subset MyInt of Int where { $^num % $x == 0}; my MyInt $a
=
Removed workaround in r33203, thanks!
Pm
# New Ticket Created by chromatic
# Please include the string: [perl #60652]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60652 >
Several tests in t/op/lexicals.t fail when run as PBC (or with parrot -r):
t/op/lexic
2008/9/24 Patrick R. Michaud <[EMAIL PROTECTED]>:
> On Wed, Sep 24, 2008 at 12:09:37PM +0200, François Perrad wrote:
>> Currently, the bigger issue in Lua on Parrot is lexical or upvalue in
>> Lua jargon (the reason for Lua on Parrot is not really Lua).
>> The following Lua code doesn't give the ex
On Wed, Sep 24, 2008 at 11:31 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 24, 2008 at 10:05:25PM +0200, Stéphane Payrard wrote:
>> One of parrot current limitation is that eval is always a closure.
>> When using rakudo interactively, one want to introduce new
>> lexical variable
Tom Christiansen:
> > Don't we have to solve all this to get the Perl 6 debugger
> > working anyway?
>
> Although I'm unsure why that might be, I also recognize the possibility
> that there may well exist hypothetical documents, unread by me, which
> mandate some scenario or behavior wherein the
whether perhaps this *might* not apply to perl6
> and ask that, should this indeed be what's afoot, that I be gently
> enlightened.
As far as I'm aware, there's nothing in the current Perl 6 design
or synopses that indicate that things are substantially different
in this a
prompt mode will need to
>>>> be able to maintain it's own dynamic lexical pad (i.e., a
>>>> DynLexPad) and have some way of extracting any lexical changes
>>>> from whatever code string it evaluates.
>>> I wouldn't call them DynLexPad or l
t; directly and not just their register indices. Doing so would require
> that the :outer sub also do store_lex and find_lex on lexical variables,
> and not just the inner ones. (That could be a drawback or a feature,
> depending on your point of view.)
Given the way that code generation
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Tue, 23 Sep 2008 03:45:37 -0500
I've put together a draft with my ideas and design for
(re-)implementing lexicals in Parrot -- now available at
http://www.pmichaud.com/perl6/lexical.txt .
It's a
exical changes from whatever code string
> > > it evaluates.
> >
> > I wouldn't call them DynLexPad or lexicals at all, I would call them
> > just globals. lexvars could shadow them though, but this a user
> > problem then.
>
> This approach might expose so
7;. In
> > particular, the interactive prompt mode will need to be able to
> > maintain it's own dynamic lexical pad (i.e., a DynLexPad) and have
> > some way of extracting any lexical changes from whatever code string
> > it evaluates.
>
> I wouldn't call them
> maintain it's own dynamic lexical pad (i.e., a DynLexPad) and have
> some way of extracting any lexical changes from whatever code string
> it evaluates.
I wouldn't call them DynLexPad or lexicals at all, I would call them
just globals.
lexvars could shadow them though, but t
On Wed, Sep 24, 2008 at 10:05:25PM +0200, Stéphane Payrard wrote:
> One of parrot current limitation is that eval is always a closure.
> When using rakudo interactively, one want to introduce new
> lexical variable that are not lost when accessing them from the
> next prompt.
> Pugs gets that rig
On Tue, Sep 23, 2008 at 03:45:37AM -0500, Patrick R. Michaud wrote:
> I've put together a draft with my ideas and design for
> (re-)implementing lexicals in Parrot -- now available at
> http://www.pmichaud.com/perl6/lexical.txt .
Earlier today chromatic asked about recursion in
One of parrot current limitation is that eval is always a closure.
When using rakudo interactively, one want to introduce new lexical variable that
are not lost when accessing them from the next prompt.
Pugs gets that right.
My take on the subject 8 years ago!
I don't know how that interacts with
On Wed, Sep 24, 2008 at 12:09:37PM +0200, François Perrad wrote:
> Currently, the bigger issue in Lua on Parrot is lexical or upvalue in
> Lua jargon (the reason for Lua on Parrot is not really Lua).
> The following Lua code doesn't give the expected result (from
> languages/lua/t/closure.t) :
Patrick R. Michaud a écrit :
I've put together a draft with my ideas and design for
(re-)implementing lexicals in Parrot -- now available at
http://www.pmichaud.com/perl6/lexical.txt .
It's a first draft and might be a bit confusing in places,
but overall I think it's a far clea
I've put together a draft with my ideas and design for
(re-)implementing lexicals in Parrot -- now available at
http://www.pmichaud.com/perl6/lexical.txt .
It's a first draft and might be a bit confusing in places,
but overall I think it's a far cleaner design than the
current imp
On Sun, Mar 09, 2008 at 04:17:51PM -0400, Bob Rogers wrote:
> From: Klaas-Jan Stol (via RT) <[EMAIL PROTECTED]>
> : when running a language in interactive mode, and you declare a local
> : variable, then this local variable cannot be accessed afterwards.
>
> That's it exactly. A general solutio
On Tue, Apr 1, 2008 at 2:37 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 01, 2008 at 01:23:38PM +0200, Klaas-Jan Stol wrote:
> > in the exception handler, a new Undef is created in $P0. When leaving
> > this line, this code won't work. When commenting out this line, it
> > wil
On Tue, Apr 01, 2008 at 01:23:38PM +0200, Klaas-Jan Stol wrote:
> in the exception handler, a new Undef is created in $P0. When leaving
> this line, this code won't work. When commenting out this line, it
> will print "hi", as expected.
> I don't get that, because, 3 lines later, a new object is st
I'm a bit confused on how lexicals are supposed to work. Below is a
simple example, which looks more or less on code generated by PCT for
a try/catch statement.
in the exception handler, a new Undef is created in $P0. When leaving
this line, this code won't work. When commenting out thi
From: Klaas-Jan Stol (via RT) <[EMAIL PROTECTED]>
Date: Sun, 09 Mar 2008 09:43:02 -0700
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #51560]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Displ
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #51560]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51560 >
hi,
when running a language in interactive mode, and you declare a local
variable, th
Yep, this is the issue that I wrote about a couple of days ago. If
you take a look at the code though, there is a point where the block
for bar is being made into a closure. Take a look at sub _block14:
.sub "_block14" :outer("_block12")
get_global $P20, "_block15"
newclosure $P20, $P2
On Wed, Feb 06, 2008 at 03:33:14PM +0100, Klaas-Jan Stol wrote:
> function foo()
>
> local a = 2
>
> function bar()
> print(a)
> end
> end
>
> foo()
> bar()
>
> What happens here is, a function foo is defined, in which a local var. "a"
> is initialized to the value "2". Ano
Hi,
I have trouble understanding how lexicals work in the code that is generated
by PCT.
Consider the following Lua snippet:
function foo()
local a = 2
function bar()
print(a)
end
end
foo()
bar()
What happens here is, a function foo is defined, in which a local var. &q
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #49182]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=49182 >
I'm converting a parrot-porters post into RT tickets so
that progress can be track
:outer("foo") now basically works, there is also a new Sub method
C.
There is one limitation though: the subroutine referenced by :outer must
be already compiled, that is: it must be in the same sourcefile [1] and
it's source code has to appear before the sub referencing it [2].
[1] can for
Klaas-Jan Stol wrote:
maybe I misunderstand, but does the above mean that lexicals are stored
in registers, instead of storing them in scratchpads? (with lexicals
being local variables in a function, with the addition of being also
accessible from nested functions)
The storage of lexicals
Matt Diephouse (via RT) wrote:
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #36623]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36623 >
There's currently no way to delete a global or a lex
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #36623]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36623 >
There's currently no way to delete a global or a lexical.
mdiep: you should be
are needed for this.
Yes that's what I've already stated above ;)
> It was Larry Wall who suggested the pragma in the long thread,
Yes I've bookmarked it. But a pragma doesn't solve outside effects of
libraries that just capture the continuation under your hood.
And - aga
the time, except for such platform stuff. I test
on two platforms, 3 computers. Tests are currently not passing due to
obvious violations of the recent pdd03 changes.
t/op/gc_13.imc would still fail because of continuation and register
allocation, it's just using lexicals now.
> ... Then it must
Matt Fowles <[EMAIL PROTECTED]> wrote:
> On Wed, 24 Nov 2004 17:25:05 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> a = b + c + foo()
> I am not sure that they are as rare as you think.
Does it matter? They are no lexicals, you can't refetch them. So they
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~
> On Wed, 24 Nov 2004 04:55:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> I've clearly stated that lexicals aka non-volatiles have distinct
>> registers.
> Thus for these large subs, won't this be
On Wed, 24 Nov 2004 04:55:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
> > ... However, if a continuation restores registers to the data they
> > had when the continuation was taken, then all of the registers will
> > contain the things that exactly
On Tue, 23 Nov 2004 23:26:39 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
>
> > Have we seen that this actually destroys us? Meaning, if we add the
> > extra CFG arcs, do we start spilling like mad? If not, this is much
> > ado about nothing.
>
> Please first have a lo
Leo~
On Wed, 24 Nov 2004 04:55:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
>
> > Won't your approach put every one of those things in its own register?
>
> I've clearly stated that lexicals aka non-volati
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Won't your approach put every one of those things in its own register?
I've clearly stated that lexicals aka non-volatiles have distinct
registers.
> ... However, if a continuation restores registers to the data they
> had
we guarantee that return continuations restore all
> > non-volatile registers. If we extend that guarantee to all
> > continuations, everything would just work with the caveat that changes
> > to value registers (as opposed to reference registers) are lost. This
> > is n
opposed to reference registers) are lost. This
is not a real loss though because refetch all lexicals already
requires backing store for I and N registers.
You are missing the point. It's not a question of preserving, it's
register re-using. And forcing all I and N registers into lexical PMCs
On Mon, 2004-05-17 at 19:40, TOGoS wrote:
> This patch adds an extensive answer to "what's with
> lexical pads?", and simple answers to "how do i call a
> function?". It also adds several questions regarding
> object methods and attributes, and manages to answer
> one of them.
Thanks, I'll apply
# New Ticket Created by TOGoS
# Please include the string: [perl #29674]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29674 >
This patch adds an extensive answer to "what's with
lexical pads?", and simple answers to "h
On Mon, 16 Dec 2002, Leopold Toetsch wrote:
> Simon Glover wrote:
>
> > I've been looking into the cause of these failures, and it seems to be
> > yet another GC bug (or more likely another symptom of the same
> > underlying bug).
> >
> > The problem in this case is in scratchpad_new (in sub.
Simon Glover wrote:
I've been looking into the cause of these failures, and it seems to be
yet another GC bug (or more likely another symptom of the same
underlying bug).
The problem in this case is in scratchpad_new (in sub.c). This creates a
new Scratchpad PMC, and subsequently also creat
Simon Glover wrote:
I've been looking into the cause of these failures, and it seems to be
yet another GC bug (or more likely another symptom of the same
underlying bug).
The problem in this case is in scratchpad_new (in sub.c). This creates a
new Scratchpad PMC, and subsequently also creat
I've been looking into the cause of these failures, and it seems to be
yet another GC bug (or more likely another symptom of the same
underlying bug).
The problem in this case is in scratchpad_new (in sub.c). This creates a
new Scratchpad PMC, and subsequently also creates two new lists (one
[EMAIL PROTECTED] wrote:
... this seemed reasonable, but it
doesn't help:
.sub _foo
.local int x
x = 5
.namespace ANON
.local int x
x = 3
print x
.endnamespace ANON
print x
.end
All untested features are b0rken.
I got namespace now running, above snippet be
Leo --
Here's a Jako snippet:
var int x = 5;
{
var int x = 3;
print x;
}
print x
A naiive translation to imcc might be:
.sub _foo
.local int x
x = 5
.local int x
x = 3
print x
print x
.end
but (of course) that leads to an "x already defined" error.
I was hoping
At 4:36 PM -0500 12/3/02, Dan Sugalski wrote:
At 12:05 PM -0800 12/3/02, Jonathan Sillito wrote:
(Would someone like to put the attached file into examples/assembly and
commit it? Also could someone look at the patch in #18419?)
Attached files are in, and I'll go dig up that patch and apply it.
At 12:05 PM -0800 12/3/02, Jonathan Sillito wrote:
The example file has gotten out of date, thanks for pointing this out. The
attached example file fixes this. Also the lexical ops are documented in
core.ops and in the file docs/core_ops.pod which is generated from the
core.ops file at compile tim
header file?
>
> I take it the design of lexicals is still undecided, as
> examples/assembly/lexicals.pasm coughs up errors - ? For now, to make
> things work I'll probably end up (ab)using a hash as a symbol table.
>
> Also the ChangeLog hasn't been updated since 2002
The hash_destroy function is in include/parrot/hash.h but not defined (or
invoked) anywhere. I presume this is because hashes are GC'd, so
hash_destroy can now be removed from the header file?
I take it the design of lexicals is still undecided, as
examples/assembly/lexicals.pasm coug
At 11:50 AM -0700 9/23/02, Jonathan Sillito wrote:
> > -Original Message-
>> From: Piers Cawley [mailto:[EMAIL PROTECTED]]
>> "Jonathan Sillito" <[EMAIL PROTECTED]> writes:
>> > get_counter:
>> > new_pad 1
>>
>> Doesn't this violate the 'caller saves' principle, making it hard to
> -Original Message-
> From: Piers Cawley [mailto:[EMAIL PROTECTED]]
> "Jonathan Sillito" <[EMAIL PROTECTED]> writes:
> > get_counter:
> > new_pad 1
>
> Doesn't this violate the 'caller saves' principle, making it hard to
> do tail call optimization? Would it make sense to move the cre
"Jonathan Sillito" <[EMAIL PROTECTED]> writes:
>> -Original Message-
>> From: Sean O'Rourke [mailto:[EMAIL PROTECTED]]
>>
>> I think I didn't look through the patch queue carefully enough ;). I
>> gather that it's accepted practice (or something like that) to use an
>> array of pointers i
On 17 Sep 2002, Juergen Boemmels wrote:
> You do something like push_pad implicitly in the Sub class, but
> without a corresponding op in core.ops, when you invoke the Sub.
> You also get the current lexical scope implicitly at Sub creation
> time. This may be intentional so that the bytecode cant
"Sean O'Rourke" <[EMAIL PROTECTED]> writes:
> > At the moment I try to use this to get functions working in Scheme. I
> > have something, that is somewhat working in gdb, but not ready yet.
>
> Maybe we need a "pad pumpkin" to avoid these kinds of race conditions.
My actual implementation is a
, Juergen Boemmels wrote:
> I have several questions regarding lexicals.
>
> There is a discrepancy between parrot_assembly.pod and core.ops
> parrot_assembly.pod says that find_lex will return a pointer, where as
> core.ops uses find_lex to retrive a value and store_lex to set this
&g
Luke Palmer fretted:
> This is terrible. Calling foo which calls bar mysteriously overwrites
> $date? "Why is $date changing?" the programmer asks. He does an
> exhaustive search through his code and finally says "ohh," and has to
> change all references to the inner $date to something
> I'm talking about just in the same namespace, how
> do we keep rules from messing with file-scoped
> (or any-scoped, for that matter) lexicals or globals.
> How do we get rule- or closure-scoped lexicals
> that are put into $0?
How about something like the following r
ore we consider your concern (which I will address below), why is
this "not really necessary"? As I see it, here are the needs addressed:
1. Creating lexically scoped variables in caller's namespace
2. Protecting existing lexicals from unexpected side-effects.
One of those is
On Mon, Sep 09, 2002 at 02:13:55PM -0600, Luke Palmer wrote:
> Err.. I don't think so.
>
> # Date.pm
> grammar Date;
> my $date;
> rule date_rule { $date := }
>
> # uses_date.p6 (hmm.. I wonder what a nice extension would be...)
> use Date;
> my $date
return value of in $0{date}.
I'm talking about just in the same namespace, how do we keep rules from
messing with file-scoped (or any-scoped, for that matter) lexicals or
globals. How do we get rule- or closure-scoped lexicals that are put into
$0?
Which of these are legal
Hi,
I have several questions regarding lexicals.
There is a discrepancy between parrot_assembly.pod and core.ops
parrot_assembly.pod says that find_lex will return a pointer, where as
core.ops uses find_lex to retrive a value and store_lex to set this
value. Which of this is correct
On Mon, Sep 09, 2002 at 02:14:25PM -0500, Me wrote:
> Hence the introduction of let:
>
> m/ { let $date := } /
>
> which makes (a symbol table like entry for) $date available
> somewhere via the match object.
Somewhere? where it appears in in the namespace of the caller.
Apparently there
1 - 100 of 139 matches
Mail list logo
