# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46157]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46157
In src/global.c:internal_ns_keyed() there is the todo item:
/* TODO - stop
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 #45983]
# in the subject line of all future correspondence about this issue.
# URL: 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
Changed [ 'Test::More' ] to [ 'Test'; 'More' ]
Patch rt44663-cage-test-more-namespace-to-keys 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]:
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
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
]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44663
The Test::More namespace uses 'Test::More' instead of [ 'Test'; 'More' ]. I
prefer the latter, now that nested namespaces work. The test modules and all
code which uses them
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 this
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 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 after
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 method is
.
~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 in because it includes an API
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
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/interpreter.c
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
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
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;
= 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 hairier when we start using namespaces in Tcl:
namespace eval test {
set
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 eval
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
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
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
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?
'] # ['pge'; 'Closure']
gives me the class Closure already registered error that
started this thread.
-
(*): AFAICT, it's also not true that classnames and namespaces
are currently totally orthogonal, since the class' methods
have to be placed in a namespace that matches the classname.
So
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
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 that
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's the ['Exp';
', ''
$P0 = newclass 'Object'
$P1 = subclass 'Object', ['Object'; 'Num']
$P2 = subclass ['Object'; 'Num'], ['Object'; 'Num'; 'Int']
Normally I would expect 'Object', 'Int', and 'Num' to have their
own top-level namespaces within the HLL namespace, and not require
classnames to always include
) 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
This code
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 will
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 needs to
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 the past
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 illustration, so if
you compare
', '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 classes:
.HLL 'pge', ''
.sub __onload :load
$P0 = newclass 'Exp'
$P0 = subclass 'Exp
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:
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
['pge'; 'Closure'] like you guessed in your first email. But this
places classes next to their namespaces, which is a good thing. But we
probably do need keyed class
that perl6's 'ResizablePMCArray' class object knows that it's
the Parrot class and not the Perl6 one.
This isn't too much different from using keyed class names like
['pge'; 'Closure'] like you guessed in your first email. But this
places classes next to their namespaces, which is a good thing. But we
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #40312]
# in the subject line of all future correspondence about this issue.
# URL: 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.
# URL: 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
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
Note that all
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 [...]
It is, actually
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 either way
# New Ticket Created by Will Coleda
# Please include the string: [perl #39425]
# in the subject line of all future correspondence about this issue.
# URL: 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
[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
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 initial things that spring to mind.
1) (Can we|Will we be able to) do the whole newclass/addattribute/addmethod
thing at compile time
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 classes
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 Chas a namespace instead of Cisa
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's methods have
to be stored
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 allows
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]. In any case, the current double colons
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
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
TODOs, part 2 (todenda?):
[[ NAMESPACE PMC ]]
* The namespace.name() method is being renamed to get_name() for
consistency, and to allow for the possibility of set_name().
* The return value of namespace.get_name(), the parameter to
compiler.get_namespace(), and the parameter to the
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,
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 contributors here
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 chicken/egg problem
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, and namespaces _are_ separate here. Don't let
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 namespaces.
How
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
cl = newclass 'Foo
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/hasa namespace
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
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 the thing, that holds the top-level
namespace
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 comment it as
WTF
. 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/trunk/src/PIL/Native/Bootstrap/*.pil
... and a package/module is a namespace, it would make some sense
*) 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
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
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'd advocate
having
? 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 at all.
The current implementation disambiguates namespace
, 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
'namespace' symbol name seems not to be necessary, because if it
weren't evident, where a namespace is used, we couldn't deal
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 variable bindings, etc. The add_sub/add_var interface
can be implemented in terms of symbols, though; I'm
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
'namespace' symbol name seems
On Dec 2, 2005, at 19:44, Matt Diephouse wrote:
Leopold Toetsch [EMAIL PROTECTED] wrote:
I'm missing the policy in this proposal, e.g. what is allowed to be a
top-level global, how are HLL namespaces organized. And of course:
where is the Parrot namespace for it's PMCs.
I don't think I
On Dec 2, 2005, at 7:31, Matt Diephouse wrote:
Typed Interface
add_sub($S0, $P0)
add_namespace($S0, $P0)
add_var($S0, $P0)
Which HLLs would use these interfaces? Can you please provide some
examples of HLLs with the usage of these interfaces.
Thanks,
leo
Leopold Toetsch wrote:
add_sub($S0, $P0)
add_namespace($S0, $P0)
add_var($S0, $P0)
Which HLLs would use these interfaces?
Maybe I'm missing the point, but I see these being used in the
implementation of import_into as a way for the source HLL to tell the
target HLL
Roger Browne [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
add_sub($S0, $P0)
add_namespace($S0, $P0)
add_var($S0, $P0)
Which HLLs would use these interfaces?
Maybe I'm missing the point, but I see these being used in the
implementation of import_into as a way
Thanks Matt and Chip. It's going to take a while to digest all that, but
already I have a question:
Synopsis
- Languages should contain their namespaces
Suppose my application is multi-HLL. For example, some parts of it are
written in Python and some in Ruby. Suppose I take one small part
- Languages should contain their namespaces
Suppose my application is multi-HLL. For example, some parts of it are
written in Python and some in Ruby. Suppose I take one small part that
is written in Python and decide to re-implement it in Ruby.
Does this mean that I _must_ change its
the potential to mess about with data - and those tools don't
necessarily have a one-to-one relationship with languages.
Consider, for example, Perl 6.0 and Perl 6.1 - they will almost
certainly use namespaces in a compatible way - but there is no way that
Parrot can enforce that. Should Parrot force them
was expecting Parrot to force code generating tools to specify the
namespace they want to work in.
I'm probably looking at this far too simplistically but I was expecting to
read something like this.
Naming Conventions
For interoperability, languages will use hierarchical namespaces
waiting for. i'm going to
be like everyone else and say this will take some time to digest, but
i have a question now.
Naming Conventions
For interoperability, languages should use hierarchical namespaces.
There's no way to outlaw flat namespaces, of course, and that remains
jerry gay [EMAIL PROTECTED] wrote:
On 12/1/05, Matt Diephouse [EMAIL PROTECTED] wrote:
User Defined Namespaces
All HLLs should prefix any namespaces with the lowercased name of
the HLL (so there's no question of what to capitalize). So Perl 5's
CGI module
On Fri, Dec 02, 2005 at 11:50:15AM -0500, Matt Diephouse wrote:
With that in mind, there are two possible ways to name namespaces and
compilers:
1. Lowercase or uppercase them all. The Pugs code works with little or
no effort.
And always use Unicode Normalised form C?
Nicholas Clark
On Dec 2, 2005, at 7:31, Matt Diephouse wrote:
[ Just a few notes, more to come. I've to read it some more times. ]
Naming Conventions
HLL Private Namespaces
HLLs should use a namespace with an underscore and the
lowercased
name of the HLL to store any private items
Leopold Toetsch [EMAIL PROTECTED] wrote:
On Dec 2, 2005, at 7:31, Matt Diephouse wrote:
[ Just a few notes, more to come. I've to read it some more times. ]
Naming Conventions
HLL Private Namespaces
HLLs should use a namespace with an underscore and the
lowercased
1. LANGUAGES AND NAMESPACES
In my previous messages, I was concerned that languages were being
shoehorned too tightly into their own namespaces.
But after a careful reading about import_into, I am happy that each
language has sufficient ability to insert its symbols into the namespace
of another
Roger Browne [EMAIL PROTECTED] wrote:
1. LANGUAGES AND NAMESPACES
In my previous messages, I was concerned that languages were being
shoehorned too tightly into their own namespaces.
But after a careful reading about import_into, I am happy that each
language has sufficient ability
HLL Private Namespaces
HLLs should use a namespace with an underscore and the lowercased
name of the HLL to store any private items. For instance, Tcl should
use the _tcl namespace to store the subroutines that make up the
compiler.
Is it the intention
On Fri, 2005-12-02 at 01:31 -0500, Matt Diephouse wrote:
import_into($P0, ...)
Import items from the current namespace into the namespace in $P0.
It might be clearer to change the name to export_into, because it is
being called on - and controlled by - the source:
Roger Browne [EMAIL PROTECTED] wrote:
HLL Private Namespaces
HLLs should use a namespace with an underscore and the lowercased
name of the HLL to store any private items. For instance, Tcl should
use the _tcl namespace to store the subroutines that make up
their namespaces
- Namespaces should be hierarchical
- Add a get_namespace opcode (that takes an array or a multidimensional
hash index)
- Namespaces follow the semantics of the HLL in which they're defined
- Imports follow the semantics of the library's language
- Two
Seems like the last major thread on namespace issues, especially
inter-language issues, was around October last year and didn't reach
any firm conclusions.
What's the current status?
Tim.
, and they can emit code to do whatever oddball things they
may need to do, though I'm not sure there's a whole lot more that'd
need to be done for most languages. (Especially since namespaces are
supposed to be lexically and dynamically overridable, as well as
layered, but that's all a separate
At 11:07 AM +0100 3/15/05, Leopold Toetsch wrote:
Leopold Toetsch [EMAIL PROTECTED] wrote:
t/pmc/namespace.t
Please have a look at the supported syntax constructs. Are these
sufficient for HLL writers?
Some more thoughts WRT namespaces.
We can define a namespace, where a function or method
Leopold Toetsch [EMAIL PROTECTED] wrote:
t/pmc/namespace.t
Please have a look at the supported syntax constructs. Are these
sufficient for HLL writers?
Some more thoughts WRT namespaces.
We can define a namespace, where a function or method is stored:
.namespace [Foo]
.sub bar
The archives have tons of articels regarding namespaces, mostly HLL
policies and such, but little about Parrot semantics.
I've started a new test file t/pmc/namespace.t that summarizes some of
the current possibilities of namespace manipulation with Parrot.
Please have a look at the supported
On Sun, 3 Oct 2004, Jeff Clites wrote:
I think that no matter what the approach, there's an unavoidable
mismatch between Perl and Python when it comes to variable naming, it's
going to be a bit awkward to access Perl variables from within Python.
...
1) Treat Perl variables as having the
Dan Sugalski [EMAIL PROTECTED] wrote:
Next I want to add in the op variants:
$Px = find_global [key; key]
$Px = find_global $Px, [key; key]
$Px = find_global $Py, 'name'
I've already proposed some time ago that these variants of namespace
manipulation aren't really necessary. I
is more
flexible and powerful (because any namespace along the way can short
circuit the rest of the lookup), but means that HLL compilers must
emit the first option above (with an iterative approach, where Parrot
controls the algorithm and namespaces have less control, a compiler
would have
1 - 100 of 227 matches
Mail list logo
