Syntax of using Perl5 modules?

9 views
Skip to first unread message

Autrijus Tang

unread,
May 25, 2005, 12:06:19 AM5/25/05
to perl6-l...@perl.org
So, this now works in Pugs with (with a "env PUGS_EMBED=perl5" build):

use Digest--perl5;

my $cxt = Digest.SHA1;
$cxt.add('Pugs!');

# This prints: 66db83c4c3953949a30563141f08a848c4202f7f
say $cxt.hexdigest;

This includes the "Digest.pm" from Perl 5. DBI.pm, CGI.pm etc will
also work.

Now my question is, is my choice of using the "perl5" namespace indicator a
sane way to handle this? Is it okay for Perl 6 to fallback to using Perl 5
automatically? Or should I use something else than "use" entirely?

Thanks,
/Autrijus/

Darren Duncan

unread,
May 25, 2005, 2:56:39 AM5/25/05
to perl6-l...@perl.org

I would say that one should always have to specify the Perl 5
namespace in some way, so that there are no surprises as to whether
something you invoke is implemented in Perl 6 or Perl 5, and so that
it is possible to be actively using a Perl 5 and Perl 6 module with
the same short name at the same time.

Do not fallback to it automatically.

Rather, if someone wanted to not fill their Perl 6 code with
"--perl5", they should use the Perl 6 feature that lets you create
lexical aliases to things; they can explicitly declare a Perl 6 name
for what they want to use, which just so happens to be an alias for
the Perl 5 implementation.

I won't suggest exact syntax here, though yours looks fine for now.

Separately, since this together with the earlier 'inline' feature for
Perl 5 sort of completes a circle of Pugs->Perl5->Pugs or
Perl5->Pugs->Perl5, I see a further improvement that could possibly
be made, if it isn't already.

That is, when you have three-somes like that, let the two endmost
Pugs, or endmost Perl5, be the exact same interpreter in memory. So
that, eg, if you set a global var in the caller-most Perl5, it will
be visible in the called-most Perl5, or vice-versa.

On the other hand, I don't know whether or not that would be better
in practice than keeping separate interpreters for calling and called.

-- Darren Duncan

Terrence Brannon

unread,
May 25, 2005, 10:43:25 AM5/25/05
to Autrijus Tang, perl6-l...@perl.org
Autrijus Tang <autr...@autrijus.org> writes:

> So, this now works in Pugs with (with a "env PUGS_EMBED=perl5" build):
>
> use Digest--perl5;
>
> my $cxt = Digest.SHA1;
> $cxt.add('Pugs!');
>
> # This prints: 66db83c4c3953949a30563141f08a848c4202f7f
> say $cxt.hexdigest;
>
> This includes the "Digest.pm" from Perl 5. DBI.pm, CGI.pm etc will
> also work.
>
> Now my question is, is my choice of using the "perl5" namespace indicator a
> sane way to handle this?

I was getting used to ":" as an adverbial and adjective modifier. So I
would think the above would be:

use Digest:perl5

but that would be confusing given that two colons separate parts of a
package namespace.

--
Carter's Compass: I know I'm on the right track when,
by deleting something, I'm adding functionality.

Dave Whipp

unread,
May 25, 2005, 12:20:46 PM5/25/05
to perl6-l...@perl.org

To my mind, the coupling seems wrong. If the "use" statement needs to
state the language of the included module, then it would be difficult to
later re-implement that module in p6.

My understanding is that there are clear rules (see S11) to distinguish
p5 modules from p6: if the first keyword in the file is "module" or
"class", then it's p6; otherwise assume p5.

Your use of hyphens puts your "perl5" indicator in the "URI" field
(again, see S11), which is expected to refer to the author. "perl5"
doesn't seem correct in this context. Even if you got rid of one of the
hypthens (so that "perl5" is the "version"), then it still feels wrong.
Each version of a module should be free to choose its language, but that
should be encapsulated within the module.

If you do want to impose the language from the "use"er, the I'd expect
an adverbial syntax: "use:p5 Digest;".


Dave.

Rod Adams

unread,
May 25, 2005, 1:11:34 PM5/25/05
to perl6-l...@perl.org
Autrijus Tang wrote:

Personally, I question the need for any flag saying it's perl5, and
actually would prefer there be no such thing.

Consider S01: "Migration is important. The perl interpreter will assume
that it is being fed Perl 5 code unless the code starts with a "class"
or "module" keyword, or you specifically tell it you're running Perl 6
code in some other way,", which sounds to me like a "yes" to your
fallback question.

On the migration front, when someone ports Digest.pm to Perl6, I get a
"free" upgrade, assuming the module author was kind enough to up the
version number.


Glancing at S11, I see where you're coming from. There is some logic in
giving all the p5 modules an author of "perl5", since they will not have
one on their own. However, I think the calling syntax would have to be
"use Digest-(Any)-perl5;" to force the usage of a perl5 version.

-- Rod Adams

Adam Kennedy

