How to write a self.pm (Re: method calls on $self)

12 views
Skip to first unread message

Autrijus Tang

unread,
Jul 11, 2005, 10:17:01 PM7/11/05
to perl6-c...@perl.org, perl6-l...@perl.org
(Cross-posting the new ruling from p6l to p6c to discuss implementation strategy)

On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
> {
> let $Larry.decisive = 1;
>
> Okay, this is what we're gonna do. We're gonna go back pretty close to
> where we were originally, but with a twist. That is, .foo is always
> a call on the current topic, but the invocant is (again) always the
> topic in the outer scope of a method. The difference from before
> is that we simply outlaw .foo notation at *compile* time in those
> scopes where we know (at compile time) that $_ and $?SELF diverge.
> In such a scope you *must* specify $_ or $?SELF (or equivalent).
> (If necessary we can also compile .foo inside methods down to code
> that checks at runtime whether $_ has diverged from $?SELF and pitch
> a run-time fit for those situations we can't detect at compile time.
> Or we can just declare it erroneous.) Basically, you can't use .foo
> inside a "given" or a "for" inside a method.
>
> That's the default, and I'm not changing my mind ever again, at least
> till next week. That being said, if you mutate your language with
> anything like:
>
> use self "this";
> use self "self";
> use self "o";
> use self "./";
> use self "";
> ...
>
> then the pragma is allowed to warp .foo semantics to make it *always*
> refer to $_ everywhere, provided it *also* undoes the default binding
> of $_ := $?SELF, so people that people aren't tempted to use .foo to
> mean $?SELF.foo in that scope.
>
> Yes, this is possibly a hazard for cut-n-pasters. But then,
> you weren't supposed to be cutting-n-pasting anymore, were you?
> Shame on you. Move the common code to a role, or a base class.
> }

Normally, I try to comply with new rulings as soon as they become
available, but the implementation of this is nontrivial, so I'd welcome
more input.

The obvious thought is to have yet another magical, $^H like flag, to
denote the current dialect. If it is set, then the parser can emit
.method as $_.method, instead of $?IMPLICIT_INVOCANT.method. If it is
not set, the parser needs to emit this as the first statement in any
method body:

$_ := $?SELF

The compiler, in turn inspect whether there's an bound $_ in scope
with $?SELF set. It is not trivial, because this should work:

sub baz (&c) { c() }
method foo { baz { .bar } } # $_ is free in inner closure

But this needs to fail:

sub baz (&c) { c(1) }
method foo { baz { .bar } } # $_ is bound in inner closure

Clearly we need a way to statically determine &statement:<given>
and &statement:<for> will always assign at least one argument to
its block argument. Without that, the compile-time analysis mandated by
Larry is infeasible.

Then, we need to figure out the structure for the magic flag set by
self.pm on behalf of its caller. We are not using $^H anymore, so
there needs to be a way to pass lexical settings to the caller.

To use MJD's lexical pragma design:

module self;
use pragma;
sub import ($caller, $dialect) {
install_pragma_value('$?SELF_MAGICAL', $dialect);
}

This will create a lexically scoped hint in the importer's scope;
the parser and compiler will be hard-wired to recognise that magic
and act accordingly.

Does this seem sane? The static detection of $_ is the showstopper
currently, and Pugs will need to separate the compiler with PIL evaluator
to implement the pragma.pm above. Before that happens, I'll still
pretend that:

use self './';

is in scope. If people are uncomfortable with that, maybe we can
retrofit all tests and examples using the ./ syntax to add that dummy
line on top of their code, and ship with a stub self.pm that does
nothing. Will that do as a interim solution?

Thanks,
/Autrijus/

Autrijus Tang

unread,
Jul 12, 2005, 12:36:23 AM7/12/05
to perl6-c...@perl.org, perl6-l...@perl.org
On Mon, Jul 11, 2005 at 09:04:54PM -0700, Larry Wall wrote:
> On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
> : On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
> : The obvious thought is to have yet another magical, $^H like flag, to

> : denote the current dialect. If it is set, then the parser can emit
> : .method as $_.method, instead of $?IMPLICIT_INVOCANT.method.
>
> The parser always emits .method as $_.method under any dialect, or
> fails. What has changed is whether $_ sometimes means the invocant.

