Mailing List Archive

Pre-RFC: a `module` keyword
I've been thinking about this a lot and I wanted to run an idea past P5P. Corinna tremendously cleans up Perl's OOP capabilities. It would be nice to have something like that for procedural code. I have no sponsor for this, but I was thinking about a `module` keyword. It would complement Corinna syntax and look something like this:

    module Some::Utilities :version(3.14) {
        # all subs with an :export tag can be imported individually

        # use Some::Utilities ':strings';
        sub make_slug :export(strings) ($name) {
            ...
        }

        # use Some::Utilities ':numbers';
        sub constrain :export(numbers) ( $min, $num, $max = undef ) {
            ...
        }

        # use Some::Utilities ':numbers';
        sub weighted_pick :export(numbers) ($weight_for) {
            ...
        }
    
        # cannot be exported
        sub _binary_range ( $elem, $list ) {
            ...
        }
    }

Benefits:

* Postfix block lexically scopes changes
* Strict, warnings, utf8 source, signatures, and "no feature 'indirect'" by default
* :export is handled natively leaving the import() free for other uses
* Yields a `1` to avoid needing to add `1` at the end of every file.

Deliberately limited in scope to make it smaller and easier to implement. I believe that with `module` and `class`, we have a solid foundation for releasing Perl 7.

Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl
Re: Pre-RFC: a `module` keyword [ In reply to ]
On Mon, 24 Jan 2022 19:20:41 +0000 (UTC)
Ovid via perl5-porters <perl5-porters@perl.org> wrote:

> I've been thinking about this a lot and I wanted to run an idea past
> P5P. Corinna tremendously cleans up Perl's OOP capabilities. It would
> be nice to have something like that for procedural code. I have no
> sponsor for this, but I was thinking about a `module` keyword.

Yeah we discussed that back in Amsterdam 2019. It seemed a reasonable
idea then.

I had a go at implementing it:

https://github.com/leonerd/perl5/tree/module

It's a little out-of-date at the moment but I suspect it can be updated
quite easily

>
> Benefits:
>
> * Postfix block lexically scopes changes
> * Strict, warnings, utf8 source, signatures, and "no feature
> 'indirect'" by default

already done

> * :export is handled natively leaving the import() free for other uses
> * Yields a `1` to avoid needing to add `1` at the end of every file.

both seem good ideas.

I especially like the `:export` attribute - that's always struck me as
a much nicer way to do things than the current OHMYGODTHEHACK that is
Exporter.pm.


As a Pre-RFC I like this idea. If nobody else has any huge "absolutely
no because ${^SOLID_REASON}" I suggest writing it up as a full RFC.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Pre-RFC: a `module` keyword [ In reply to ]
On Mon, 24 Jan 2022 19:20:41 +0000 (UTC)
Ovid via perl5-porters <perl5-porters@perl.org> wrote:

> * Strict, warnings, utf8 source, signatures, and "no feature 'indirect'" by default

We can't make the "module" keyword visible without a feature flag. "use
VERSION" will still be needed and that enables all the nice stuff
anyway. Well, apart from "use utf8". It's been decided that it's a bad
default: https://www.nntp.perl.org/group/perl.perl5.porters/2021/08/msg261164.html

> * :export is handled natively leaving the import() free for other uses

I don't see why a new keyword is needed for that. If we want ':export'
attribute (which is an interesting idea), it can be implemented without
the "module" keyword. Perl already supports attributes on subs and we
already have a few built-in ones (such as :const, :method etc.).

The "package" keyword currently doesn't take attributes, but I think it
can be changed. "package Foo :bar" is a syntax error, so it probably
doesn't conflict with anything.

We should be always wary of adding new keywords, especially the ones that
do the same thing as already existing keywords but slightly differently.
We will be stuck with both keywords forever. It will make the language
more complex and confusing.

Of course, I'm not saying we should never do this, but we must carefully
weigh the costs and benefits. In this case, I'm not convinced the
benefits are big enough.

>* Yields a `1` to avoid needing to add `1` at the end of every file.

I think we should get rid of that misfeature completely.
Re: Pre-RFC: a `module` keyword [ In reply to ]
On Mon, Jan 24, 2022 at 3:39 PM Tomasz Konojacki <me@xenu.pl> wrote:

> On Mon, 24 Jan 2022 19:20:41 +0000 (UTC)
> Ovid via perl5-porters <perl5-porters@perl.org> wrote:
>
> > * Strict, warnings, utf8 source, signatures, and "no feature 'indirect'"
> by default
>
> We can't make the "module" keyword visible without a feature flag. "use
> VERSION" will still be needed and that enables all the nice stuff
> anyway. Well, apart from "use utf8". It's been decided that it's a bad
> default:
> https://www.nntp.perl.org/group/perl.perl5.porters/2021/08/msg261164.html
>
> > * :export is handled natively leaving the import() free for other uses
>
> I don't see why a new keyword is needed for that. If we want ':export'
> attribute (which is an interesting idea), it can be implemented without
> the "module" keyword. Perl already supports attributes on subs and we
> already have a few built-in ones (such as :const, :method etc.).
>
> The "package" keyword currently doesn't take attributes, but I think it
> can be changed. "package Foo :bar" is a syntax error, so it probably
> doesn't conflict with anything.
>
> We should be always wary of adding new keywords, especially the ones that
> do the same thing as already existing keywords but slightly differently.
> We will be stuck with both keywords forever. It will make the language
> more complex and confusing.
>
> Of course, I'm not saying we should never do this, but we must carefully
> weigh the costs and benefits. In this case, I'm not convinced the
> benefits are big enough.
>
> >* Yields a `1` to avoid needing to add `1` at the end of every file.
>
> I think we should get rid of that misfeature completely.
>

+1 to all your points. Prior discussion on "return true":
https://github.com/Perl/perl5/issues/17921

-Dan
Re: Pre-RFC: a `module` keyword [ In reply to ]
On Monday, 24 January 2022, 21:39:08 CET, Tomasz Konojacki <me@xenu.pl> wrote:

> > * Strict, warnings, utf8 source, signatures, and "no feature 'indirect'" by default
>
> We can't make the "module" keyword visible without a feature flag. "use
> VERSION" will still be needed and that enables all the nice stuff
> anyway. 

My intention for the full RFC was:

    use feature 'module';

> Well, apart from "use utf8". It's been decided that it's a bad
> default: https://www.nntp.perl.org/group/perl.perl5.porters/2021/08/msg261164.html

The change is lexically scoped, so ...

    use 5.38.0;

    module My::Module :version(.1) {
        # use utf8 is only applied here in brand new code
    }

    # use utf8 does not apply here

> > * :export is handled natively leaving the import() free for other uses
>
> I don't see why a new keyword is needed for that. If we want ':export'
> attribute (which is an interesting idea), it can be implemented without
> the "module" keyword. Perl already supports attributes on subs and we
> already have a few built-in ones (such as :const, :method etc.).

There is no new keyword. Instead, this follows the Corinna "KIM syntax" (https://ovid.github.io/articles/language-design-consistency.html) to ensure language design consistency. :import is a modifier, not a keyword. This RFC would introduce only one new keyword, `module`, and `:import` doesn't exist without that feature.

> The "package" keyword currently doesn't take attributes, but I think it
> can be changed. "package Foo :bar" is a syntax error, so it probably
> doesn't conflict with anything.

Agreed, but I'm trying to create something which is entirely lexically scoped in a new syntax to avoid complicating existing code.

> We should be always wary of adding new keywords, especially the ones that
> do the same thing as already existing keywords but slightly differently.
> We will be stuck with both keywords forever. It will make the language
> more complex and confusing.

Agreed. That's why only `module` is a new keyword. If `module` goes away, so does `:import` and `:version` (for `package`, it would still be there for Corinna's `class` keyword).

Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl
Re: Pre-RFC: a `module` keyword [ In reply to ]
On Mon, Jan 24, 2022 at 3:58 PM Ovid via perl5-porters <
perl5-porters@perl.org> wrote:

> On Monday, 24 January 2022, 21:39:08 CET, Tomasz Konojacki <me@xenu.pl>
> wrote:
>
> > > * Strict, warnings, utf8 source, signatures, and "no feature
> 'indirect'" by default
> >
> > We can't make the "module" keyword visible without a feature flag. "use
> > VERSION" will still be needed and that enables all the nice stuff
> > anyway.
>
> My intention for the full RFC was:
>
> use feature 'module';
>
> > Well, apart from "use utf8". It's been decided that it's a bad
> > default:
> https://www.nntp.perl.org/group/perl.perl5.porters/2021/08/msg261164.html
>
> The change is lexically scoped, so ...
>
> use 5.38.0;
>
> module My::Module :version(.1) {
> # use utf8 is only applied here in brand new code
> }
>
> # use utf8 does not apply here
>

