more pdd21 questions
Leopold Toetsch
1)
Namespace Opcodes
add_namespace $P0, $P1
The opcode signature looks a bit strange to me, especially when compared
to the 'add_namespace' method. Is the namespace name implied? And there
is of course again the question where to add the namespace: relative to
HLL or absolute at namespace root.
The relative to HLL:: or absolute issue applies to 'get_namespace $P1'
too. OTOH the aliasing example explicitely includes 'perl6' as toplevel
namespace component. I'm missing some consistency here. Are only
{find,store}_global relative to 'HLL::'?
2)
Default Namespace
The default namespace PMC will implement Parrot's current behavior.
The current implementation allows a nested namespace and a variable to
have the same name (via the hack of prepending "\0" to namespace names).
Assuming that this hack should go away, I see two ways to continue
implementation:
a) Parrot's default namespace is untyped (raw). This means that a
variable/subroutine can't have the same name as a namespace. This could
break existing code.
b) Otherwise, Parrot's namespace is (half-)typed, at least namespace and
variable/sub are allowed to coexist with the same name. [1]
3) Parrot's internal namespace needs a name ('parrot', 'core' or whatever).
4) Where are all the Parrot libraries living: PGE, Getopt, Data, Digest,
...? Below the 'parrot' namespace? Toplevel? 'Lib'?
5) Has the namespace root a name?
$P0 = ns.'name'()
$S0 = join '::', $P0 # '::parrot::Foo'
or should the toplevel be excluded by 'name'?
Thanks for clarification,
leo
[1] This needs 2 storage slots per hash bucket, at least one more
indirection to access items. A fully typed namespace with 4 slots (raw,
namespace, var, sub) is then not more complicated to implement.
Leopold Toetsch
On Mar 8, 2006, at 14:30, Leopold Toetsch wrote:
> 2)
> Default Namespace
>
> The default namespace PMC will implement Parrot's current
> behavior.
>
> The current implementation allows a nested namespace and a variable to
> have the same name (via the hack of prepending "\0" to namespace
> names). Assuming that this hack should go away, I see two ways to
> continue implementation:
>
> a) Parrot's default namespace is untyped (raw). This means that a
> variable/subroutine can't have the same name as a namespace. This
> could break existing code.
>
> b) Otherwise, Parrot's namespace is (half-)typed, at least namespace
> and variable/sub are allowed to coexist with the same name. [1]
I've implemented now b). The overhead is low (one if statement) and no
additional storage space is used, if either a NameSpace or a var_or_sub
is stored into a name slot.
leo
Chip Salzenberg
> >a) Parrot's default namespace is untyped (raw). This means that a
> >variable/subroutine can't have the same name as a namespace. This
> >could break existing code.
> >
> >b) Otherwise, Parrot's namespace is (half-)typed, at least namespace
> >and variable/sub are allowed to coexist with the same name. [1]
>
> I've implemented now b). The overhead is low (one if statement) and no
> additional storage space is used, if either a NameSpace or a var_or_sub
> is stored into a name slot.
Ah, well, I'm sorry to report that (a) was the correct answer; Parrot's
default should be entirely untyped.
Sorry I didn't catch this earlier, but I'm actually on the road today, so
it's a good thing I caught it now before users could start counting on it.
--
Chip Salzenberg <ch...@pobox.com>
Leopold Toetsch
On Mar 10, 2006, at 17:45, Chip Salzenberg wrote:
> Ah, well, I'm sorry to report that (a) was the correct answer; Parrot's
> default should be entirely untyped.
>
> Sorry I didn't catch this earlier, but I'm actually on the road today,
> so
> it's a good thing I caught it now before users could start counting on
> it.
The 'totally untyped' is in contradiction to the current implementation
(which the default NameSpace PMC ought to implement) and at least to
code in tests. I don't know, if it's used elsewhere too.
And pdd21 is distinguishing these opcodes as part of the raw interface:
$P0 = getnamespace xx
from
$P1 = find_global yy
*if* the default namespace is really that untyped, the former isn't
needed at all.
Therefore I'm not really happy with removing already implemented and
working code, the more that it would not conform to existing behavior
anymore.
leo
Chip Salzenberg
me know whether you'll suffer any breakage when/if Parrot default namespaces
go untyped, i.e. when you're no longer allowed to have a namespace and a
global variable with the same name but distinct. HLL-specific namespaces
will be able to make their own choices, so this issue only affects those
using the default namespace objects, i.e. Patrick, Allison, & co.)
On Fri, Mar 10, 2006 at 06:45:11PM +0100, Leopold Toetsch wrote:
> On Mar 10, 2006, at 17:45, Chip Salzenberg wrote:
> >Ah, well, I'm sorry to report that (a) was the correct answer; Parrot's
> >default should be entirely untyped.
>
> The 'totally untyped' is in contradiction to the current implementation
> (which the default NameSpace PMC ought to implement) and at least to
> code in tests. I don't know, if it's used elsewhere too.
>
> And pdd21 is distinguishing these opcodes as part of the raw interface:
> $P0 = getnamespace xx
> from
> $P1 = find_global yy
>
> *if* the default namespace is really that untyped, the former isn't
> needed at all.
Interesting conflict. Resolution(s):
1. Independent of other issues, you've prompted me to notice that I omitted
namespaces themselves from the namespace typed interface. Hence the
typed interface should include {add,del,find}_namespace methods. (I'd
have committed this already but I have an svn problem this morning.)
Confidence: HIGH
2. All Parrot internal code that manipulates nested namespaces, including
(but not limited to) the getnamespace opcode, should use the typed
interface. Specifically, it should use the {add,del,find}_namespace
methods mentioned in (1).
Confidence: HIGH
3. Given (1) and (2), the getnamespace opcode is useful regardless of
whether the *default* namespace is untyped, because the it will be used
to navigate through *non*-default namespaces as well as default ones,
and non-default namespaces can be typed.
Confidence: MEDIUM
(I don't like the idea of getnamespace being slowed down by using
named PMC methods rather than hash vtable entries, but I think I
can live with it until benchmarks demonstrate it's a bottleneck.)
4. I still like the idea of Parrot's default namespace being 100% untyped,
which imposes minimum surprise on users coming from various language
backgrounds, some of which are 100% untyped. In my experience, Perl
users understand Python naming easily, but the other way is harder.
Confidence: MEDIUM
(cont.)
> Therefore I'm not really happy with removing already implemented and
> working code, the more that it would not conform to existing behavior
> anymore.
5. It's possible that making the default namespace 100% untyped won't
actually break anything; it depends on whether anyone has actually
started to depend on namespaces and globals being distinct.
Confidence: UNKNOWN
PIR users: If namespace "foo" and global variable "foo" were no longer
distinct, so you had to rename one or the other in your code, would
you suffer any breakage in the first place, and if you did, would you
have a hard time fixing it?
PS: I'd have committed {add,del,find}_namespace to pdd03 but my svn is
busted this morning.
--
Chip Salzenberg <ch...@pobox.com>
Chip Salzenberg
On Tue, Mar 14, 2006 at 08:03:02AM -0800, Chip Salzenberg wrote:
> 1. Independent of other issues, you've prompted me to notice that I omitted
> namespaces themselves from the namespace typed interface. Hence the
> typed interface should include {add,del,find}_namespace methods.
Those methods are already there, of course. I guess I was smarter when I
wrote it than I am now. :-)
PS: *yawn*
--
Chip Salzenberg <ch...@pobox.com>
Chromatic
> PIR users: If namespace "foo" and global variable "foo" were no longer
> distinct, so you had to rename one or the other in your code, would
> you suffer any breakage in the first place, and if you did, would you
> have a hard time fixing it?
I doubt it and no. Forbidding "::" in namespace names will likely be more
work (not a lot, just comparatively more).
-- c
Patrick R. Michaud
> me know whether you'll suffer any breakage when/if Parrot default namespaces
> go untyped, i.e. when you're no longer allowed to have a namespace and a
> global variable with the same name but distinct. HLL-specific namespaces
> will be able to make their own choices, so this issue only affects those
> using the default namespace objects, i.e. Patrick, Allison, & co.)
Just to answer this quickly -- from my perspective I don't see
any particular need to have both a namespace and a distinct
(Parrot) global variable that has the same name as a namespace.
In particular, PGE doesn't make use of many variables that
exist outside of a namespace, and any exported symbol names that
I've created thus far have been chosen with the expectation that they
would likely change before all is said and done. :-)
Pm
Chip Salzenberg
What, you currently use "::" in your namespace names? On purpose? :-)
--
Chip Salzenberg <ch...@pobox.com>
Chromatic
> What, you currently use "::" in your namespace names? On purpose? :-)
<grandpa>I've had objects working in my PIR code before even Dan thought they
worked. Once upon a time, that *was* the way to go.
Now get off my lawn!</grandpa>
-- c
Chip Salzenberg
They'll still work. It'll just be a warning, and hopefully one that can be
turned off without editing the imcc source code.
--
Chip Salzenberg <ch...@pobox.com>