But the compiler needs to trigger ambiguity resolution -- i.e. check
for $?SELF agreement with $_ -- when it sees $?IMPLICIT_INVOCANT.

No need to do that if it sees $_.method. So they need to be different.

> In any event, SMD methods always have a first argument, so you're never
> in doubt at that point. And since .bar always means $_.bar, I don't
> think you really have a problem here that's any harder than you already
> had with $_.

The problem here is for the compiler to detect whether $_ agrees
with $?SELF, when it sees $?IMPLICIT_INVOCANT. If they agree,
$?IMPLICIT_INVOCANT gets replaced by $_; otherwise it is an error.

Consider this construct:

method foo {
$_ := $something_else if rand(2)>1;
.bar;
}

That's one case where it's not possible to detect at compile time,
so it needs to silently let .bar go thru as $_.bar.

> : Clearly we need a way to statically determine &statement:<given>


> : and &statement:<for> will always assign at least one argument to
> : its block argument. Without that, the compile-time analysis mandated by
> : Larry is infeasible.
>

> I think you can assume that "given" and "for" always bind at least one
> argument. In particular, a "for" that binds 0 arguments will never
> progress, plus you can recognize it:

But what in "given" and "for" signify that? I do not want to special
case based on function names, and &statement:<given> may be rebound
to something else. How does that something else signify that it will
at least bind at least one argument to its code argument? Via the
signature of the code argument, i.e. the <Any> in &code<Any>?

sub statement:<given> (Any $topic, &code<Any>) { ... }

If so, what is the signature of "for"? I can't seem to write it down.

> : Then, we need to figure out the structure for the magic flag set by


> : self.pm on behalf of its caller. We are not using $^H anymore, so
> : there needs to be a way to pass lexical settings to the caller.
>

> Perhaps hints should just be considered lexically scoped $? variables.
> You export them lexically just the same way you export any other lexically
> scoped things, however that is.
>
> How will you handle:
>
> use Foo :my<$x>;
>
> Seems like this is just a kind of
>
> use Foo :my<$?MYHINT>
>
> thingy, only perhaps you're just setting $?MYHINT rather than aliasing
> it back into a Foo variable.

Yes, that's the main difference. How does the :my<> form of export work
in the exporter's end?

sub foo is export<my> { ... }

Will that work?

> : Does this seem sane? The static detection of $_ is the showstopper


> : currently, and Pugs will need to separate the compiler with PIL evaluator
> : to implement the pragma.pm above.
>

> I suspect you're making it complicateder than it needs to be, but
> perhaps I don't understand the problem fully. Of course, the two are
> not mutually exclusive...

Indeed I suspect both are true. :)

Thanks,
/Autrijus/

Larry Wall

unread,
Jul 12, 2005, 12:04:54 AM7/12/05
to perl6-c...@perl.org, perl6-l...@perl.org
On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: The obvious thought is to have yet another magical, $^H like flag, to

: denote the current dialect. If it is set, then the parser can emit
: .method as $_.method, instead of $?IMPLICIT_INVOCANT.method.

The parser always emits .method as $_.method under any dialect, or


fails. What has changed is whether $_ sometimes means the invocant.

: If it is


: not set, the parser needs to emit this as the first statement in any
: method body:
:
: $_ := $?SELF

That is the part that has to be conditional on the dialect.

: The compiler, in turn inspect whether there's an bound $_ in scope


: with $?SELF set. It is not trivial, because this should work:
:
: sub baz (&c) { c() }
: method foo { baz { .bar } } # $_ is free in inner closure
:
: But this needs to fail:
:
: sub baz (&c) { c(1) }
: method foo { baz { .bar } } # $_ is bound in inner closure

The compiler is free to treat any undecidable binding as ambiguous
and die of uncertainty. Though we should probably make some official
rule so that different compilers don't end up with different definitions
of "undecidable".

In any event, SMD methods always have a first argument, so you're never
in doubt at that point. And since .bar always means $_.bar, I don't
think you really have a problem here that's any harder than you already
had with $_.

: Clearly we need a way to statically determine &statement:<given>


: and &statement:<for> will always assign at least one argument to
: its block argument. Without that, the compile-time analysis mandated by
: Larry is infeasible.

I think you can assume that "given" and "for" always bind at least one


argument. In particular, a "for" that binds 0 arguments will never
progress, plus you can recognize it:

for @foo -> {...}