unread,
May 26, 2005, 9:02:02 AM5/26/05
to perl6-l...@perl.org
> On the migration front, when someone ports Digest.pm to Perl6, I get a
> "free" upgrade, assuming the module author was kind enough to up the
> version number.

You are making a pretty huge assumption here that whoever has a
namespace in p5 CPAN has first dibs at the P6 namespace of the same
name, and that they will do a straight port over.

Someone else could reimplement the module for Perl 6, or perhaps the
author wants to (desperately needed in some cases)completely overhaul
the module and API based on lessons learnt the first time.

The problem with automatic fallback is simple that you are no longer
getting two different versions of the same module, you are getting two
completely different libraries, with no guarentee that the API is
consistent.

Automatic fallback lets changes in environment leak into the process and
cause unexpected changes in program functionality, and this is BAD.

The only time at which having to do nothing to load a current CPAN
module will be during the transition period, before a suffucient body of
Perl 6 modules have built up.

In the longer run, much better to have to do something special to get
the old and redundant versions of modules.

Adam K

Rod Adams

unread,
May 26, 2005, 1:59:40 PM5/26/05
to perl6-l...@perl.org
Adam Kennedy wrote:

You get all those possibilities whenever you install any new version of
a module you get from someone else, regardless of a p5->p6 hop. In p6,
when you say "use Digest;", you are specifically asking for what p6
considers the "latest" version. In p5, it was "first match on libpath".

I believe the ability to specify what versions and/or authors of the
module you find permissible in p6 can completely resolve your issues. If
you care about getting an exact version of a module, ask for it, and
you'll get it or die.

In p5, your only options were to 1) not install the new version 2)
install it, and globally update your code to match, 3) give each script
it's own libpath.

I still think auto fallback makes sense. If you don't like it, always
fully specify your "use" statements. See S11 for details.

-- Rod Adams

Clement Cherlin

unread,
May 27, 2005, 12:44:51 AM5/27/05
to
In article <20050525040...@aut.dyndns.org>, autr...@autrijus.org
(Autrijus Tang) wrote:

I think Perl 6 should either use a namespace for Perl 5 modules, such as

use Perl5::Digest;

or simply treat all modules alike

use Digest;

which gets a Perl 6 version if available, then falls back to Perl 5.

Adam Kennedy

unread,
May 27, 2005, 12:02:03 AM5/27/05
to perl6-l...@perl.org
> You get all those possibilities whenever you install any new version of
> a module you get from someone else, regardless of a p5->p6 hop. In p6,
> when you say "use Digest;", you are specifically asking for what p6
> considers the "latest" version. In p5, it was "first match on libpath".

Except that within Perl 5, there is an general expectation that the same
API will exist across multiple module versions. It is assumed that newer
versions of a module will continue to work the same as older ones, with
API breakages being a bad and rare thing.

The 6 month long mod_perl Apache::->Apache2:: argument was over this
very thing. There is a huge difference between an API version and a
module (implementation) version.

As far as I'm aware, there is no expectation that *every* module in Perl
6 that shares a name with a module in Perl 5 will merely be a
re-implementation of the same API in Perl6.

If I am expected to reimplement all my Perl 5 modules in Perl 6 without
the opportunity to do a better job and take advantage of new Perl 6
API-related features, could someone please point my boot in the general
direction of the ass of whoever came up with that idea.

Adma K

Rod Adams

unread,
May 27, 2005, 5:07:38 AM5/27/05
to perl6-l...@perl.org
Adam Kennedy wrote:

<soapbox>
Across all languages, libraries, modules, applications, operating
systems, and most everything else in the computer world, I expect
interoperability to remain mostly the same across minor version numbers,
but anything goes when a new major version comes out. Now, I'm not
terribly active in the CPAN arena, but I think it's short sighted to
expect the API from version 1.1.5 to still be there in 2.7.1. This
phenomenon is why it's fairly common to see the last minor version of
the previous major version still around and available in many areas.
Major changes in usage and syntax are what major version jumps are all
about.
</soapbox>

As an alternative, the URI field of the module version could be extended
to have the API version mixed somehow, maybe "cpan:JRANDOM#1.5.6". But
that gets non-intuitive and ugly very quickly.

Part of the p5 problem is that module upgrades were all or nothing. In
p6, you'll be able to load both the old version and the new version, at
the same time. Or just tell the old apps that you don't have time to fix
to use versions < 2.0.0, and the new apps to use version >= 2.0.0.

Another part of the problem with p5 is that while there was the ability
to spec a version in a 'use' call, it was only a lower bound. You
couldn't specify an upper bound as well, to tell people that you weren't
ready for a new API/semantics. (To my knowledge, _nobody_ overrides the
VERSION method)


Personally, I would prefer having to track which major version number
I'm using over the mess that's in CPAN, where it seems like the standard
way to introduce a new API is to come up with a new name for the module
that means the same thing. However, as I pointed out before, since in p5
there is no notion of an author URI, haveing that become the string
'perl5' makes sense, and could be matched against, both positively and
negatively.

-- Rod Adams

Reply all
Reply to author
Forward
0 new messages