Re: Nested modules
Luke Palmer wrote:
So, we can have :: in names, but that doesn't represent any inherent
relationship between the module before the :: and the one after. I
think this is an important thing to keep.
However, will it be possible to, for example, do:
module Foo;
module Bar { ... }
And refer to the inner module as, say, Foo.Bar.
Kinda like an inner class in Java?
A more interesting
concept, can one use variables as modules, like:
::($foo)::somefunc();
except dynamic?
(On a side note, that syntax doesn't seem right, although I can't
fathom what is...)
Or some awful thing like that?
And of course this would imply the existance of anonymous modules. Yay.
How... would that be useful? What would one use an anonymous
module for that they couldn't do with an anonymous class? I
thought a module was more of a compiletime distinction, while
a class was a runtime + compiletime (i.e. all encompassing)
one.
- Joe
How to get environment variables?
Is it possible to get environment variables from perl6 programme? It failes when I try to use perl5 hash %ENV. Thanks.
Re: How to get environment variables?
[EMAIL PROTECTED] (Andrew Shitov) writes:
Is it possible to get environment variables from perl6 programme? It
failes when I try to use perl5 hash %ENV. Thanks.
Are you sure you're using the Perl 6 hash syntax? (%ENV{FOO} rather than Perl
5-style $ENV{FOO})
What version of Perl 6 are you using?
--
The C Programming Language -- A language which combines the power of
assembly language with the flexibility of assembly language.
Re: How to get environment variables?
I tried this one-line programme for example:
my %e = %ENV;
and got this (parrot-0.0.13/perl are built under mandrake linux):
Global '_HV_ENV' not found
Error: '/parrot-0.0.13/parrot -r env.imc ' failed with exit code 1
Stopped at /parrot-0.0.13/languages/perl6/perl6 line 339
main::mydie(256,'/parrot-0.0.13/parrot -r env.imc ') called at
/parrot-0.0.13/languages/perl6/perl6 line 819
main::pass4('env.imc','env.warn') called at
/parrot-0.0.13/languages/perl6/perl6 line 741
main::pass2('env.imc','env.warn') called at
/parrot-0.0.13/languages/perl6/perl6 line 435
main::output_tree('P6C::prog=ARRAY(0x8ef6e5c)','env.p6','env.warn')
called at /parrot-0.0.13/languages/perl6/perl6 line 500
main::pass1('Parse::RecDescent=HASH(0x8f2ed70)','env.p6','env.warn','undef') called at /parrot-0.0.13/languages/perl6/perl6 line 562
main::run() called at /parrot-0.0.13/languages/perl6/perl6 line 219
Are you sure you're using the Perl 6 hash syntax? (%ENV{FOO} rather than Perl
5-style $ENV{FOO})
What version of Perl 6 are you using?
This week's summary
The Perl 6 Summary of the week ending 20031102 It's Monday morning, the croissants have been baked, the focaccia is glistening with all the extra virgin olive oil I poured on it as it left the oven and, in the airing cupboard, a raisin borodinsky slouches towards full proof (thought at the rate it's currently rising it'll probably be Tuesday before I can bake it off), what better time could there be to pause and write a summary? So, I'll kick off with perl6-internals because, well, it's on the summary checklist (which goes something like: 1. Wibble about the weather or something before; 2. Start with perl6-internals; 3. Continue with perl6-language if it saw any traffic; 4. Make announcements, suggest people give money to the Perl Foundation; 5. Make sure Leon Brocard gets a mention; 6. Aspell; 7. Mail PODs to http://perl.com and a text version to perl6-announce; 8. Profit!) NULL Px Proposal Right at the end of the previous week, Melvin Smith suggested having the initial 'empty' PMC registers all point at a global PMCNull which would throw an exception if you tried to invoke any of its methods. Which sounds weird, but it does mean that you get a real exception instead of a segfault, and exceptions are so much more trappable. Dan liked the idea. Melvin later posted a patch implementing the idea, which Leo Ttsch fixed up slightly an applied. http://xrl.us/2w8 http://xrl.us/2w9 Parrot Calling Convention Confusion Steve Fink is having problems using an unprototyped call to a prototyped function, which he thinks is a reasonable thing to do (and I think I agree with him; I can imagine cases where you have a function pointer or something where you don't know its exact prototype, but you do want to make a call to it so you'd be forced to make an unprototyped call.). Melvin Smith disagrees with him. Steve then went on to point out that he's still getting failures when the function is both declared and called in an unprototyped fashion. According to Leo, this is because unprototyped returns are neither defined nor implemented. Which is odd really -- I thought they were exactly the same as an unprototyped call, but you invoke the return continuation (P1) instead of P0, the other registers are set up exactly as if you were making an unprototyped function call. http://xrl.us/2xa A clash of symbols Arthur Bergman, Ponie stablemaster, popped up to point out that definitions like #define version obj.version (found in include/parrot/pobj.h if you're interested) did some scary things to Perl_utilize in the Perl 5 core. Steve Fink stuck his hand up to being the person who added the version field (which is apparently rather handy if you're debugging the Garbage Collection (GC) system. Leo fixed things by applying a s/version/pobj_version/g patch. http://xrl.us/2xb Storing external data in PMCs Arthur popped up again asking for help with implementing a Perl5LVALUE PMC. It turns out that the API doesn't quite support what he needs. After a certain amount of discussion of various options Arthur proposed a Parrot_PMC_attach_data(Parrot, PMC, *void) extension to the API. He didn't *quite* get what he wanted, but he got something very like it later in the week. I did like Arthur's reasons for starting the serious Ponie effort by working on Perl5LVALUEs though: [because] it is so obscure that it's hardly used anywhere and is limited to a few small areas in the core. http://xrl.us/2xc Screaming Pumpkins Ahoy! On Monday, Leo declared that yes, Melvin Smith's proposed Halloween 'Screaming Pumpkin' Parrot release would be happening. Various people promised extra goodies, and a few problems were sorted out with some platforms. Features were frozen on Wednesday and Parrot 0.0.13 Screaming Pumpkin was released upon a cowering world at 2003103114:11:46 precisely. For all the astonishing speed of the release cycle, there's a lot of good stuff to be had in the screaming pumpkin, check out Leo's announcement for details. http://xrl.us/2xd http://xrl.us/2xe -- Leo's announcement Header Dependencies Jrgen Bmmels wasn't entirely happy with the way Parrot's headers are set up. Apparently there are some nasty dependency (and crypto dependency) issues. He proposed fixing up the headers as much as possible to eliminate these issues. Dan and Leo thought it would be nice, but Dan thought there wouldn't be that much point in doing it as things would probably decay, and pretty much everything internal should just be using parrot.h, and everything external should be using extend.h or embed.h. http://xrl.us/2xf Tinderboxen Jrgen Bmmels triggered a quick bout of tinderbox fixing, as various different hardware
Re: Nested modules
On Sun, Nov 02, 2003 at 07:50:05PM -0700, Luke Palmer wrote:
: So, we can have :: in names, but that doesn't represent any inherent
: relationship between the module before the :: and the one after. I
: think this is an important thing to keep.
:
: However, will it be possible to, for example, do:
:
: module Foo;
:
: module Bar { ... }
That just makes another global module named Bar. To get an inner
module, you'd have to use what we already use to get packaged
names of variables:
module Foo;
our module Bar { ... }
: And refer to the inner module as, say, Foo.Bar.
Its full name would be Foo::Bar. The other would be a Bar method
call on class Foo, presumably.
: A more interesting
: concept, can one use variables as modules, like:
:
: ::($foo)::somefunc();
:
: Or some awful thing like that?
Yes, there's going to be a ::() interpolation syntax for names.
: And of course this would imply the existance of anonymous modules. Yay.
Yes, and you left out lexical modules:
module Foo;
my module Bar { ... }
In theory I suppose you could have objects with module attributes:
class Foo {
has module .Bar { ... }
}
Just don't ask me what it means...
Larry
Re: Nested modules
Larry wrote:
In theory I suppose you could have objects with module attributes:
class Foo {
has module .Bar { ... }
}
Just don't ask me what it means...
Of course, Larry's just joking there...he knows precisely what it means.
It means that every object of class Foo has its own private version of
the .Bar module which in turn has its own private namespace. So that, for
example, any reference to a package variable of that module:
method Foo::baz {
$.Bar::qux++;
}
refers to the $qux variable belonging to the .Bar module belonging to the Foo
object on which the baz method was invoked.
This kind of behaviour is more useful for nested classes, I suspect, but
it should certainly be available for nested modules as well.
Damian
Re: Nested modules
Damian Conway wrote: Larry wrote: This kind of behaviour is more useful for nested classes, I suspect, but it should certainly be available for nested modules as well. So, what's the difference between a module and a class, and why would you want dynamic namespaces? Isn't that something you'd use a class for? I'm a bit confused. (-: - Joe
