develooper Front page | perl.perl5.porters | Postings from June 2022

Re: Pre-RFC: A built-in ability for lexical import/export

Thread Previous | Thread Next
Paul "LeoNerd" Evans
June 27, 2022 13:40
Re: Pre-RFC: A built-in ability for lexical import/export
Message ID:
On Fri, 24 Jun 2022 16:44:27 +0100
"Paul \"LeoNerd\" Evans" <> wrote:

> I was thinking that maybe it should be just exposed as a builtin::
> function itself, perhaps as
>   builtin::lexically_export $name, \&func;

I've had a bit of a go at implementing this:

> Perhaps it should take a whole kv-list of name/ref pairs, so you can
> export lots in one go:
>   builtin::lexically_export
>     one => \&one,
>     two => \&two, ...

It currently doesn't do this yet, but shouldn't be hard to add.

In the process of writing it I've come up with some more questions, to
which I don't have an easy answer:

  * Should it support things other than functions? Should we support

      lexically_export VAR => \my $scalar;

  * If so, should names be sigil-prefixed?

      lexically_export '$VAR' => \my $scalar, '&func' => sub {...};

While I don't think it is common to want to export things other than
functions, it does occasionally happen (e.g. think the $LOG variable of
various logger modules, or the $METRICS of Metrics::Any). It would be
nice to support these in some way.

If we do support them, it raises the question on whether the "name"
argument to lexically_export() itself should include the sigil part of
it. In the vastly-common majority of cases, they'll all just be
functions, so it feels annoying to have to '&'-prefix them all -
especially if it would otherwise break the neat way of using
"name => \&name" notation.

On the other hand, it would lead to an awkward situation if you wanted
to export more than one item of the same basename:

    FOO => \my $s, FOO => \my @arr, FOO => \my %hash, FOO => sub {};

This would technically be fine as it would create four separately named
items in the caller - $FOO, @FOO, %FOO and &FOO (callable as FOO()).
But it does feel strange, and breaks the otherwise neat hash-like
name/value pair structure of the arguments. I'm not sure I like it.

Instead, perhaps a compromise idea taken from the way
works; which is to say that sigils would be required for
scalar/hash/array variables, but not required for regular functions.

    name   => \&function,   # a regular function
    '$VAR' => \my $scalar,  # a scalar variable
    '@VAR' => \my @arr,     # an array variable
    '%VAR' => \my %hash,    # a hash variable

    '&func' => \&func,      # also permitted for symmetry, but not
                            #   required

I.e. the model being "if no sigil is specified, presume &"; and
additionally, error if the sigil doesn't match the thing being

I think this feels sane - does anyone disagree?

Paul "LeoNerd" Evans      |  |

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About