[perl #39597] Problems with string constants in method calls
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39597]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39597 >
The following code in lines 108-110 of languages/tcl/src/class/
tclcommand.pir are giving parrot some trouble:
inlined.emit(" if epoch != %0 goto dynamic_%1", epoch, label_num)
inlined .= retval
inlined.emit(" goto end_%0", label_num)
as evidenced here:
mini:~/Projects/parrot/languages/tcl mdiep$ cat test.tcl
puts here
exit
puts nothere
mini:~/Projects/parrot/languages/tcl mdiep$ parrot tcl.pbc test.tcl
src/string.c:712: failed assertion `s->encoding && s->charset && !
PObj_on_free_list_TEST(s)'
Abort trap
mini:~/Projects/parrot/languages/tcl mdiep$
Changing those lines to
$S0 = " if epoch != %0 goto dynamic_%1"
inlined.emit($S0, epoch, label_num)
inlined .= retval
$S0 = " goto end_%0"
inlined.emit($S0, label_num)
makes the code run as expected:
mini:~/Projects/parrot/languages/tcl mdiep$ parrot tcl.pbc test.tcl
here
mini:~/Projects/parrot/languages/tcl mdiep$
Changing just the second .emit line to use an S register:
inlined.emit(" if epoch != %0 goto dynamic_%1", epoch, label_num)
inlined .= retval
$S0 = " goto end_%0"
inlined.emit($S0, label_num)
gives a different error:
mini:~/Projects/parrot/languages/tcl mdiep$ parrot tcl.pbc test.tcl
error:imcc:syntax error, unexpected '\n', expecting '('
in file 'EVAL_2' line 39
mini:~/Projects/parrot/languages/tcl mdiep$
Here, parrot is using the wrong string for the first .emit as shown
in the trace:
20366 set_args PC1567 (4), P1, "__read", P2, S3
PC1567=FixedIntegerArray=PMC(0x2739508) P1=Object(TclCod
eString)=PMC(0x301140c) P2=Integer=PMC(0x301442c: 0) S3="3"
20372 get_results PC1558
20374 callmethodcc P1, "emit" P1=Object(TclCodeString)
=PMC(0x301140c)
Help here would be greatly appreciated.
--
matt diephouse
http://matt.diephouse.com
Re: State of Perl6 Backends
The "main" backend as I see it, in the near future, is definitely the Perl 5 runtime for production use Codegen to that runtime is probably going to be written in Perl 5 in Pugs::Compiler::Perl6 space, although it may also happen at Perl 6 space, Parrot space, or Haskell space. (The author-side tools has higher flexibility; the client-side runtime must only assume pure Perl5 and maybe selected well-known XS modules.) So, as of now, you envision svn:/pugs/misc/pX/Common/Pugs-Compiler-Perl6 to be the "main" engine for Perl 6 ? Will this be written only in pure Perl 5 ? And parts of it will be rewritten in Perl 6, and thereby eventually we'll have a Perl 6 engine itself written in Perl 6 ? If this is the case, is the purpose of the other backend engines simply -Ofun or more than that? :-) Where does Parrot fit in all of this? But in the long run, it'll just be different runtimes for different environment. Python has maybe 10 implementations, half of them quite complete; Scheme has more than 20; it's really good for Perl 6 to be retargettable across different runtimes as well. Makes sense. It's good to have different engines suitable for different purposes ... Thanks for taking the time to reply! Swaroop
Re: Mutil Method Questions
"Chris Yocum" <[EMAIL PROTECTED]> writes:
> Hi All,
> At the risk of sounding a bit thick, I have a couple of questions
> about Perl6's multi keyword and mutilmethod in general. This seems
> like overloaded functions from C++ so why do we need a key word to
> declare them rather than using something like C++'s name mangling? Is
> there something that I am just missing here?
Because of your question I had a look at Synopsis 6
(http://dev.perl.org/perl6/doc/design/syn/S06.html). I should do this
more often. Maybe you should also have a look. It's always refreshing.
At least the many keywords seem to be necessary to map the complexity
of different paradigms possible in Perl6. Multimethods are not just
overloading as in C++. Second, the different keywords declare
different behaviour you can choose. Just read S06, it's explained
quite understandable.
> can we now write generic/overloaded functions in Perl6 without OO or
> have I conflated OO with overloading incorrectly?
However it's currently called, with multimethods you can elegantly
"divide and conquer" your code into different subs instead of ugly
"parameter checking if-cascades".
multi sub talk () { say 'Loose Talk Is Noose Talk.'; }
multi sub talk (String $msg) { say $msg; }
multi sub talk (String $msg, Int $times) { say $msg x $times; }
talk("Hi", 10);
talk("Hello");
talk;
GreetinX
Steffen
--
Steffen Schwigon <[EMAIL PROTECTED]>
Dresden Perl Mongers
Re: Mutil Method Questions
Steffen Schwigon <[EMAIL PROTECTED]> writes:
> multi sub talk () { say 'Loose Talk Is Noose Talk.'; }
> multi sub talk (String $msg) { say $msg; }
> multi sub talk (String $msg, Int $times) { say $msg x $times; }
BTW, because we are just on-topic, can someone explain, when these
types above are used. They seem pretty useless in my example but it
looked that nice. :-)
How do I extend the example to really check the parameter types. Some
kind of "use strict" anywhere?
GreetinX
Steffen
--
Steffen Schwigon <[EMAIL PROTECTED]>
Dresden Perl Mongers
Re: Mutil Method Questions
> Multimethods are not just overloading as in C++.
To expand upon this point a little, you can use multimethods to do
pattern-matching in the style of ML and similar languages. So, to pinch
an example from the pugs tree (examples/functional/fp.p6)
multi sub length () returns Int { 0 }
multi sub length (*$x, [EMAIL PROTECTED]) returns Int { 1 + length(@xs) }
Now you can call length on a list, and the call will be dispatched to
the first multi if the list is empty, the second otherwise. In both
cases you're passing a list. Really, this use is caused by having slurpy
argument lists as much as by the multis. The quicksort example in
examples/algorithms/quicksort.p6 is the clearest and most concise
description of quicksort I have yet seen. (The version I usually use
when teaching ML is not as nice as this one.)
Multis also let you define things that look like methods (in the OO
sense) outside the class. This is useful because you might want to have
common operations on certain objects be as convenient as method calls,
but without needing to give them the privileged access to the object
data that methods and submethods get, and without modifying the class
itself.
--
I went to the CO guess what he told me guess what he told me | apologies
He said boy u better learn to like Win no matter what u do | to Prince
But he's a fool, 'cos nothing compares, nothing compares 2 GNU
^^ http://surreal.istic.org/songs/?file=Nothing%20Compares%202%20GNU.txt
signature.asc
Description: Digital signature
[svn:perl6-synopsis] r9717 - doc/trunk/design/syn
Author: audreyt
Date: Fri Jun 23 07:55:16 2006
New Revision: 9717
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: Correct an extra comma in the comment:
for @foo, sub { ... }
should be written as
for @foo sub { ... }
if the sub is to be taken as the loop body.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podFri Jun 23 07:55:16 2006
@@ -142,7 +142,7 @@
$sq = -> $val { $val**2 }; # Same as: $sq = sub ($val) { $val**2 };
-for @list -> $elem {# Same as: for @list, sub ($elem) {
+for @list -> $elem {# Same as: for @list sub ($elem) {
print "$elem\n";# print "$elem\n";
} # }
Re: Mutil Method Questions
On 6/23/06, Steffen Schwigon <[EMAIL PROTECTED]> wrote:
Steffen Schwigon <[EMAIL PROTECTED]> writes:
> multi sub talk () { say 'Loose Talk Is Noose Talk.'; }
> multi sub talk (String $msg) { say $msg; }
> multi sub talk (String $msg, Int $times) { say $msg x $times; }
BTW, because we are just on-topic, can someone explain, when these
types above are used. They seem pretty useless in my example but it
looked that nice. :-)
IMHO they are already used in that example automatically. You just
don't see it because every multi sub had different amount of
parameters.
This example might make it a bit clearer:
multi sub talk (String $msg1, String $msg2) { say "$msg1 $msg2" }
multi sub talk (String $msg, Int $times) { say $msg x $times; }
multi sub talk (String $msg, Num $times) { say "Please use an integer"; }
multi sub talk (String $msg, Range $r) { say "$_: $msg" for $r }
talk("Hello", "World"); # String and String
talk("Hi", 2); # String and Int
talk("Test", 1.23); # String and Num
talk("Hello", 3..5); # String and Range
talk(123, 3); # Int and Int
I think that would print
Hello World
HiHi
Please use an integer
3: Hello
4: Hello
5: Hello
123123123
In last example, there is no exact match for parameters (Int, Int), so
IMHO perl6 would select the closest match, which in this case is
(String, Int) because Int can be converted to String.
The Range-example is my quess of how Range could be used with "for".
I'm not 100% sure if that syntax is OK.
How do I extend the example to really check the parameter types. Some
kind of "use strict" anywhere?
I think that parameter types are automatically checked.
Also "use strict;" is default in perl6, but that's a bit different thing IMHO.
--
Markus Laire
Re: Mutil Method Questions
On Fri, Jun 23, 2006 at 06:18:51PM +0300, Markus Laire wrote:
> multi sub talk (String $msg1, String $msg2) { say "$msg1 $msg2" }
> multi sub talk (String $msg, Int $times) { say $msg x $times; }
> multi sub talk (String $msg, Num $times) { say "Please use an integer"; }
> multi sub talk (String $msg, Range $r) { say "$_: $msg" for $r }
>
> talk("Hello", "World"); # String and String
> talk("Hi", 2); # String and Int
> talk("Test", 1.23); # String and Num
> talk("Hello", 3..5); # String and Range
> talk(123, 3); # Int and Int
>
> I think that would print
> Hello World
> HiHi
> Please use an integer
> 3: Hello
> 4: Hello
> 5: Hello
> 123123123
>
> In last example, there is no exact match for parameters (Int, Int), so
> IMHO perl6 would select the closest match, which in this case is
> (String, Int) because Int can be converted to String.
An alternate interpretation would be that the last one is actually a compile-
time error because none of the sigs match (Int,Int) and for a call to
work with 2 Int parameters, you'd need to be explicit:
talk(~123,3);
But I'm not sure which way perl6 actually leans.
Though it seems to me that automatic type conversion by the compiler is
a way to get yourself in trouble. Not that perl shouldn't let the
programmer get himself in trouble, but this seems like one of those
things that should require asking to turn on rather than asking to
turn off.
my two cents,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Mutil Method Questions
On 6/23/06, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote: An alternate interpretation would be that the last one is actually a compile- time error because none of the sigs match (Int,Int) and for a call to work with 2 Int parameters, you'd need to be explicit: talk(~123,3); But I'm not sure which way perl6 actually leans. Though it seems to me that automatic type conversion by the compiler is a way to get yourself in trouble. Not that perl shouldn't let the programmer get himself in trouble, but this seems like one of those things that should require asking to turn on rather than asking to turn off. Synopsis 12 at http://dev.perl.org/perl6/doc/design/syn/S12.html says When you call a subroutine with a particular short name, if there are multiple visible long names, they are all considered candidates. They are sorted into an order according to how close the actual types of the arguments match up with the declared types of the parameters of each candidate. The best candidate is called, unless there's a tie, in which case the tied candidates are redispatched using any additional tiebreaker long names (see below). IMHO that seems to mean that in my example the (String, Int) version would be called because it's "the best candidate". And that would also mean that first Int is automatically converted to String. -- Markus Laire
lexical lookup and OUTER::
audreyt++ pointed out on #parrot that there doesn't seem to be a way
to specify where to start finding lexicals, in support of perl's
OUTER::. eg. (from S04):
my $x = $OUTER::x;
or
my $x = OUTER::<$x>;
i propose this should be specified using a three-arg form of find_lex
where the third parameter is an integer specifying
which level in the lexical chain to start the lookup.
i've entered this TODO test in t/op/lexicals.t, in r13008:
pir_output_is(<<'CODE', <<'OUTPUT', 'find_lex: (Perl6 OUTER::)', todo
=> 'not yet implemented');
.sub main :main
.lex '$x', 42
get_outer()
.end
.sub 'get_outer' :outer('main')
.lex '$x', 13
$P0 = find_lex '$x', 1
say $P0
.end
CODE
42
OUTPUT
~jerry
[perl #39615] [TODO] get_outer op not defined in PDDs
# New Ticket Created by jerry gay # Please include the string: [perl #39615] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=39615 > tests exist for the get_outer op in t/op/lexicals.t, but i find no mention of the op in documentation anywhere. i *believe* it belongs in PDD20, with other lexical ops docs. ~jerry
Re: State of Perl 6 Backends
On Friday 23 June 2006 00:04, Swaroop C H wrote: > So, as of now, you envision svn:/pugs/misc/pX/Common/Pugs-Compiler-Perl6 to > be the "main" engine for Perl 6 ? I believe Audrey's point was that it is the most complete implementation right now. > If this is the case, is the purpose of the other backend engines simply > -Ofun or more than that? :-) They're all at various stages of incompleteness. Some people believe that specifying a common minimal subset of Perl 6 (or an intermediate language which can represent Perl 6) will allow nearly simultaneous bootstrapping on multiple backends. > Where does Parrot fit in all of this? I am speaking for myself, not Audrey (or anyone else) here. I believe that it will be the most complete and most performant backend in the near and medium future. > Makes sense. It's good to have different engines suitable for different > purposes ... Yes and no. Having multiple incomplete and incompatible implementations is fairly uninteresting. (Multiple complete and incompatible implementations isn't much better; try writing a complex CL program on one platform and deploying it to another sometime.) -- c
Re: Mutil Method Questions
Hi All, I would like to thank everyone for their illuminating examples and prose. This has cleared up understanding for me. Thanks again, Chris On 6/23/06, Markus Laire <[EMAIL PROTECTED]> wrote: On 6/23/06, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote: > An alternate interpretation would be that the last one is actually a compile- > time error because none of the sigs match (Int,Int) and for a call to > work with 2 Int parameters, you'd need to be explicit: > > talk(~123,3); > > But I'm not sure which way perl6 actually leans. > > Though it seems to me that automatic type conversion by the compiler is > a way to get yourself in trouble. Not that perl shouldn't let the > programmer get himself in trouble, but this seems like one of those > things that should require asking to turn on rather than asking to > turn off. Synopsis 12 at http://dev.perl.org/perl6/doc/design/syn/S12.html says When you call a subroutine with a particular short name, if there are multiple visible long names, they are all considered candidates. They are sorted into an order according to how close the actual types of the arguments match up with the declared types of the parameters of each candidate. The best candidate is called, unless there's a tie, in which case the tied candidates are redispatched using any additional tiebreaker long names (see below). IMHO that seems to mean that in my example the (String, Int) version would be called because it's "the best candidate". And that would also mean that first Int is automatically converted to String. -- Markus Laire
Re: Mutil Method Questions
On Fri, Jun 23, 2006 at 06:55:28PM +0300, Markus Laire wrote:
> On 6/23/06, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> >An alternate interpretation would be that the last one is actually a
> >compile-
> >time error because none of the sigs match (Int,Int) and for a call to
> >work with 2 Int parameters, you'd need to be explicit:
> >
> >talk(~123,3);
> >
> >But I'm not sure which way perl6 actually leans.
> >
> >Though it seems to me that automatic type conversion by the compiler is
> >a way to get yourself in trouble. Not that perl shouldn't let the
> >programmer get himself in trouble, but this seems like one of those
> >things that should require asking to turn on rather than asking to
> >turn off.
>
> Synopsis 12 at
> http://dev.perl.org/perl6/doc/design/syn/S12.html
> says
>
> When you call a subroutine with a particular short name, if there are
> multiple visible long names, they are all considered candidates. They
> are sorted into an order according to how close the actual types of
> the arguments match up with the declared types of the parameters of
> each candidate. The best candidate is called, unless there's a tie, in
> which case the tied candidates are redispatched using any additional
> tiebreaker long names (see below).
>
>
> IMHO that seems to mean that in my example the (String, Int) version
> would be called because it's "the best candidate". And that would also
> mean that first Int is automatically converted to String.
I don't think so. I think the "best candidate" prose is about
choosing from types that have been specified, not autoconverting
between types such that one of them will match the long name. In
other words, when you have
multi sub foo (Num) { ... }
multi sub foo (Int) { ... }
foo(1);
foo("123");
foo("bar");
foo(Int) is the best candidate for the first one because 1 is an Int.
But in the second and third calls, there is no "best candidate"
because strings were passed. Would you expect the third call to
succeed because "bar" can be converted into the number 0?
The programmer put type information in the sig for a reason. I think
that reason is that they wanted to be careful about what was allowed
to be passed to the subroutine. Autoconversion seems to defeat that.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Mutil Method Questions
Steffen Schwigon schrieb:
> At least the many keywords seem to be necessary to map the complexity
> of different paradigms possible in Perl6. Multimethods are not just
> overloading as in C++. Second, the different keywords declare
> different behaviour you can choose. Just read S06, it's explained
> quite understandable.
Hm, but wouldn't whose be equivalent?
sub foo ($bar) {
$bar.say;
}
multi sub foo ($bar) {
$bar.say;
}
Aren't subs a subset of multi subs, meaning that every sub can be
expressed as a multi sub?
Is there anything a sub has in advantage of a multi sub?
So might not just every sub be a multi sub?
If the only difference is, that you _must not_ declare a sub twice with
different argument lists, I think that this one is relatively
unimportant and letting every sub be a multi sub seems to be more
consistent to me in opposite to this arbitrary looking distinction.
Maybe I just phenomenally misunderstood multi subs, but unless I did, I
can't see why we want to have subs when we can have multi subs that can
do the same and even more.
-Thomas
Can foo("123") dispatch to foo(Int) (was: Mutil Method Questions)
I'm sending this also to perl6-language, in case someone there knows
an answer to this.
On 6/23/06, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
I don't think so. I think the "best candidate" prose is about
choosing from types that have been specified, not autoconverting
between types such that one of them will match the long name. In
other words, when you have
multi sub foo (Num) { ... }
multi sub foo (Int) { ... }
foo(1);
foo("123");
foo("bar");
foo(Int) is the best candidate for the first one because 1 is an Int.
But in the second and third calls, there is no "best candidate"
because strings were passed. Would you expect the third call to
succeed because "bar" can be converted into the number 0?
I think you are right, but I don't see that mentioned anywhere in Synopses.
S12 clearly says that for a particular short name ("foo" here) *all*
visible long names ("foo(Num)" and "foo(Int)" here) are candidates and
best candidate *is* called (no matter how bad it is) -- unless there's
a tie.
So that would seem to say that for foo("123") above foo(Int) would be
called because it's the best candidate.
Which one is "better" for foo("bar")? foo(Int) or foo(Num)? Or is that a tie?
And what about other types?
e.g. if String can't ever be "best candidate" for Int, then does that
mean that neither can Int ever be "best candidate" for Num, because
they are different types?
The programmer put type information in the sig for a reason. I think
that reason is that they wanted to be careful about what was allowed
to be passed to the subroutine. Autoconversion seems to defeat that.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
--
Markus Laire
Re: Can foo("123") dispatch to foo(Int) (was: Mutil Method Questions)
On Fri, Jun 23, 2006 at 09:11:44PM +0300, Markus Laire wrote:
> And what about other types?
> e.g. if String can't ever be "best candidate" for Int, then does that
> mean that neither can Int ever be "best candidate" for Num, because
> they are different types?
Well, I think Num and Int *aren't* different types because as far as
duck typing goes, Num does Int. I wouldn't expect that String does
Int though (at least not without some help :).
The way I see it, the types specified in the signature are like
constraints. When you say
sub foo (Num) { ... }
the signature says that "only an item that can perform the Num role may
fit in this slot". When perl tries to match Capture to Signature,
it checks the type of each argument in the Capture against the
"does list" for each parameter in the Signature. If the argument type
appears in the "does list" of the Signature, then it's a match and all
is well. Otherwise it's an error. Since "Num does Int", a call such
as C succeeds.
At least that's my vague interpretation of this aspect of perl6 at
this moment. :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: State of Perl 6 Backends
在 2006/6/23 上午 9:50 時，chromatic 寫到： On Friday 23 June 2006 00:04, Swaroop C H wrote: So, as of now, you envision svn:/pugs/misc/pX/Common/Pugs-Compiler- Perl6 to be the "main" engine for Perl 6 ? I believe Audrey's point was that it is the most complete implementation right now. No, that is not my point at all. It's not even true. :-) The Pugs/ Haskell runtime is currently the most complete, and I wouldn't suggest deploying that in production for most places currently using Perl 5 at this point, because for that a runtime needs to guarantee compatibility with Perl 5 XS modules and interoperability with the Perl 5 calling convention (e.g. what Ponie set out to do), which the Haskell runtime only does partially with significant GC/memory-leak issues. The Perl 5 runtime/emitter of P::C::P is currently at a comparable state as Parrot/Perl6 -- neither of them handle the calling convention, neither runs the toned-down Perl4-level Test.pm, and their object space support is "basically" working at the internals level (ParrotObject and Moose), but still entirely hidden from the userland. Of course, I'd like to get Test.pm working for both, and try to agree on the calling convention and object space semantics, at the Chicago hackathon. Makes sense. It's good to have different engines suitable for different purposes ... Yes and no. Having multiple incomplete and incompatible implementations is fairly uninteresting. (Multiple complete and incompatible implementations isn't much better; try writing a complex CL program on one platform and deploying it to another sometime.) Indeed. So instead of having the implementions define the language, this time around the specs, and tests, and API documentations, need to be adhered closely by implementors, which is why we're all talking together in #perl6 in the past few months or so. :-) Multiple implementations that are compatible to the spec, like the R5RS Scheme, are really a very good thing. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: State of Perl 6 Backends
On Friday 23 June 2006 12:19, Audrey Tang wrote: > Multiple implementations that are compatible to the spec, like the > R5RS Scheme, are really a very good thing. Only insofar as the spec is complete enough that an implementation that adds nothing beyond that is useful and that there exists somewhere a set of core-ish libraries that work on conformant implementations. Scheme's not entirely perfect there. -- c
Docathon (was Re: State of Perl 6 Backends)
> "AT" == Audrey Tang <[EMAIL PROTECTED]> writes: AT> Indeed. So instead of having the implementions define the language, AT> this time around the specs, and tests, and API documentations, need AT> to be adhered closely by implementors, which is why we're all talking AT> together in #perl6 in the past few months or so. :-) that was a good leadin for me to remind anyone at the chicago hackathon that we are going to also do a docathon. i actually printed up (double sided to save trees) the full set of synopses from perl.org. (not the most up to date but good enough). i will be marking it up as i read it. i would like to get some of you to do more proofreading at the docathon and we can integrates our patches, rewrites, questions while a large corps of p6 hackers will be around. take a break from hacking p6 and hack the p6 docs! sign up and post your ideas at: http://yapcchicago.org/wiki/index.cgi?SynopsisEdit (i should have called it DocAthon. maybe i will rename it) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: lexical lookup and OUTER::
On Fri, Jun 23, 2006 at 08:27:04AM -0700, jerry gay wrote: > audreyt++ pointed out on #parrot that there doesn't seem to be a way > to specify where to start finding lexicals, in support of perl's > OUTER::. eg. (from S04): >my $x = $OUTER::x; > or >my $x = OUTER::<$x>; So OUTER:: is a -starting- point of one scope up? I thought it was a specific notation that the $x you want is exactly one scope up, and if you wanted two scopes up, you had to ask for OUTER::OUTER::<$x>. Hm: what -is- the meaning of OUTER::OUTER::<$x> -- search starting two scopes up, going as far as needed? > i propose this should be specified using a three-arg form of find_lex > where the third parameter is an integer specifying > which level in the lexical chain to start the lookup. I'm not fond of numeric scope counts, but they are cheap and solve this specific problem. So, OK, and thanks for driving this with a test. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: lexical lookup and OUTER::
On 6/23/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
On Fri, Jun 23, 2006 at 08:27:04AM -0700, jerry gay wrote:
> audreyt++ pointed out on #parrot that there doesn't seem to be a way
> to specify where to start finding lexicals, in support of perl's
> OUTER::. eg. (from S04):
>my $x = $OUTER::x;
> or
>my $x = OUTER::<$x>;
So OUTER:: is a -starting- point of one scope up? I thought it was a
specific notation that the $x you want is exactly one scope up, and if you
wanted two scopes up, you had to ask for OUTER::OUTER::<$x>.
from #perl6:
13:21| audreyt: ?eval my $x = 3; { { say $OUTER::x } }
13:21| evalbot_10746: OUTPUT[3 ] Bool::True
boy, it's nice to have a reference implementation! yes, OUTER:: starts
the lookup one scope up.
Hm: what -is- the meaning of OUTER::OUTER::<$x> -- search starting two
scopes up, going as far as needed?
indeed.
my $x = 3; { { say $OUTER::x} }# 3
> i propose this should be specified using a three-arg form of find_lex
> where the third parameter is an integer specifying
> which level in the lexical chain to start the lookup.
I'm not fond of numeric scope counts, but they are cheap and solve this
specific problem. So, OK, and thanks for driving this with a test.
--
great, thanks!
~jerry
Re: lexical lookup and OUTER::
On 6/23/06, jerry gay <[EMAIL PROTECTED]> wrote:
indeed.
my $x = 3; { { say $OUTER::x} }# 3
of course that should be
my $x = 3; { { say $OUTER::OUTER::x} }# 3
Re: lexical lookup and OUTER::
On Fri, Jun 23, 2006 at 01:16:22PM -0700, Chip Salzenberg wrote:
> On Fri, Jun 23, 2006 at 08:27:04AM -0700, jerry gay wrote:
> > audreyt++ pointed out on #parrot that there doesn't seem to be a way
> > to specify where to start finding lexicals, in support of perl's
> > OUTER::. eg. (from S04):
> >my $x = $OUTER::x;
> > or
> >my $x = OUTER::<$x>;
>
> So OUTER:: is a -starting- point of one scope up? I thought it was a
> specific notation that the $x you want is exactly one scope up, and if you
> wanted two scopes up, you had to ask for OUTER::OUTER::<$x>.
My understanding is that $OUTER::x means "$x as it appears in the
outer lexical scope". In Perl 6 code, this means:
{
my $x = 4;
{
my $y = 7;
{
my $x = 9;
say $x; # outputs 9
say $OUTER::x; # outputs 4
say $OUTER::OUTER::x;# same thing
}
}
}
S02 says this in a somewhat roundabout way:
The current lexical symbol table is now accessible
through the pseudo-package MY. [...] The OUTER name refers
to the MY symbol table immediately surrounding the current
MY, and OUTER::OUTER is the one surrounding that one.
I interpret the first sentence as meaning that the "MY" pseudo-package
refers to all of the symbols in the current lexical scope, not
just those that have been explicitly declared in the current scope
using "my".
However, if there's confusion on this point then perhaps we should
kick the question to p6l or #perl6 for clarification.
Pm
Re: lexical lookup and OUTER::
jerry gay <[EMAIL PROTECTED]> wrote: audreyt++ pointed out on #parrot that there doesn't seem to be a way to specify where to start finding lexicals, in support of perl's OUTER::. eg. (from S04): my $x = $OUTER::x; or my $x = OUTER::<$x>; i propose this should be specified using a three-arg form of find_lex where the third parameter is an integer specifying which level in the lexical chain to start the lookup. While you can't do this with find_lex currently, you *can* do it. Tcl walks the lexpads to find lexicals. (See languages/tcl/runtime/variables.pir): .sub find_lex_pdd20 .param string variable_name .local pmc interp, lexpad, variable .local int depth interp = getinterp depth = 2 # we know it's not us or our direct caller. get_lexpad: # Is there a lexpad at this depth? lexpad = interp["lexpad";depth] unless_null lexpad, got_lexpad # try again inc depth goto get_lexpad got_lexpad: variable = lexpad[variable_name] .return(variable) .end Of course, that doesn't mean that I wouldn't like an opcode to do it for me. :-) -- matt diephouse http://matt.diephouse.com
Re: lexical lookup and OUTER::
在 2006/6/23 下午 1:31 時，Patrick R. Michaud 寫到： I interpret the first sentence as meaning that the "MY" pseudo-package refers to all of the symbols in the current lexical scope, not just those that have been explicitly declared in the current scope using "my". Same interpretation here, as S02 says $MY::foo is just $::foo which is just a lexically-looked up $foo, it follows that MY::.keys will contain all visible lexical symbols, which will be a subset of OUR::.keys, instead of disjoint. Some example code in S02 could help... Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: Perl6 without GHC or Parrot?
在 2006/6/22 下午 12:37 時，Andy Dougherty 寫到： One other oddity: You can't run the test file twice without cleaning up the generated .tc files first. Specifically: $ perl -Ilib 01-sanity/01-tap.t [ works ] $ perl -Ilib 01-sanity/01-tap.t Unmatched right curly bracket at 01-sanity/01-tap.tc line 7, at end of line syntax error at 01-sanity/01-tap.tc line 7, near "}" That has just been fixed in the repo; please install the Module::Compile copy in Pugs's perl5/Module-Compile/ and the problem should go away. I have pinged ingy for a new release. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Re: [perl #39597] Problems with string constants in method calls
via RT Matt Diephouse <[EMAIL PROTECTED]> wrote:
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39597]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39597 >
The following code in lines 108-110 of languages/tcl/src/class/
tclcommand.pir are giving parrot some trouble:
inlined.emit(" if epoch != %0 goto dynamic_%1", epoch, label_num)
inlined .= retval
inlined.emit(" goto end_%0", label_num)
It looks like pbc_merge is the actual source of the trouble here. If I
change languages/tcl/src/tclsh.pir to load the individual bytecode
files instead of the merged file, it works as expected.
--
matt diephouse
http://matt.diephouse.com