The reasons for it being a "bad default" are not elided by only being used
for new code.


> > > * :export is handled natively leaving the import() free for other uses
> >
> > I don't see why a new keyword is needed for that. If we want ':export'
> > attribute (which is an interesting idea), it can be implemented without
> > the "module" keyword. Perl already supports attributes on subs and we
> > already have a few built-in ones (such as :const, :method etc.).
>
> There is no new keyword. Instead, this follows the Corinna "KIM syntax" (
> https://ovid.github.io/articles/language-design-consistency.html) to
> ensure language design consistency. :import is a modifier, not a keyword.
> This RFC would introduce only one new keyword, `module`, and `:import`
> doesn't exist without that feature.
>

I believe he was referring to adding the new keyword "module" for this,
when it could be done more generally.


> > The "package" keyword currently doesn't take attributes, but I think it
> > can be changed. "package Foo :bar" is a syntax error, so it probably
> > doesn't conflict with anything.
>
> Agreed, but I'm trying to create something which is entirely lexically
> scoped in a new syntax to avoid complicating existing code.
>

Restricting it to a block is not required for it to be lexically scoped for
new code - feature bundles already do this.

-Dan
Re: Pre-RFC: a `module` keyword [ In reply to ]
On Mon, Jan 24, 2022 at 4:13 PM Dan Book <grinnz@gmail.com> wrote:

> On Mon, Jan 24, 2022 at 3:58 PM Ovid via perl5-porters <
> perl5-porters@perl.org> wrote:
>
>> On Monday, 24 January 2022, 21:39:08 CET, Tomasz Konojacki <me@xenu.pl>
>> wrote:
>>
>> > > * Strict, warnings, utf8 source, signatures, and "no feature
>> 'indirect'" by default
>> >
>> > We can't make the "module" keyword visible without a feature flag. "use
>> > VERSION" will still be needed and that enables all the nice stuff
>> > anyway.
>>
>> My intention for the full RFC was:
>>
>> use feature 'module';
>>
>> > Well, apart from "use utf8". It's been decided that it's a bad
>> > default:
>> https://www.nntp.perl.org/group/perl.perl5.porters/2021/08/msg261164.html
>>
>> The change is lexically scoped, so ...
>>
>> use 5.38.0;
>>
>> module My::Module :version(.1) {
>> # use utf8 is only applied here in brand new code
>> }
>>
>> # use utf8 does not apply here
>>
>
> The reasons for it being a "bad default" are not elided by only being used
> for new code.
>
>
>> > > * :export is handled natively leaving the import() free for other uses
>> >
>> > I don't see why a new keyword is needed for that. If we want ':export'
>> > attribute (which is an interesting idea), it can be implemented without
>> > the "module" keyword. Perl already supports attributes on subs and we
>> > already have a few built-in ones (such as :const, :method etc.).
>>
>> There is no new keyword. Instead, this follows the Corinna "KIM syntax" (
>> https://ovid.github.io/articles/language-design-consistency.html) to
>> ensure language design consistency. :import is a modifier, not a keyword.
>> This RFC would introduce only one new keyword, `module`, and `:import`
>> doesn't exist without that feature.
>>
>
> I believe he was referring to adding the new keyword "module" for this,
> when it could be done more generally.
>
>
>> > The "package" keyword currently doesn't take attributes, but I think it
>> > can be changed. "package Foo :bar" is a syntax error, so it probably
>> > doesn't conflict with anything.
>>
>> Agreed, but I'm trying to create something which is entirely lexically
>> scoped in a new syntax to avoid complicating existing code.
>>
>
> Restricting it to a block is not required for it to be lexically scoped
> for new code - feature bundles already do this.
>

To add my own specificity to xenu's points: I think these are all good
ideas which don't require a new keyword or feature to implement.

-Dan
Re: Pre-RFC: a `module` keyword [ In reply to ]
What about auto-including the 'feature' if the very first line (second if
there is a shebang) started with the 'module' keyword? That would be very
unlikely to break compatibility with existing code, and allows less
boilerplate for module-only files. Might not need the block scope in such
cases either.

-Chad

On Mon, Jan 24, 2022 at 1:16 PM Dan Book <grinnz@gmail.com> wrote:

> On Mon, Jan 24, 2022 at 4:13 PM Dan Book <grinnz@gmail.com> wrote:
>
>> On Mon, Jan 24, 2022 at 3:58 PM Ovid via perl5-porters <
>> perl5-porters@perl.org> wrote:
>>
>>> On Monday, 24 January 2022, 21:39:08 CET, Tomasz Konojacki <me@xenu.pl>
>>> wrote:
>>>
>>> > > * Strict, warnings, utf8 source, signatures, and "no feature
>>> 'indirect'" by default
>>> >
>>> > We can't make the "module" keyword visible without a feature flag. "use
>>> > VERSION" will still be needed and that enables all the nice stuff
>>> > anyway.
>>>
>>> My intention for the full RFC was:
>>>
>>> use feature 'module';
>>>
>>> > Well, apart from "use utf8". It's been decided that it's a bad
>>> > default:
>>> https://www.nntp.perl.org/group/perl.perl5.porters/2021/08/msg261164.html
>>>
>>> The change is lexically scoped, so ...
>>>
>>> use 5.38.0;
>>>
>>> module My::Module :version(.1) {
>>> # use utf8 is only applied here in brand new code
>>> }
>>>
>>> # use utf8 does not apply here
>>>
>>
>> The reasons for it being a "bad default" are not elided by only being
>> used for new code.
>>
>>
>>> > > * :export is handled natively leaving the import() free for other
>>> uses
>>> >
>>> > I don't see why a new keyword is needed for that. If we want ':export'
>>> > attribute (which is an interesting idea), it can be implemented without
>>> > the "module" keyword. Perl already supports attributes on subs and we
>>> > already have a few built-in ones (such as :const, :method etc.).
>>>
>>> There is no new keyword. Instead, this follows the Corinna "KIM syntax" (
>>> https://ovid.github.io/articles/language-design-consistency.html) to
>>> ensure language design consistency. :import is a modifier, not a keyword.
>>> This RFC would introduce only one new keyword, `module`, and `:import`
>>> doesn't exist without that feature.
>>>
>>
>> I believe he was referring to adding the new keyword "module" for this,
>> when it could be done more generally.
>>
>>
>>> > The "package" keyword currently doesn't take attributes, but I think it
>>> > can be changed. "package Foo :bar" is a syntax error, so it probably
>>> > doesn't conflict with anything.
>>>
>>> Agreed, but I'm trying to create something which is entirely lexically
>>> scoped in a new syntax to avoid complicating existing code.
>>>
>>
>> Restricting it to a block is not required for it to be lexically scoped
>> for new code - feature bundles already do this.
>>
>
> To add my own specificity to xenu's points: I think these are all good
> ideas which don't require a new keyword or feature to implement.
>
> -Dan
>
Re: Pre-RFC: a `module` keyword [ In reply to ]
On Mon, 24 Jan 2022 14:46:35 -0800
Chad Granum <exodist7@gmail.com> wrote:

> What about auto-including the 'feature' if the very first line
> (second if there is a shebang) started with the 'module' keyword?
> That would be very unlikely to break compatibility with existing
> code, and allows less boilerplate for module-only files. Might not
> need the block scope in such cases either.

I think that was the conclusion we came to in Amsterdam.

*technically* it's possible someone might write some code like this,
but that's fantastically unlikely:

module($_) for qw( some args here );

sub module { ... }

Much less likely if you try to find something with the parens in there.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Pre-RFC: a `module` keyword [ In reply to ]
The best gamblers stop when they're ahead. I recommend we follow
the tempered course laided out in RJBS' email from the PRC, then
see what all can be back filled in "non-corina" POOP. I mean, there
are probably some sensible things C<bless> and C<package> could
provide in a backcompat way that would also fit whatever niche that
has yet to be identified as inspiration from what's moving ahead.

It's not unlike the feedback loop that at one point had developed
between perl 6 and perl 5, thought that seems to have run its
course. So maybe see if something similar is begs itself later?

I mean, I think Util::H2O "tremendously cleans up" a lot of hairy
procedural, hashref-heavy code with ad hoc accessors on refs
in-flight; but I also am not prepared to pre-RFC it's inclusion in
core or a dual life module - I am tempted, though. :-)

Cheers,
Brett

* Ovid via perl5-porters <perl5-porters@perl.org> [2022-01-24 19:20:41 +0000]:

> I've been thinking about this a lot and I wanted to run an idea past P5P. Corinna tremendously cleans up Perl's OOP capabilities. It would be nice to have something like that for procedural code. I have no sponsor for this, but I was thinking about a `module` keyword. It would complement Corinna syntax and look something like this:
>
> ? ? module Some::Utilities :version(3.14) {
> ? ? ? ? # all subs with an :export tag can be imported individually
>
> ? ? ? ? # use Some::Utilities ':strings';
> ? ? ? ? sub make_slug :export(strings) ($name) {
> ? ? ? ? ? ? ...
> ? ? ? ? }
>
> ? ? ? ? # use Some::Utilities ':numbers';
> ????????sub constrain :export(numbers) ( $min, $num, $max = undef ) {
> ? ? ? ? ? ? ...
> ? ? ? ? }
>
> ? ? ? ? # use Some::Utilities ':numbers';
> ????????sub weighted_pick :export(numbers) ($weight_for) {
> ? ? ? ? ? ? ...
> ????????}
> ????
> ????????# cannot be exported
> ????????sub _binary_range ( $elem, $list ) {
> ? ? ? ? ? ? ...
> ? ? ? ? }
> ????}
>
> Benefits:
>
> * Postfix block lexically scopes changes
> * Strict, warnings, utf8 source, signatures, and "no feature 'indirect'" by default
> * :export is handled natively leaving the import() free for other uses
> * Yields a `1` to avoid needing to add `1` at the end of every file.
>
> Deliberately limited in scope to make it smaller and easier to implement. I believe that with `module` and `class`, we have a solid foundation for releasing Perl 7.
>
> Best,
> Ovid
> --?
> IT consulting, training, specializing in Perl, databases, and agile development
> http://www.allaroundtheworld.fr/.?
>
> Buy my book! - http://bit.ly/beginning_perl
>

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Re: Pre-RFC: a `module` keyword [ In reply to ]
On Tue, 25 Jan 2022 at 06:47, Chad Granum <exodist7@gmail.com> wrote:

> What about auto-including the 'feature' if the very first line (second if
> there is a shebang) started with the 'module' keyword? That would be very
> unlikely to break compatibility with existing code, and allows less
> boilerplate for module-only files. Might not need the block scope in such
> cases either.
>

Too fragile...

Compare this:

module Example { print "$x" } # compilation error, since `use strict` is
in effect

and this:

# See examples/whatever.pl for practical uses of this module
module Example { print "$x" } # since this is no longer the first line, we
have no `strict`, no `warnings`

Plus all the usual versioning problems - defaults that seem reasonable now
will be outdated by the time Perl 5.46 is released.
Re: Pre-RFC: a `module` keyword [ In reply to ]
On 2022-01-24 11:20 a.m., Ovid via perl5-porters wrote:
> I've been thinking about this a lot and I wanted to run an idea past P5P. Corinna tremendously cleans up Perl's OOP capabilities. It would be nice to have something like that for procedural code. I have no sponsor for this, but I was thinking about a `module` keyword. It would complement Corinna syntax ...

I realize that Raku has the module+class duality, but how does it help Perl that
Corinna hasn't already done?

Is the point that "module" is for routines that do NOT have associated private
storage like static/shared class fields?

Does Corinna have the concept of static classes like Java/etc where one can
declare a class but can not instantiate an instance/object of it and the class
methods can only be used as "ClassName::method_name()" or exported as
"method_name()"?

If Corinna does NOT have classes that can't be instantiated as objects, then I
see a value to have a "module" which fills the standalone never used with an
object role.

But if Corinna does support static/non-instantiable classes, then I see no
reason to have "module" too.

Or if "module" exists, then Corinna should be that all classes must be
instantiable, even if they are singletons due to having no fields.

-- Darren Duncan
Re: Pre-RFC: a `module` keyword [ In reply to ]
I like the idea of syntactic support for function libraries, but I don’t like the proposed use of the word "module".

We have existing, well-established, terminology where a module is a package in a .pm file of the corresponding name, and a module can either be a class or a function library (or the love child of both).

I don’t have a great alternative to suggest ("sublibrary", "exporter", "library", … ?)

Neil
Re: Pre-RFC: a `module` keyword [ In reply to ]
On 2022-01-25 2:41 a.m., Neil Bowers wrote:
> I like the idea of syntactic support for function libraries, but I don’t like
> the proposed use of the word "module".
>
> We have existing, well-established, terminology where a /module/ is a package in
> a .pm file of the corresponding name, and a module can either be a class /or/ a
> function library (or the love child of both).
>
> I don’t have a great alternative to suggest ("sublibrary", "exporter",
> "library", … ?)

I don't have a problem with the term "module" for this. It works for Raku.

However, I'm also okay with considering some other terms.

The "exporter" one is I feel the best out of what you enumerated, and is very
specific to the main distinctiveness of these.

I oppose using the keyword "library" or any compound based on it, as this is
best kept as a very generic term that covers any kind of Perl package or
collection of such.

Outside those, experience in designing my own Muldis Object Notation / Muldis
Data Language / etc, has shown that a thesaurus is a great help.

Basically, its good to look in a thesaurus for inspiration for many other words
we can pick which don't already have programming language associations and so we
can invent whatever meaning we want.

For example, see all the various synonyms for "package" or "library" or "book"
etc, see one we like and give it the meaning we want.

Otherwise, I'd go with either "module" or "exporter".

-- Darren Duncan
Re: Pre-RFC: a `module` keyword [ In reply to ]
On Tue, Jan 25, 2022 at 5:42 AM Neil Bowers <neilb@neilb.org> wrote:

> I like the idea of syntactic support for function libraries, but I don’t
> like the proposed use of the word "module".
>
> We have existing, well-established, terminology where a *module* is a
> package in a .pm file of the corresponding name, and a module can either be
> a class *or* a function library (or the love child of both).
>
> I don’t have a great alternative to suggest ("sublibrary", "exporter",
> "library", … ?)
>

Each of these features can simply be implemented in the existing syntax and
no new keyword is needed.

-Dan
Re: Pre-RFC: a `module` keyword [ In reply to ]
Hi Curtis,

We think there's definitely scope for improving Perl's support for creating modules of function libraries, and the import mechanism.

Some of what you proposed is effectively supported already with the `package Foo::Bar 0.001 { ... }` syntax.

There are a lot of modules on CPAN that solve different subsets of "the problem" (for example there are modules that use attributes for tagging functions for export), and your proposal feels like it's adding to that, rather than proposing a unified step forward.

So in its current form, we've marked this as rejected, but we think this is an area that's ripe for more thought. Part of that should include a review of CPAN and the problems with the current options. Finally, we agreed that in whatever form, we're not likely to ever accept a `module` keyword to mean "a collection of functions", given the established definition of "module".

Neil
Re: Pre-RFC: a `module` keyword [ In reply to ]
Thanks for that, Neil. It makes perfect sense. I knew `module` was problematic, but given that the best alternative I had was `library`, I chose `module`. Suggestions welcome.

I'll see what people are doing on the CPAN.

Best,
Ovid/Curtis
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl






On Friday, 11 February 2022, 10:52:36 CET, Neil Bowers <neilb@neilb.org> wrote:








Hi Curtis,

We think there's definitely scope for improving Perl's support for creating modules of function libraries, and the import mechanism.

Some of what you proposed is effectively supported already with the `package Foo::Bar 0.001 { ... }` syntax.

There are a lot of modules on CPAN that solve different subsets of "the problem" (for example there are modules that use attributes for tagging functions for export), and your proposal feels like it's adding to that, rather than proposing a unified step forward.

So in its current form, we've marked this as rejected, but we think this is an area that's ripe for more thought. Part of that should include a review of CPAN and the problems with the current options. Finally, we agreed that in whatever form, we're not likely to ever accept a `module` keyword to mean "a collection of functions", given the established definition of "module".

Neil
Re: Pre-RFC: a `module` keyword [ In reply to ]
Hi there,

On Fri, 11 Feb 2022, Ovid via perl5-porters wrote:

> ... given that the best alternative I had was `library`, I chose
> `module`. Suggestions welcome.

Trying for a short word which will be substantially different and
hopefully not be too contentious,

as in basement: vault
as in capsule: pill
as in pile: rick

Come to think of it, 'capsule' doesn't seem too bad even if it is
seven characters. A good thesaurus is your friend.

--

73,
Ged.
Re: Pre-RFC: a `module` keyword [ In reply to ]
Hi there,

On Fri, 11 Feb 2022, Ovid via perl5-porters wrote:

> ... given that the best alternative I had was `library`, I chose
> `module`. Suggestions welcome.

Trying for a short word which will be substantially different and
hopefully not be too contentious,

as in basement: vault
as in capsule: pill
as in pile: rick

Come to think of it, 'capsule' doesn't seem too bad even if it is
seven characters. A good thesaurus is your friend.

--

73,
Ged.
Re: Pre-RFC: a `module` keyword [ In reply to ]
On 2022-02-12 12:42 a.m., G.W. Haywood via perl5-porters wrote:
> On Fri, 11 Feb 2022, Ovid via perl5-porters wrote:
>
>> ... given that the best alternative I had was `library`, I chose
>> `module`. Suggestions welcome.
>
> Trying for a short word which will be substantially different and
> hopefully not be too contentious,
>
> as in basement: vault
> as in capsule: pill
> as in pile: rick
>
> Come to think of it, 'capsule' doesn't seem too bad even if it is
> seven characters.  A good thesaurus is your friend.

That's exactly what I said a few times, including earlier in this very thread, a
good thesaurus is your friend, use it to take words without existing use in the
field so you can invent the meaning you want.

This being said, following my own advice when naming things in the past, I found
there is a huge overlap between appropriate names for libraries/modules/etc and
appropriate names for collection data types.

Regarding "capsule" specifically, while that could work, I feel it sounds more
like a container data type. But whatever.

-- Darren Duncan
Re: Pre-RFC: a `module` keyword [ In reply to ]
On 2022-02-12 12:48 a.m., Darren Duncan wrote:
> On 2022-02-12 12:42 a.m., G.W. Haywood via perl5-porters wrote:
>> On Fri, 11 Feb 2022, Ovid via perl5-porters wrote:
>>
>>> ... given that the best alternative I had was `library`, I chose
>>> `module`. Suggestions welcome.
>>
>> Trying for a short word which will be substantially different and
>> hopefully not be too contentious,
>>
>> as in basement: vault
>> as in capsule: pill
>> as in pile: rick
>>
>> Come to think of it, 'capsule' doesn't seem too bad even if it is
>> seven characters.  A good thesaurus is your friend.
>
> That's exactly what I said a few times, including earlier in this very thread, a
> good thesaurus is your friend, use it to take words without existing use in the
> field so you can invent the meaning you want.
>
> This being said, following my own advice when naming things in the past, I found
> there is a huge overlap between appropriate names for libraries/modules/etc and
> appropriate names for collection data types.
>
> Regarding "capsule" specifically, while that could work, I feel it sounds more
> like a container data type.  But whatever.

Responding to myself, what I specifically thought at the time was that "capsule"
was a good alternate name to essentially the same concept as an "object". And I
actually used the name Capsule for a time as a data type, before I ended up
changing the name to Article (as in "article of clothing" or "newspaper
article") in my own project.

-- Darren Duncan
Re: Pre-RFC: a `module` keyword [ In reply to ]
On Friday, 11 February 2022, 10:52:36 CET, Neil Bowers <neilb@neilb.org> wrote:

> We think there's definitely scope for improving Perl's support for creating modules
> of function libraries, and the import mechanism.

<snip>

> So in its current form, we've marked this as rejected, but we think this is an area
> that's ripe for more thought. Part of that should include a review of CPAN and the
> problems with the current options.

I've been mulling over this for some time because I wanted to have clear thoughts on it and check what's on the CPAN.

I withdraw the `:version` and `:export` parts of this, though I would love to see a lexical export solution. However, the core idea seems solid. Unfortunately, I cannot find anything on the CPAN which solidly supports what I'm looking for. Going with `library` instead of `module` as a keyword:

    library My::Library 0.01 {
        sub foo ($bar) { ... }

        library Pretty { # My::Library::Pretty
            # Public
        }
        library Utils :private { # My::Library::Utils
            # Private to My::Library and enclosed libraries
        }
    }

(I get sick and tired of writing "Utils" packages to organize my code and littering the global namespace)

I could write up more (better keyword suggestions needed), but I simply can't find anything comparable on the CPAN and despite asking around, no one else has offered suggestions. Can anyone offer pointers?
       
Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl