RFC0020: A builtin for Lexical Export #20

leonerd · 2022-06-28T14:10:54Z

No description provided.

ivrntsv · 2022-06-29T18:20:52Z

Why it is lexically_export and not export_lexically? I think verb should be first.

leonerd · 2022-06-29T18:58:25Z

Why it is lexically_export and not export_lexically? I think verb should be first.

Hmm i hadn't thought about that. I'm not fussed either way. We should probably make it whatever seems more consistent with other things.

haarg · 2022-06-29T19:21:32Z

Could also be export_lexical. I'm not too bothered either way.

ivrntsv · 2022-06-29T20:14:43Z

I am not so fluent in English so I don't know whether some way is preffered from the language point of view. But from what I saw in programming languages without function overloading there is a naming pattern like action_some_concretization. For unrelated illustration: In Perl you can call sort function with package function: sort numerically @arr. So for me export_lexically sounds more naturally. But this is just a suggestion, food for thought.

rwp0 · 2022-06-30T00:51:36Z

I'm for export or lexport to make things simpler

leonerd · 2022-06-30T14:13:17Z

I'm for export or lexport to make things simpler

I think export is a bit too short for clarity. It doesn't express the lexical nature. I could imagine some sort of builtin function to tidy up the way we do symbolic package exports:

export_symbolically $caller, name => \&func, name2 => \&func2, ...;

rwp0 · 2022-06-30T15:47:07Z

I'm for export or lexport to make things simpler

I think export is a bit too short for clarity. It doesn't express the lexical nature. I could imagine some sort of builtin function to tidy up the way we do symbolic package exports:
export_symbolically $caller, name => \&func, name2 => \&func2, ...; 

Hmm, do you mean a function in addition to the proposed :export attribute?

I'll add l_export to my list of names.

Leont · 2022-06-30T21:20:20Z

rfcs/rfc0020.md

+
+## Motivation
+
+"Traditional" Perl modules of the era around Perl 5.8 have always used symbolic aliasing into the caller's package to implement their export mechanism. This was the only mechanism available to them at the time, and served well in the era of procedural modules with functions in them. As more code became object-oriented, using packages to implement classes, the problems of making these exports visible as named symbols in the class's namespace became apparent, because each imported function would be visible as a named method on the class, whether it wanted that or not.


Not just that era, that has true ever since 5.0

Leont · 2022-07-01T10:36:22Z

rfcs/rfc0020.md

+
+If no sigil is present on the name argument, it is presumed to be of the first kind, and the value must be a `CODE` reference.
+
+As the only effect this function has is to add new things to the compiletime lexical scope, it shall be an error to call this function during regular runtime, when no code is currently being compiled. It shall also be an error to pass non-reference values, references to unsupported items (e.g. globs), or references whose type does not match the sigil of its name.


I'm not sure I like how the the compiletime lexical scope is implicit, are we sure that's good enough? (though OTOH hints and hints hash already have that issue and we survive fine)

What would the alternative be?

It has to be a compiletime scope, because that's the only thing that can work. It's unlikely there are multiple nested ones, and in any case I think it would be weird if we were to try to allow some kind of "uplevel" ability to affect scopes beyond the immediate caller. I don't think there's any other way we could offer.

leonerd · 2022-07-02T13:23:09Z

There seems various thoughts on the name of this. I'm not overly attached to any of them so I think lets propose a vote on the various ideas. Use the "+1" thumbs-up reaction for voting on the following ideas.

Besides the name, is there any other concern anyone has?

leonerd · 2022-07-02T13:23:18Z

VOTE: lexically_export

leonerd · 2022-07-02T13:23:27Z

VOTE: export_lexically

leonerd · 2022-07-02T13:23:33Z

VOTE: export_lexical

tonycoz · 2022-07-04T01:47:40Z

rfcs/rfc0020.md