And a given that doesn't bind $_ isn't worth much either.

Or is that what you're asking?

: Then, we need to figure out the structure for the magic flag set by


: self.pm on behalf of its caller. We are not using $^H anymore, so
: there needs to be a way to pass lexical settings to the caller.

Perhaps hints should just be considered lexically scoped $? variables.


You export them lexically just the same way you export any other lexically
scoped things, however that is.

: To use MJD's lexical pragma design:


:
: module self;
: use pragma;
: sub import ($caller, $dialect) {
: install_pragma_value('$?SELF_MAGICAL', $dialect);
: }
:
: This will create a lexically scoped hint in the importer's scope;
: the parser and compiler will be hard-wired to recognise that magic
: and act accordingly.

How will you handle:

use Foo :my<$x>;

Seems like this is just a kind of

use Foo :my<$?MYHINT>

thingy, only perhaps you're just setting $?MYHINT rather than aliasing
it back into a Foo variable.

: Does this seem sane? The static detection of $_ is the showstopper


: currently, and Pugs will need to separate the compiler with PIL evaluator
: to implement the pragma.pm above.

I suspect you're making it complicateder than it needs to be, but


perhaps I don't understand the problem fully. Of course, the two are
not mutually exclusive...

: Before that happens, I'll still pretend that:


:
: use self './';
:
: is in scope. If people are uncomfortable with that, maybe we can
: retrofit all tests and examples using the ./ syntax to add that dummy
: line on top of their code, and ship with a stub self.pm that does
: nothing. Will that do as a interim solution?

That's fine for the short term.

Larry

Larry Wall

unread,
Jul 12, 2005, 6:58:37 PM7/12/05
to perl6-c...@perl.org, perl6-l...@perl.org
On Tue, Jul 12, 2005 at 12:36:23PM +0800, Autrijus Tang wrote:

: On Mon, Jul 11, 2005 at 09:04:54PM -0700, Larry Wall wrote:
: > On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: > : On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: > : The obvious thought is to have yet another magical, $^H like flag, to
: > : denote the current dialect. If it is set, then the parser can emit
: > : .method as $_.method, instead of $?IMPLICIT_INVOCANT.method.
: >
: > The parser always emits .method as $_.method under any dialect, or
: > fails. What has changed is whether $_ sometimes means the invocant.
:
: But the compiler needs to trigger ambiguity resolution -- i.e. check
: for $?SELF agreement with $_ -- when it sees $?IMPLICIT_INVOCANT.
:
: No need to do that if it sees $_.method. So they need to be different.

Well, another approach is to treat .method as invariably $_.method,
and catch the problem at the attempt to rebind $_. Thomas seems to
think it should already be doing that. Of course, that would make it
impossible to use given or for inside a method at all...

So the other approach is to give up on compile-time checks and say
that $?IMPLICIT_INVOCANT.method in a method's lexical scope (and
in the absence of "use self") turns into

($_ =:= $?SELF ?? $_.method :: fail "Phooey")

: > In any event, SMD methods always have a first argument, so you're never


: > in doubt at that point. And since .bar always means $_.bar, I don't
: > think you really have a problem here that's any harder than you already
: > had with $_.
:
: The problem here is for the compiler to detect whether $_ agrees
: with $?SELF, when it sees $?IMPLICIT_INVOCANT. If they agree,
: $?IMPLICIT_INVOCANT gets replaced by $_; otherwise it is an error.
:
: Consider this construct:
:
: method foo {
: $_ := $something_else if rand(2)>1;
: .bar;
: }
:
: That's one case where it's not possible to detect at compile time,
: so it needs to silently let .bar go thru as $_.bar.

Though Thomas's constant binding notion would presumably catch that.
But then we're getting into the "noalias" zone that Dennis Ritchie hates.
On the other hand, I can see lots of uses for variables that may
not be rebound, at least in terms of reassuring the optimizer that
Weird Things Can't Happen.

: > : Clearly we need a way to statically determine &statement:<given>


: > : and &statement:<for> will always assign at least one argument to
: > : its block argument. Without that, the compile-time analysis mandated by
: > : Larry is infeasible.
: >
: > I think you can assume that "given" and "for" always bind at least one
: > argument. In particular, a "for" that binds 0 arguments will never
: > progress, plus you can recognize it:
:
: But what in "given" and "for" signify that? I do not want to special
: case based on function names, and &statement:<given> may be rebound
: to something else.

