On Wed, 27 Dec 2017 05:17:34 -0800, c...@zoffix.com wrote:
> On Mon, 28 Nov 2016 05:41:48 -0800, c...@zoffix.com wrote:
> > On Mon, 28 Nov 2016 05:38:23 -0800, c...@zoffix.com wrote:
> > > The error is even weirder here:
> > >
> > > m: package IO::Foo { }; use IO::Foo
> > > rakudo-moar 054aca: OUTP
On Wed, 27 Dec 2017 05:17:34 -0800, c...@zoffix.com wrote:
> On Mon, 28 Nov 2016 05:41:48 -0800, c...@zoffix.com wrote:
> > On Mon, 28 Nov 2016 05:38:23 -0800, c...@zoffix.com wrote:
> > > The error is even weirder here:
> > >
> > > m: package IO::Foo { }; use IO::Foo
> > > rakudo-moar 054aca: OUTP
On Mon, 28 Nov 2016 05:41:48 -0800, c...@zoffix.com wrote:
> On Mon, 28 Nov 2016 05:38:23 -0800, c...@zoffix.com wrote:
> > The error is even weirder here:
> >
> > m: package IO::Foo { }; use IO::Foo
> > rakudo-moar 054aca: OUTPUT«===SORRY!===»
>
> Oh, that one was just a glitch in camelia. The e
On Mon, 28 Nov 2016 05:41:48 -0800, c...@zoffix.com wrote:
> On Mon, 28 Nov 2016 05:38:23 -0800, c...@zoffix.com wrote:
> > The error is even weirder here:
> >
> > m: package IO::Foo { }; use IO::Foo
> > rakudo-moar 054aca: OUTPUT«===SORRY!===»
>
> Oh, that one was just a glitch in camelia. The e
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #104760]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=104760 >
11:41 < moritz> nom: class X::Foo { ... }; class X::Foo { }
11:41 <+p6eval> nom 21
On Tue Jul 08 10:35:02 2008, jhorwitz wrote:
> I wanted some feedback on this patch before I apply it. It implements
> "just enough" interpolated namespace support for mod_perl6 to work (see
> S02). In fact, the only supported form is the following subroutine call:
>
>::($ns)::foo()
>
> I
On Tue Jan 13 15:18:05 2009, moritz wrote:
> 00:11 <@moritz_> rakudo: module A { sub b { return 'bar' }}; say A::b()
> 00:11 < p6eval> rakudo 35511: OUTPUT«b»
>
> should return 'bar', of course
>
This and the various other cases in this ticket are resolved in r35763.
Thanks!
Jonathan
# New Ticket Created by Jeff Horwitz
# Please include the string: [perl #62410]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=62410 >
the Foo::bar() format for calling subs no longer works as of r35597. for
me personally
On Nov 5, 2008, at 9:41 PM, Patrick R. Michaud wrote:
On Tue, Nov 04, 2008 at 09:10:02PM -0600, Chris Dolan wrote:
The Perl6 code that triggers that looks like this:
method is_string(Str $src, Str $expected, Str $msg) {
my $method = PDF::Grammar::literal_string;
... just a point of
On Tue, Nov 04, 2008 at 09:10:02PM -0600, Chris Dolan wrote:
> The Perl6 code that triggers that looks like this:
>
>method is_string(Str $src, Str $expected, Str $msg) {
> my $method = PDF::Grammar::literal_string;
... just a point of syntax (which probably doesn't resolve the
issue you
Aha, this was already reported as
[perl #60358] Rakudo doesn't recognize grammars with :: in the name
I added my thoughts to that ticket.
Chris
On Nov 5, 2008, at 12:36 AM, Chris Dolan wrote:
Replying to myself: I think the flaw is in my use of
"PDF::Grammar::literal_string" as a method poin
Replying to myself: I think the flaw is in my use of
"PDF::Grammar::literal_string" as a method pointer. This worked fine
when it was "PDF__Grammar::literal_string", but now the following PIR:
get_hll_global $P108, ["PDF";"Grammar"], "literal_string"
is returning undef. The answer appear
Thanks to Jonathan for working on the :: bug. I'm still having
problems, however. The code below worked before I switched all of my
"__" class separators to "::". I'm not sure how to tell whether it's
failing to find my .pm (I moved the .pm from lib/
PDF__Grammar__Actions.pm to lib/PDF/Gr
On Tue Jul 29 11:27:34 2008, [EMAIL PROTECTED] wrote:
> Hi there, declaring classes in other namespaces except the toplevel
> one results in "emtpy" classes (revision 29850).
>
>
> This code:
>
> class Foo::Bar { method foo {} }
> my $b = Foo::Bar.new;
>
# New Ticket Created by Johan Viklund
# Please include the string: [perl #57388]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57388 >
Hi there, declaring classes in other namespaces except the toplevel
one results
# New Ticket Created by Jeff Horwitz
# Please include the string: [perl #56700]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56700 >
I wanted some feedback on this patch before I apply it. It implements
"just enough" in
be able to use 'get_pmc_keyed' here,
* but we can't because Parrot's default namespaces are not
* fully typed and there's a pseudo-typed interface that
* distinguishes 'get_pmc_keyed' from 'get_pointer_keyed';
* the former is for NS and the latter is for non-NS.
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46157]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46157 >
In src/global.c:internal_ns_keyed() there is the todo item:
/* TODO - stop depending o
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45983]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45983 >
In src/objects.c:parrot_class_register() there is the todo item:
/* XXX try HLL namesp
On Friday 17 August 2007 04:24:10 Badai Aqrandista wrote:
> Changed [ 'Test::More' ] to [ 'Test'; 'More' ]
Thanks, applied as r20648.
By the way, the justification for this is that PDD 15 says (or at least
should) that the proper approach to namespace nesting is to use keys, not
n-delimited st
On Thursday 16 August 2007 15:50:25 Badai Aqrandista via RT wrote:
> Sorry I just read the docs/submissions.pod and realized I shouldn't
> have submit the patch here. I'll resubmit it in proper way to
> parrotbug.
It's fine here; don't worry.
-- c
Hi,
Sorry I just read the docs/submissions.pod and realized I shouldn't
have submit the patch here. I'll resubmit it in proper way to
parrotbug.
--
Thanks,
Badai Aqrandista (cheepy)
Changed [ 'Test::More' ] to [ 'Test'; 'More' ]
Patch level 1
Source: 4c149bba-1ebb-4b29-940e-6c2cefc7587e:/parrot/local:599
Target: d31e2699-5ff4-0310-a27c-f18f2fbe73fe:/trunk:20643
(https://svn.perl.org/parrot/trunk)
Log:
[EMAIL PROTECTED]: cheepy | 2007-07-14 05:14:58 -0400
Cre
Hi chromatic,
Thanks for your prompt reply.
> The main change is to change all instances of [ 'Test::More' ] and the like to
> [ 'Test'; 'More' ].
Can you point to a document or a thread that explains about why this
change needs to happen?
I'm at work now. I'll work on it tonight.
--
Thanks,
On Wednesday 15 August 2007 13:42:39 Badai Aqrandista wrote:
Hi Badai,
> I'm new to the list. I'm a Perl Programmer doing web development in my
> day job and I'd like to help. I'll try to commit an hour or two per
> day to parrot project.
Welcome!
> Can you let me know what I should do to get t
Please include the string: [perl #44663]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=44663 >
>
>
> The Test::More namespace uses 'Test::More' instead of [ 'Test'; 'More' ].
#x27;More' ]. I
prefer the latter, now that nested namespaces work. The test modules and all
code which uses them needs to change to follow this example.
This should take about 20 minutes for a motivated CAGE cleaner. If no one
gets to it on the bug day, I'll do it.
-- c
On Saturday 17 February 2007 08:42, Allison Randal via RT wrote:
> On Thu Jan 11 09:58:32 2007, [EMAIL PROTECTED] wrote:
> > I've held off on applying it because Allison said we need a
> > deprecation cycle
> > for the name() -> get_name() rename.
> I've made a note in DEPRECATED.pod that the me
On Thu Jan 11 09:58:32 2007, [EMAIL PROTECTED] wrote:
> I've held off on applying it because Allison said we need a
> deprecation cycle
> for the name() -> get_name() rename.
I've made a note in DEPRECATED.pod that the method is being renamed
(r17030). Go ahead and apply this patch immediately aft
On Thursday 11 January 2007 07:37, Jerry Gay wrote:
> i'm sending this to rt so it doesn't get lost. i want it in before
> 0.4.8 next week.
I've held off on applying it because Allison said we need a deprecation cycle
for the name() -> get_name() rename.
-- c
week.
~jerry
-- Forwarded message --
From: chromatic <[EMAIL PROTECTED]>
Date: Dec 25, 2006 1:44 PM
Subject: [PATCH] Add get_name() Method to Namespaces
To: [EMAIL PROTECTED]
Here's a patch to implement get_name(), as specified in PDD 21. I haven't
checked it
Here's a patch to implement get_name(), as specified in PDD 21. I haven't
checked it in because it includes an API change. There was already a name()
method in namespaces; I renamed it per the PDD.
-- c
=== src/int
Matt Diephouse wrote:
One common use of anonymous subs in a dynamic language is
for later exporting them into another package (or multiple different
packages). In that case, you really don't want the sub to retain a link
to its defining namespace, you want it to fully adopt the namespace it's
p
From: Allison Randal <[EMAIL PROTECTED]>
Date: Wed, 22 Nov 2006 20:37:26 -0800
Ben Morrow wrote:
>
> ...but that's just a braino on Matt's part, and his point still stands
> for the code
>
> package Test;
>
> sub apply {
> my $func = shift;
Allison Randal <[EMAIL PROTECTED]> wrote:
Okay, so we're basically solving the same problem as Perl 5's "main"
routine, which it stuffs in an obscure C variable internal to the
interpreter, not accessible from the symbol table. (Talk about
less-than-transparent introspection.)
Huh. I don't know
Matt Diephouse wrote:
Let's try this again, starting from the Tcl side of things. Tcl code
can exist outside of subroutines. This, for example, is a valid Tcl
program:
set number 5
puts $number
[...]
But things get a
little hairier when we start using namespaces in Tcl:
namespace
:main
.local pmc number
number = new .TclInt
number = 5
set_global 'number', number
say number
.end
That doesn't look too bad. This actually works and correctly stores
the "number" variable in the root HLL namespace. But things get a
little hai
Jonathan Worthington wrote:
OK, so I've added a REQUIREMENTS section to the objects PDD now and
filled it out with some (hopefully most) of what Perl 6 and .Net need as
a start.
Thanks Jonathan, it's a great start!
Allison
Allison Randal wrote:
More specifically: If you have any questions related to a PDD in clip,
please add them to a QUESTIONS section at the end of the PDD. For
requirements, use REQUIREMENTS. Neither of these sections will live in
the final version of the PDD, so it's a flag for me to process th
To wrap up (or restart) the thread, here are some thoughts from a
high-level view:
HLL classnames should live in the symbol table (i.e. namespace), not in
Parrot's internal class registry. Yes, this means PIR/POST will need
different syntax for instantiating objects from HLL classes. But the
chromatic wrote:
On Monday 23 October 2006 09:49, Jonathan Worthington wrote:
Would it be a good idea to start collecting requirements together from
different language implementors so that when the time comes to work on
the OO PDD, there is already a good description of what it needs to do?
P
Am Montag, 23. Oktober 2006 15:14 schrieb Patrick R. Michaud:
> > .HLL 'pge', ''
> > ...
> > cl = newclass 'Exp' # ['pge'; 'Exp']
> > ...
> > .namespace ['Exp'] # ['pge'; 'Exp']
> > ...
> > scl = subclass 'Exp', ['Exp'; 'Closure'] # ['pge'; 'Exp'; 'Closure']
> > ...
>
> It
On Mon, Oct 23, 2006 at 05:49:08PM +0100, Jonathan Worthington wrote:
> Allison Randal wrote:
> >>I think the object model needs a thorough going over in general
> >Yup. It's on the list right after I/O, threads, and events.
> >...
> >Ruby is a serious OO language, but it's not finished yet. For t
On Monday 23 October 2006 09:49, Jonathan Worthington wrote:
> Would it be a good idea to start collecting requirements together from
> different language implementors so that when the time comes to work on
> the OO PDD, there is already a good description of what it needs to do?
> If so, I'm happ
Allison Randal wrote:
I think the object model needs a thorough going over in general
Yup. It's on the list right after I/O, threads, and events.
-- for
the reasons above and because it's an unproven system. I'm not
convinced that it will handle all of Perl 6's needs as is. No serious
OO langu
bothers me here -- I don't think
that a subclass should have to include the name of its parent in
the class name. It should be:
scl = subclass 'Exp', 'Closure'# ['pge'; 'Closure']
However, writing either this or
scl = subclass 'Exp'
ge'; 'Exp']
> ...
> scl = subclass 'Exp', ['Exp'; 'Closure'] # ['pge'; 'Exp'; 'Closure']
> ...
I strongly disagree. I don't think that a subclass should have to
be named as a sub-namespace of its pa
space) with all the implications for naming it.
There was some discussion re unifying namespace and class 'namespaces' but it
stalled.
The "class isa NameSpace" thingy is still undecided.
leo
Am Donnerstag, 19. Oktober 2006 23:19 schrieb Patrick R. Michaud:
> So, here's the revised version of the code to create
> the classes:
>
> .HLL 'pge', ''
>
> .sub __onload :load
> $P0 = newclass 'Exp'
[...]
> $P0 = subclass 'Exp', 'Closure'
> # ...
> .end
>
>
Matt Diephouse writes:
Allison Randal <[EMAIL PROTECTED]> wrote:
Matt Diephouse wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
>> On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
>> > This is unspecced. ATM, all classes go into the 'parrot' HLL. This
is
>> > a relic of
Allison Randal <[EMAIL PROTECTED]> wrote:
Matt Diephouse wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
>> On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
>> > This is unspecced. ATM, all classes go into the 'parrot' HLL. This is
>> > a relic of the past and I think it ne
Matt Diephouse wrote:
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
> This is unspecced. ATM, all classes go into the 'parrot' HLL. This is
> a relic of the past and I think it needs to change. I'm pretty sure
> that HLL classes w
he module
directly or have to take extra steps to reach it as a module outside
your current HLL. Or, if we say you can only directly access namespaces
within your current HLL, then it's a question of whether you can access
PGE modules in the 'parrot' HLL (so in the general case you
t if the Perl 6 programmer really wants to be using
the Parrot ResizablePMCArray, it will need to be imported into
the perl6 hll_namespace somehow, or otherwise given enough details
so that perl6's 'ResizablePMCArray' class object knows that it's
the Parrot class and not the Pe
blePMCArray to use internally? Or die because there's already a
ResizablePMCArray class? Remember that no matter how much name
mangling you do in this case, there's probably a language that doesn't
want to do any.
This isn't too much different from using keyed class names like
On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > According to pdd21, each HLL gets its own hll_namespace.
> >PGE is really a form of HLL compiler, so it should have
> >its own hll_namespace, instead of using parrot's hll namespace:
really
ought to be referring to its classes as 'Match',
'Exp', 'Literal', etc. So, if we're in the PGE HLL,
we ought to be able to drop the 'PGE::' prefix from
our classnames and namespaces.
So, here's the revised version of the code to create
the
.
After the changes introduced by pdd21, I'm lost as to how
to deal with classname conflicts when multiple HLL namespaces
are involved. I have a very real example from PGE, but bear
with me as I present some background. Also, note that I've
simplified a few details here for illustrat
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #40312]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40312 >
[info commands] needs to support namespaces.
--
Matt Diephouse
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39833]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39833 >
Namespace support has been added to Tcl, but [rename] doesn't have it
yet. See [proc
re the predeclaration of the language higher
> in the lexical scope.
Namespaces aren't your only concern here. You also care about all of the
semantics of module loading and the integration of the target language's
module loading semantics with Perl 6's. For example, there'
On Thu, Jul 06, 2006 at 09:09:08AM -0700, Larry Wall wrote:
: use **perl5::DBI;
which, if you don't like the two-character form, you can spell:
⁑perl5::DBI
:-)
Hmm, hmm, speaking of sanity, how 'bout user-defined sigils and twigils:
sigil ¢ = Capture;
twigil ¬ = "NOTREALLY::";
nical
list, and then suppose someone adds a language 'q', for instance?
But after a "use q:mumble" we can certainly recognize "q:", presumably
forcing people to write "q :mumble" for the rest of the lexical scope
if they want a mumbled quote. Alternately w
在 2006/7/6 上午 3:30 時，Allison Randal 寫到：
Quick question, is there a syntax specified in Perl 6 for referring
to namespaces from other languages?
I'm reviewing the namespaces PDD and want to update this snippet:
--
IMPLEMENTATION EXAMPLES: Suppose a Perl program were to import some
Quick question, is there a syntax specified in Perl 6 for referring to
namespaces from other languages?
I'm reviewing the namespaces PDD and want to update this snippet:
--
IMPLEMENTATION EXAMPLES: Suppose a Perl program were to import some Tcl
module with an import pattern o
be the
root, or that some pseudo-HLL, perhaps the default "parrot" one, should have
the root namespace as its HLL namespace.
> >> Also, is there any reason we can't/shouldn't add find_global variants
> >> that lookup globals in HLL's? Right now we ha
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
On Wed, Jun 28, 2006 at 11:40:28PM -0700, Matt Diephouse wrote:
> The get_namespace opcode gets namespaces from the root namespace.
> Should it get namespaces from the HLL namespace instead? The PDD isn't
> explicit either way [.
On Wed, Jun 28, 2006 at 11:40:28PM -0700, Matt Diephouse wrote:
> The get_namespace opcode gets namespaces from the root namespace.
> Should it get namespaces from the HLL namespace instead? The PDD isn't
> explicit either way [...]
It is, actually:
=head2 Namespace Opcodes
I've started implementing namespace support in Tcl this week (yay!).
But I've run into a bit of trouble, so I have a couple questions:
The get_namespace opcode gets namespaces from the root namespace.
Should it get namespaces from the HLL namespace instead? The PDD isn't
explicit
> [coke - Mon Jun 12 10:29:50 2006]:
>
> Need a store_global opcode that takes a multi-element NS key.
>
Implemented, plus test case.
Jonathan
# New Ticket Created by Will Coleda
# Please include the string: [perl #39425]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39425 >
Need a store_global opcode that takes a multi-element NS key.
--
Will "Coke" Coleda
[E
On Thu, May 25, 2006 at 01:09:47AM +0100, Jonathan Worthington wrote:
> This looks pretty nice.
Sometimes "dynamic" is remarkably convenient. :-)
> 1) (Can we|Will we be able to) do the whole newclass/addattribute/addmethod
> thing at compile time (in a :immediate), so that you have your classe
27;whatever']
$P0.foo()
.end
.sub whatever_foo :anon :method
print "Foo!\n"
.end
Note that the default implementation of vtable add_method() still depends
on
public namespaces. But we can fix that. }:-)
This looks pretty nice. A couple of init
.sub whatever_foo :anon :method
print "Foo!\n"
.end
Note that the default implementation of vtable add_method() still depends on
public namespaces. But we can fix that. }:-)
--
Chip Salzenberg <[EMAIL PROTECTED]>
On May 16, 2006, at 19:32, Chip Salzenberg wrote:
There's is a problem with the naming of classes and their associated
namespaces
that must be addressed.
The first question is: why is the namespace associated, or - in other
words - why does a class C a namespace instead of C
name
{ copied to P6L for the "use case" question below }
On Wed, May 17, 2006 at 12:18:27PM -0400, Will Coleda wrote:
> My concern is that, in an effort to work around this restriction,
> each language will end up implementing a workaround to hide the
> __parrot* namespaces: the
language will end up implementing a workaround to hide the
__parrot* namespaces: these workarounds will hinder interoperability
unless they are synchronized: if they're synchronized, why not
canonicalize them and put it in the core?
That said, I'm still trying to figure out why a class
There's is a problem with the naming of classes and their associated namespaces
that must be addressed.
Creating Parrot classes currently requires _typed_ namespaces, that is,
namespaces where more than one object can have the same fully-qualified
name. Parrot's default namespace a
On Mon, Apr 17, 2006 at 04:44:10PM +0200, Leopold Toetsch wrote:
> Thinking a bit more about it (and discussing this issue with pmichaud)
> on #parrot - it seems that we really want hierarchical class names too,
> the more that a Perl6 class isa NameSpace too.
>
> That means:
>
> * newclass, su
TODOs, part 2 ("todenda"?):
[[ NAMESPACE PMC ]]
* The .name() method is being renamed to get_name() for
consistency, and to allow for the possibility of set_name().
* The return value of .get_name(), the parameter to
.get_namespace(), and the parameter to the get_namespace opcode
should al
chromatic wrote:
What should the syntax for creating new objects be? That is, if I define an
object with its methods in the namespace [ 'PAST'; 'Node' ], how do I create
a new instance of that class?
.local pmc node
node = new ???
Thinking a bit more about it (and discussin
On Apr 17, 2006, at 8:02, chromatic wrote:
What should the syntax for creating new objects be? That is, if I
define an
object with its methods in the namespace [ 'PAST'; 'Node' ], how do I
create
a new instance of that class?
.local pmc node
node = new ???
.namespace ['PAS
On Sunday 16 April 2006 22:00, Chip Salzenberg wrote:
> * standard Parrot libraries not associated with any HLL should have their
> own namespaces
>
> For example, PGE should live in a ["pge"] namespace, or, conceivably,
> under ["parrot";"PGE&qu
Based on a status report from Leo {thanks!} and my recent revisions to
pdd21, here's a list of things that need to be done to bring parrot fully
into the new world of namespaces. The items are roughly in descending order
of importance. There's room for several contrib
On Mon, Dec 05, 2005 at 04:41:21PM +0100, Leopold Toetsch wrote:
> On Dec 5, 2005, at 5:55, Matt Diephouse wrote:
> >>- perl5: sometimes (via sigil, but $ref_tosub)
> >>- perl6: maybe (sigil is part of the symbol name, but $ref)
> >
> >Functions, variables, a
On Wed, Feb 08, 2006 at 08:49:54PM +0100, Leopold Toetsch wrote:
> I'm still having troubles, when thinking about namespace PMCs and
> implementation thereof. Especially the relationship of class namespaces
> and the store_global opcode.
As well you might. :-, There's a chi
On Feb 12, 2006, at 3:07, Jonathan Worthington wrote:
The usage of the C<.namespace> directive causes the creation of a new
namespace PMC with that name. Additionally the namespace PMC is
registered
as a type. This needs a bit of additional code that prevents
instantiation
of name
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
I'm still having troubles, when thinking about namespace PMCs and
implementation thereof.
Especially the relationship of class namespaces and the store_global
opcode.
We have e.g. this PIR snippets:
.sub main :main
I'm still having troubles, when thinking about namespace PMCs and
implementation thereof.
Especially the relationship of class namespaces and the store_global
opcode.
We have e.g. this PIR snippets:
.sub main :main
cl = newclass 'Foo' # a class isa
On Jan 26, 2006, at 5:35, Chip Salzenberg wrote:
Ah yes, of *course*. PMCs have methods, and the methods need to be
found
somewhere, so the default place to look should be vtable->namespace.
Is there a problem with killing vtable->namespace_name and replacing
its
usages with the existing vt
;class? (It's currently unused)
> >
> >Beats me. Vtables don't have namespaces.
>
> Given that in P6 speak ...
>
> 00:27 < stevan> Class.isa(Package)
> 00:27 < stevan> Class.isa(Module), Module.isa(Package), Package.isa(Object)
>
> See also pugs/
On Jan 25, 2006, at 21:21, Chip Salzenberg wrote:
On Tue, Jan 24, 2006 at 05:43:25PM +0100, Leopold Toetsch wrote:
*) what is vtable->package? A pointer to the namespace PMC of this
class? (It's currently unused)
Beats me. Vtables don't have namespaces. Pleaes just commen
ge,
I gather it's an attempt at layered or translucent namespaces -- where one
namespace underlies another and is only consulted when the top one does not
contain the name being searched for. Interesting, but puzzling. Let it
live. For now.
> *) I presume that the stash_hash is
*) what is Stash.parent_stash? (It's currently unused)
*) I presume that the stash_hash is the thing, that holds the top-level
namespace.
*) what is vtable->package? A pointer to the namespace PMC of this
class? (It's currently unused)
*) what is Parrot_Context.current_package? Shoudn't that bet
On Dec 5, 2005, at 5:55, Matt Diephouse wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Of course, now that I think about it more, it's possible that nothing
else will be adding namespaces for Python.
Or: only python itself can create Python namespaces.
In which case I
On Sun, 2005-12-04 at 12:25 +0100, Leopold Toetsch wrote:
> And it doesn't answer my question at all, sorry. Which HLLs are able to
> divide their symbols into above categories?
Ah, maybe I see what you're getting at.
At compile-time, a HLL knows whether it is compiling a sub or a
variable. But
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> And it doesn't answer my question at all, sorry. Which HLLs are able to
> divide their symbols into above categories? Further: as this proposals
> deals with the managment of namespaces, a special typed interface for a
> '
t; - ???
LISP - yes
Matt
Actually, it's "yes" for Common Lisp, and "no" for Scheme. But there's
a bit more to it than that: Namespaces in Common Lisp map a name
(string) to a symbol, which is the object that holds the name's global
function and/or va
;> implementation of "import_into" as a way for the source HLL to tell
> >> the
> >> target HLL whether to treat each name as a sub, namespace, variable or
> >> method.
> >
> > Yes, that's correct.
>
> And it doesn't answer my question a
r symbols into above categories? Further: as this proposals
deals with the managment of namespaces, a special typed interface for a
'namespace' symbol name seems not to be necessary, because if it
weren't evident, where a namespace is used, we couldn't deal with
namespaces
1 - 100 of 270 matches
Mail list logo