+ If the name is a `SCALAR` reference, a new scalar variable will be created in the scope. The corresponding name argument must begin with a `$` sigil.
+
+ If the name is an `ARRAY` reference, a new array variable will be created in the scope. The corresponding name argument must begin with a `@` sigil.
+
+ If the name is a `HASH` reference, a new hash variable will be created in the scope. The corresponding name argument must begin with a `%` sigil.


Shouldn't these all be "If the value is a ... reference" rather than "If the name is a ... reference"?

Oops, absolutely right. Fix pushed.

ivrntsv · 2022-07-04T11:09:03Z

I'm sorry guys. I don't want to test your patience. But how about export_lex and hypothetical export_sym (which this RFC is not about)?

leonerd · 2022-07-04T11:16:16Z

@ivrntsv

But how about export_lex and hypothetical export_sym

I'm not sure that lex is sufficiently meaningful to new/casual readers, to work out what the thing is (Same as lexport).

This is no longer the 1980s, with code stored on reels of tape or punched cards where every byte matters. We're allowed to spell words out in full now ;)

leonerd · 2022-07-04T11:25:48Z

It seems export_lexical is currently the vote-winner. I'm not entirely sure how I feel about a function named as a singular noun ("lexical") having the ability to create multiple lexicals, but nevertheless I'll update the spec for that.

ivrntsv · 2022-07-04T11:28:16Z

As I see export_lexical is preffered by voters. But that mean mixing verb and adjective. Or maybe in that case export is noun. It should be written lexical_export then. I preffer to mix verb and adverb in export_lexically. Maybe the short variant is the winner so I suggested export_lex as variant. But I don't insist.

Addition: After some thought I see that lexical adjective plays well with exportable noun(s) that follow. Now I'm at peace. Thank you))

ivrntsv · 2022-07-04T16:09:11Z

I can't get this thing out of my head. So one final (I wish) thought. export_as_lexical (hypothetical export_as_symbol). This as part will give understanding that something exportable will become a lexical variable (or a package symbol) on the user side. export_lexical tells to export something lexical which is not true. Most of the time you export something global from a package.

leonerd · 2022-07-04T22:35:36Z

Hmm.. that is true. It's not that the thing being exported is necessarily a lexical (indeed; most of the time for doing coderefs it probably won't be). It's that once exported, the new thing that is created is a lexical. So maybe the word as should be part of its name.

iabyn · 2022-07-05T08:27:09Z

On Mon, Jul 04, 2022 at 03:35:50PM -0700, Paul Evans wrote: Hmm.. that is true. It's not that the thing *being* exported is necessarily a lexical (indeed; most of the time for doing coderefs it probably won't be). It's that once exported, the new thing that is created is a lexical. So maybe the word `as` should be part of its name.

'export_lexically' would correctly describe how the thing is being exported rather than what is being exported.

…

-- You never really learn to swear until you learn to drive.

leonerd · 2022-07-05T09:56:37Z

@iabyn

'export_lexically' would correctly describe how the thing is being exported rather than what is being exported.

Indeed - is why I voted for that one in particular; though it seems export_lexical currently has 7 votes to its 5. But perhaps this distinction is enough to sway it in favour anyway..?

leonerd · 2022-07-08T21:10:57Z

Righty. Setlled on export_lexically

leonerd changed the title ~~Write RFC0020 - A builtin for Lexical Export~~ RFC0020 - A builtin for Lexical Export Jun 28, 2022

leonerd mentioned this pull request Jun 28, 2022

Add builtin::export_lexically Perl/perl5#19895

Merged

leonerd force-pushed the rfc0020 branch from 22581d5 to c70eedc Compare June 29, 2022 11:48

leonerd changed the title ~~RFC0020 - A builtin for Lexical Export~~ RFC0020: A builtin for Lexical Export Jun 29, 2022

Leont reviewed Jun 30, 2022

View reviewed changes

Leont reviewed Jul 1, 2022

View reviewed changes

tonycoz reviewed Jul 4, 2022

View reviewed changes

RFC0020: A builtin for Lexical Export

6fbbacb

leonerd force-pushed the rfc0020 branch from 78f7cc1 to 6fbbacb Compare July 8, 2022 21:09

leonerd merged commit 844eda1 into Perl:main Jul 8, 2022

leonerd deleted the rfc0020 branch July 8, 2022 21:13

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RFC0020: A builtin for Lexical Export #20

RFC0020: A builtin for Lexical Export #20

leonerd commented Jun 28, 2022

ivrntsv commented Jun 29, 2022 •

edited

leonerd commented Jun 29, 2022

haarg commented Jun 29, 2022

ivrntsv commented Jun 29, 2022

rwp0 commented Jun 30, 2022

leonerd commented Jun 30, 2022

rwp0 commented Jun 30, 2022 •

edited

Leont Jun 30, 2022

Leont Jul 1, 2022

haarg Jul 1, 2022

leonerd Jul 2, 2022

leonerd commented Jul 2, 2022

leonerd commented Jul 2, 2022

leonerd commented Jul 2, 2022

leonerd commented Jul 2, 2022

tonycoz Jul 4, 2022

leonerd Jul 4, 2022

ivrntsv commented Jul 4, 2022 •

edited

leonerd commented Jul 4, 2022

leonerd commented Jul 4, 2022

ivrntsv commented Jul 4, 2022 •

edited

ivrntsv commented Jul 4, 2022 •

edited

leonerd commented Jul 4, 2022

iabyn commented Jul 5, 2022 via email

leonerd commented Jul 5, 2022

leonerd commented Jul 8, 2022


		## Motivation

		"Traditional" Perl modules of the era around Perl 5.8 have always used symbolic aliasing into the caller's package to implement their export mechanism. This was the only mechanism available to them at the time, and served well in the era of procedural modules with functions in them. As more code became object-oriented, using packages to implement classes, the problems of making these exports visible as named symbols in the class's namespace became apparent, because each imported function would be visible as a named method on the class, whether it wanted that or not.


		If no sigil is present on the name argument, it is presumed to be of the first kind, and the value must be a `CODE` reference.

		As the only effect this function has is to add new things to the compiletime lexical scope, it shall be an error to call this function during regular runtime, when no code is currently being compiled. It shall also be an error to pass non-reference values, references to unsupported items (e.g. globs), or references whose type does not match the sigil of its name.

RFC0020: A builtin for Lexical Export #20

RFC0020: A builtin for Lexical Export #20

Conversation

leonerd commented Jun 28, 2022

ivrntsv commented Jun 29, 2022 • edited

leonerd commented Jun 29, 2022

haarg commented Jun 29, 2022

ivrntsv commented Jun 29, 2022

rwp0 commented Jun 30, 2022

leonerd commented Jun 30, 2022

rwp0 commented Jun 30, 2022 • edited

Leont Jun 30, 2022

Choose a reason for hiding this comment

Leont Jul 1, 2022

Choose a reason for hiding this comment

haarg Jul 1, 2022

Choose a reason for hiding this comment

leonerd Jul 2, 2022

Choose a reason for hiding this comment

leonerd commented Jul 2, 2022

leonerd commented Jul 2, 2022

leonerd commented Jul 2, 2022

leonerd commented Jul 2, 2022

tonycoz Jul 4, 2022

Choose a reason for hiding this comment

leonerd Jul 4, 2022

Choose a reason for hiding this comment

ivrntsv commented Jul 4, 2022 • edited

leonerd commented Jul 4, 2022

leonerd commented Jul 4, 2022

ivrntsv commented Jul 4, 2022 • edited

ivrntsv commented Jul 4, 2022 • edited

leonerd commented Jul 4, 2022

iabyn commented Jul 5, 2022 via email

leonerd commented Jul 5, 2022

leonerd commented Jul 8, 2022

ivrntsv commented Jun 29, 2022 •

edited

rwp0 commented Jun 30, 2022 •

edited

ivrntsv commented Jul 4, 2022 •

edited

ivrntsv commented Jul 4, 2022 •

edited

ivrntsv commented Jul 4, 2022 •

edited