I understand the desire for generality, but that road also leads to
error messages that are completely opaque to naive users, who are
pretty accurate in their view that features like "given" and "for"
will Stay Put in the normal course of events. Many of the most useful
diagnostics in Perl 5 are the ones that are guessing based on common
usage patterns. Users can't do much with messages that when deciphered
come out to mean something like "you called a function passing as
its first argument another function whose first argument's declared
type allows it to be optionally bound to $_ but if we actually try to
make use of that we'll get some ambiguity further on down the road,
and that's bad." They'd much rather chuck the generality and have
"You can't say .foo inside "given" where the topic could be either $_
or the method's invocant." Or in the absense of that just blow up
at run time.

Of course, I'm just restating your problem here...

: How does that something else signify that it will


: at least bind at least one argument to its code argument? Via the
: signature of the code argument, i.e. the <Any> in &code<Any>?
:
: sub statement:<given> (Any $topic, &code<Any>) { ... }

Maybe something like:

sub statement:<given> (Any $topic, *&code:(Any is topic)) { ... }

: If so, what is the signature of "for"? I can't seem to write it down.

Good question. I suppose the signature wants to guarantee minimum arity
of 1 somehow. Maybe

sub statement:<for> (Lazy *@topics, *&code:(Any is topic, *)) { ... }

or some such. But whether the outer function is actually functioning
as a topicalizer would still depend on the innards of your function.
Hmm. We might settle for declaring such functions with a special trait
that indicates that they are *intended* to function as topicializers.
And then maybe the compiler could just depend on those declarations
for its static analysis:

sub statement:<given> (Any $topic, *&code:(Any)) is topicalizer { ... }

Other that that we rely on the run-time check. (Which hopefully common
code analysis can factor out multiple copies of.)

: > : Then, we need to figure out the structure for the magic flag set by


: > : self.pm on behalf of its caller. We are not using $^H anymore, so
: > : there needs to be a way to pass lexical settings to the caller.
: >
: > Perhaps hints should just be considered lexically scoped $? variables.
: > You export them lexically just the same way you export any other lexically
: > scoped things, however that is.
: >
: > How will you handle:
: >
: > use Foo :my<$x>;
: >
: > Seems like this is just a kind of
: >
: > use Foo :my<$?MYHINT>
: >
: > thingy, only perhaps you're just setting $?MYHINT rather than aliasing
: > it back into a Foo variable.
:
: Yes, that's the main difference. How does the :my<> form of export work
: in the exporter's end?
:
: sub foo is export<my> { ... }
:
: Will that work?

Hrm, I don't think so. For standard variables, that's not something
the exporter is supposed to worry about. It's the importer that
decides what scope to import into. The "is export<foo>" syntax is
for export tag groups, but those are orthogonal to the final scoping.

But since lexical scoping is the default import scope anyway, all we
need to do is make sure the hint variable gets exported mandatorily whether
requested or not, and maybe not worry about whether the user has a way
to divert the hint into a package variable. So maybe it's just

my $?MYHINT is export<MANDATORY> = 1;

Except for the small issue that this would also set $?MYHINT in this
scope. I suppose

{
my $?MYHINT is export<MANDATORY> = 1;
}

might be a workaround, but more likely we just need to tap into the
underlying exporter mechanism to create the lexical symbol and copy a
1 into it somehow rather than trying to create a spurious alias into
the exporting package that we'll throw away anyway. Maybe there's
some kind of syntactic sugar for that, like a special declarator:

importsym $?MYHINT = 1;

where ordinary export looks like

importsym &foo ::= &bar;

Or whatever fills the niche of Perl 5's glob assignments. We could go
as far as to just return a glob of code to eval after the "use", though
that's a bit source-filtery. I think low-level exportation needs to
be done with some kind of generics, but I haven't thought it through yet.

Maybe it looks like some kind of role-ish upscopey block structure.

EXPORT {
our $packagevar;
my $?MYHINT = 1;
mysym &foo ::= &OUTER::bar;
reexport Foo.all; # conjectural (as if the rest isn't...)
}

where "mysym" is a generic declarator that defaults to "my" but
is user overridable to "our" or "state" (which are also lexically
scoped names but have different dynamic lifetimes). An EXPORT block
would only promote to a scope that was currently being compiled.
Presumably you could have multiple EXPORT blocks, with implicit EXPORTs
being generated from "is export" declarations. Or else there's one
EXPORT and you have to call stdexports() from it if you rewrite it.
More likely EXPORTALL is the one export block that calls all the
individual implicit or explicit EXPORT blocks.

: > : Does this seem sane? The static detection of $_ is the showstopper


: > : currently, and Pugs will need to separate the compiler with PIL evaluator
: > : to implement the pragma.pm above.
: >
: > I suspect you're making it complicateder than it needs to be, but
: > perhaps I don't understand the problem fully. Of course, the two are
: > not mutually exclusive...
:
: Indeed I suspect both are true. :)

As you can plainly see, I also reserve the right to do both of those
at once all by myself. :-)

Larry

Gav....

unread,
Jul 15, 2005, 9:54:57 AM7/15/05
to perl6-c...@perl.org, perl6-l...@perl.org
Hi All,

Being a relative newcomer to all that is Perl 6, can someone tell me what
differences
I need to know in order to write/amend Perl 6 extension Modules as opposed
to
Perl 5 versions ?

I have downloaded PXPerl for Windows (which seems a bit broken to me atm)
and
wanted to start writing some (fairly basic to start with) Modules.

As Perl 6 Modules are to work with Perl 5 it makes sense for me to learn
this straight off.

Apologies for intruding on this list, but I see no perl6-modules list
anywhere and only
brief mentions of v6 Modules in places.

You are all doing a great job, and I want to do my bit to get Perl 6
working - if I can.

I guess I should us a linux box to keep up to date, best version to go for ?

Thanks

Gav...

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.15/49 - Release Date: 14/07/2005

Nathan Gray

unread,
Jul 15, 2005, 3:17:13 PM7/15/05
to Gav...., perl6-c...@perl.org
On Fri, Jul 15, 2005 at 09:54:57PM +0800, Gav.... wrote:
> Being a relative newcomer to all that is Perl 6, can someone tell me what
> differences
> I need to know in order to write/amend Perl 6 extension Modules as opposed
> to
> Perl 5 versions ?

A good starting place is:

http://svn.openfoundry.org/pugs/docs/other/porting_howto

> I have downloaded PXPerl for Windows (which seems a bit broken to me atm)
> and
> wanted to start writing some (fairly basic to start with) Modules.
>
> As Perl 6 Modules are to work with Perl 5 it makes sense for me to learn
> this straight off.
>
> Apologies for intruding on this list, but I see no perl6-modules list
> anywhere and only
> brief mentions of v6 Modules in places.

perl6-compiler is probably the best list for these kinds of questions,
at the moment, so you're in the right place.

> You are all doing a great job, and I want to do my bit to get Perl 6
> working - if I can.

Awesome.

> I guess I should us a linux box to keep up to date, best version to go for ?

Not really necessary, we've got quite a few architectures represented.
Linux is only one.

-kolibrie

Gav....

unread,
Jul 16, 2005, 9:03:59 AM7/16/05
to Nathan Gray, perl6-c...@perl.org
From: "Nathan Gray"

Looks good ,thanks.

For those of you that have been here a while I suspect you do not notice,
but to me there seems to be no structure, no definitive place where one can
go and find everything needed from a Central location. www.perl6.com would
have been an excellent place to house a central repository of information,
howtos, downloads, modules , samples etc etc, but unfortunatly seems to have
been nabbed by a cybersquatter (http://www.strangelogic.com/) unless one of
you lot of this site ? . Perl6.net/Perl6.org contain web versions of this
list. http://search.cpan.org/modlist/Perl6 is empty, there are Perl6 Modules
out there so why are they not in here, are all the v6 modules included in
Pugs? - Can Perl6 modules now be submitted to CPAN?

http://dev.perl.org/perl6/ would seem to be 'the' first port of call for
information would that be fair to say. From there , there are links to Pugs
and Parrot. For those that needed Perl 5, they downloaded Perl 5, if they
needed specific Modules they downloaded them. With Perl 6 in its current
form, new users can easily be confused, they still use Perl 5, then Parrot ,
then Pugs. What is the intention here, will all three be bundled together
and just called 'Perl 6' or will users still have to go to three different
sites to get a complete package?

| (I wrote earlier :-)


| > I have downloaded PXPerl for Windows (which seems a bit broken to me
atm)

I haven't really tried to test this yet, but hundreds of error messages flew
past on install, has
anyone else used this?

| perl6-compiler is probably the best list for these kinds of questions,
| at the moment, so you're in the right place.

Good to know ,thanks.

|
| > You are all doing a great job, and I want to do my bit to get Perl 6
| > working - if I can.
|
| Awesome.

Once I get my head around it that is. I have a couple of Modules in mind
that do
not seem to exist as Perl5 modules so hope I can fulfill both needs. What is
to
happen with the current list of Perl 5 Modules, are these to stay as they
are with
Perl 6 being able to read them ok, or is it preferred that they too be
converted.
Is there a Perl5 to Perl6 Module converter in the making ?

|
| > I guess I should us a linux box to keep up to date, best version to go
for ?
|
| Not really necessary, we've got quite a few architectures represented.
| Linux is only one.

Not neccessary for the Perl6 project probably, but in my best interests
would it
be better to have a linux flavour so I can keep using upto date versions of
Pugs/Parrot etc
or is there somebody here doing a good job of quick turnarounds in compling
Binary
distributions so windows users arent always a month behind.

Does someone here have a x86 version of Solaris 10 for example to test with,
if not
I could probably use that if it is supported.

Thanks

Gav...

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.

Version: 7.0.323 / Virus Database: 267.8.16/50 - Release Date: 15/07/2005

Stevan Little

unread,
Jul 16, 2005, 12:41:56 PM7/16/05
to Gav...., Nathan Gray, perl6-c...@perl.org
Gav,

Welcome aboard. You might also want to hop onto the #perl6 channel over
at irc.freenode.net it is where many of use spend way too much time,
and a great place for asking questions like these.

On Jul 16, 2005, at 9:03 AM, Gav.... wrote:
> For those of you that have been here a while I suspect you do not
> notice,
> but to me there seems to be no structure, no definitive place where
> one can
> go and find everything needed from a Central location. www.perl6.com
> would
> have been an excellent place to house a central repository of
> information,
> howtos, downloads, modules , samples etc etc, but unfortunatly seems
> to have
> been nabbed by a cybersquatter (http://www.strangelogic.com/) unless
> one of
> you lot of this site ? .

Actually it seems someone has done something here, because when I go to
www.perl6.com I get forwarded to
http://dev.perl.org/perl6/?HiFromPerl6.com.

As for the howtos, modules, etc. much of those are centrally located,
and that is in the Pugs distribution. It will certainly not be the
final place for them, but it is their current home.

> Perl6.net/Perl6.org contain web versions of this
> list. http://search.cpan.org/modlist/Perl6 is empty, there are Perl6
> Modules
> out there so why are they not in here, are all the v6 modules included
> in
> Pugs? - Can Perl6 modules now be submitted to CPAN?

CPAN has no real rules, so you can submit a Perl 6 module if you like,
but it will likely be frowned upon. Currently all the working Perl 6
modules are inside Pugs since that is the only thing which will
currently run them.

However, this will not always be like this, but since we are still very
early in the development of Perl 6/Pugs it makes sense.

> http://dev.perl.org/perl6/ would seem to be 'the' first port of call
> for
> information would that be fair to say. From there , there are links to
> Pugs
> and Parrot. For those that needed Perl 5, they downloaded Perl 5, if
> they
> needed specific Modules they downloaded them. With Perl 6 in its
> current
> form, new users can easily be confused, they still use Perl 5, then
> Parrot ,
> then Pugs. What is the intention here, will all three be bundled
> together
> and just called 'Perl 6' or will users still have to go to three
> different
> sites to get a complete package?

I can see your confusion, let me try to explain.

Pugs is (at the moment) just a reference implementation of Perl 6.
Autrijus is fond of saying that Pugs is "optimized for fun". Which is
to say that it is not meant to be the real Perl 6 production release,
but instead a "sandbox" in which everyone can experiment with the Perl
6 language, and therefore provide more concrete feedback to the Perl 6
design team.

Parrot is a virtual machine, from it's birth it was envisioned that it
would run Perl 6, however, Parrot is (and will be) much more than just
a Perl 6 VM. Currently Pugs will "use" Parrot to handle things like
Perl 6 rules and grammers, and Pugs also supports a very experimental
"compile Perl 6 for Parrot" feature.

And finally Perl 6 (the official release) does not exist yet.

> | perl6-compiler is probably the best list for these kinds of
> questions,
> | at the moment, so you're in the right place.
>
> Good to know ,thanks.

As I said above, #perl6 over on irc.freenode.net is also a very good
place. In fact, I highly recommend that you drop by and chat if you are
interested in doing any Perl 6 work.

> || > You are all doing a great job, and I want to do my bit to get
> Perl 6
> | > working - if I can.
> |
> | Awesome.
>
> Once I get my head around it that is. I have a couple of Modules in
> mind
> that do
> not seem to exist as Perl5 modules so hope I can fulfill both needs.
> What is
> to
> happen with the current list of Perl 5 Modules, are these to stay as
> they
> are with
> Perl 6 being able to read them ok, or is it preferred that they too be
> converted.

The idea is to have Perl 6 be able to load and run Perl 5 code. This
will be accomplished through the Ponie project, (which is an
implementation of Perl 5 on Parrot). Currently Pugs has support for
this and autrijus actually has some Perl 6 code in production, which
uses Pugs to load the Perl 5 DBI module.

> Is there a Perl5 to Perl6 Module converter in the making ?

I highly doubt this will ever exist. Not only is Perl 6 a very
different language from Perl 5, but good Perl 5 module design will not
be the same as good Perl 6 module design.

However, that said, we have ported a number of popular/useful Perl 5
modules to Perl 6. They can be found in the Pugs distribution here
http://svn.openfoundry.org/pugs/ext/

> | > I guess I should us a linux box to keep up to date, best version
> to go
> for ?
> |
> | Not really necessary, we've got quite a few architectures
> represented.
> | Linux is only one.
>
> Not neccessary for the Perl6 project probably, but in my best interests
> would it
> be better to have a linux flavour so I can keep using upto date
> versions of
> Pugs/Parrot etc
> or is there somebody here doing a good job of quick turnarounds in
> compling
> Binary
> distributions so windows users arent always a month behind.

Well to start with, being a month behind is a loooong period of time in
Pugs development. Pugs is a very fast moving project, so much so that
by the time the CPAN release hits the main CPAN mirror, it is usually
already out-dated.

There was someone who was making windows binaries, but I am not sure if
that is still the case. Again, #perl6 is a great place to ask about
this stuff.

> Does someone here have a x86 version of Solaris 10 for example to test
> with,
> if not
> I could probably use that if it is supported.

More tester and more platforms are always welcome. You might want to
check if GHC (the Glaskow Haskell Compiler) runs on that platform first
(as you will need that to compile Pugs).

Good luck, and I hope to see you on #perl6 :)

Stevan

Gav....

unread,
Jul 18, 2005, 7:39:36 AM7/18/05
to Stevan Little, Nathan Gray, perl6-c...@perl.org

----- Original Message -----
From: "Stevan Little" <ste...@iinteractive.com>
Subject: Re: Perl 6 Modules


| Gav,
|
| Welcome aboard. You might also want to hop onto the #perl6 channel over
| at irc.freenode.net it is where many of use spend way too much time,
| and a great place for asking questions like these.

Thanks, I have visited #perl6, being in Australia may be the reason why
I havent caught anyone there so far.


| Actually it seems someone has done something here, because when I go to
| www.perl6.com I get forwarded to
| http://dev.perl.org/perl6/?HiFromPerl6.com.

Spooky, something has been done , nothing to do with my mentioning
of it but the timing was there :)

|
| As for the howtos, modules, etc. much of those are centrally located,
| and that is in the Pugs distribution. It will certainly not be the
| final place for them, but it is their current home.

Thanks, yep got them. Some people may wish to 'view' some of what
is available before download, but that will come.

| CPAN has no real rules, so you can submit a Perl 6 module if you like,
| but it will likely be frowned upon. Currently all the working Perl 6
| modules are inside Pugs since that is the only thing which will
| currently run them.
|
| However, this will not always be like this, but since we are still very
| early in the development of Perl 6/Pugs it makes sense.

Yes, I get it now, having a section on CPAN dedicated to Perl6 Modules
does give the impression that is the expected place for them. Maybe it is
just there 'ready and waiting'. So I (or anyone) should submit to Autrijus
or to pugscode.org ? or to the list.

|
| Pugs is (at the moment) just a reference implementation of Perl 6.
| Autrijus is fond of saying that Pugs is "optimized for fun". Which is
| to say that it is not meant to be the real Perl 6 production release,
| but instead a "sandbox" in which everyone can experiment with the Perl
| 6 language, and therefore provide more concrete feedback to the Perl 6
| design team.
|
| Parrot is a virtual machine, from it's birth it was envisioned that it
| would run Perl 6, however, Parrot is (and will be) much more than just
| a Perl 6 VM. Currently Pugs will "use" Parrot to handle things like
| Perl 6 rules and grammers, and Pugs also supports a very experimental
| "compile Perl 6 for Parrot" feature.
|
| And finally Perl 6 (the official release) does not exist yet.

Thanks for the info.

El-Stupido question then using basic example :-

Supposing I have a .pl file that sends a newsletter and starts off with as
normal

#!/usr/bin/perl -w
use CGI::Carp qw(fatalsToBrowser);
use CGI qw(:standard);

use DBI;
$|=1;
$textfile = param('textfile');
$htmlfile = param('htmlfile');
$subject = param('subject');
#$username = param('username');

print "Content-type: text/html\n\n";

etc etc ......


What would be the changes required to write this a Perl 6 file, my guess is
:-

#!/usr/bin/pugs
use v6;

but I don't know about the rest of it.

I'd like to get this sorted first and then write a test perl6 module and use
that in my test perl 6 script. Then I think the fog will have cleared.

| As I said above, #perl6 over on irc.freenode.net is also a very good
| place. In fact, I highly recommend that you drop by and chat if you are
| interested in doing any Perl 6 work.

Will continue to do so and hope to catch some of you there, if only to watch
and learn for the first little while.

| The idea is to have Perl 6 be able to load and run Perl 5 code. This
| will be accomplished through the Ponie project, (which is an
| implementation of Perl 5 on Parrot). Currently Pugs has support for
| this and autrijus actually has some Perl 6 code in production, which
| uses Pugs to load the Perl 5 DBI module.

Cool, sounds like the sort of thing I need in my Q above.

|
| > Is there a Perl5 to Perl6 Module converter in the making ?
|
| I highly doubt this will ever exist. Not only is Perl 6 a very
| different language from Perl 5, but good Perl 5 module design will not
| be the same as good Perl 6 module design.
|
| However, that said, we have ported a number of popular/useful Perl 5
| modules to Perl 6. They can be found in the Pugs distribution here
| http://svn.openfoundry.org/pugs/ext/

Thanks, taking a look.

| Well to start with, being a month behind is a loooong period of time in
| Pugs development. Pugs is a very fast moving project, so much so that
| by the time the CPAN release hits the main CPAN mirror, it is usually
| already out-dated.
|
| There was someone who was making windows binaries, but I am not sure if
| that is still the case. Again, #perl6 is a great place to ask about
| this stuff.

Thanks Again, if there is a shortage of people doing this, maybe it is
something
I could do if there was a demand. (?)

| More tester and more platforms are always welcome. You might want to
| check if GHC (the Glaskow Haskell Compiler) runs on that platform first
| (as you will need that to compile Pugs).

The main site mentions Solaris but then the downloads page does not, so I
guess
I'll go for FreeBSD or Windows version.

Thanks

Gav...

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.

Version: 7.0.323 / Virus Database: 267.9.0/50 - Release Date: 16/07/2005

Darren Duncan

unread,
Jul 18, 2005, 4:56:21 PM7/18/05
to perl6-c...@perl.org
At 7:39 PM +0800 7/18/05, Gav.... wrote:
>What would be the changes required to write this a Perl 6 file, my guess is
>:-
>
>#!/usr/bin/pugs
>use v6;
>
>but I don't know about the rest of it.
>
>I'd like to get this sorted first and then write a test perl6 module and use
>that in my test perl 6 script. Then I think the fog will have cleared.

If you want to write your program now, you should look at the 'CGI'
module that is already ported to native Perl 6, and use that. The
'DBI' module hasn't been ported yet, but you can use the Perl 5
version by saying 'use perl5:DBI' or something like that (you may
need to explicitly build Pugs with Perl 5 linked in, for that to
work). Then you just have to update the rest of your code to be good
Perl 6. Lots of examples exist now with Pugs. -- Darren Duncan

Reply all
Reply to author
Forward
0 new messages