RFC: Syntax::Construct

[choroba]

The Problem

When you want to use say in your script, you can tell Perl

use v5.10;

I do not like this style, though, because it does not tell me what feature of 5.10 I need to run the script. A slightly better approach is to add a comment:

use v5.10; # say

This is still not much convenient for the author, though: He has to go through several perldeltas to find the first version where the feature appeared. I fined the feature pragma much nicer:

use feature 'say';

Unfortunately, not all new syntactic constructs are introduced through the feature pragma. For example, the defined-or operator (//) cannot be introduced in any other way then

use v5.10; # //

(You can use a higher version, just to confuse the reader more.)

The Solution

I read through the deltas and wrote Syntax::Construct. It allows you to put the following into your script:

use Syntax::Construct qw( // ... );

And similarly for many features I was able to find in the documentation (see the POD section of the pm file for the full list). Comments or pull requests greatly appreciated.

[davido]

One comment I have: // and //= don't require you to say anything at all to use them. You just have to be running Perl 5.10 or later. So if the intent is to now say, "use Syntax::Construct qw( // ); so that someone looking at the script knows they must be using a sufficiently new version of Perl to provide the // operator, that requires that the person looking at the script now do the footwork of figuring out what Perl version started providing that syntax, which seems to sort of go against the spirit of the module. In such a case, it would be much clearer to say, "use v5.10; # Because we like //"

[tye]

Sorry, but 'use v5.10;' really sucks. Did you look at what Syntax::Construct does? It also tells the user what version of Perl they need. I think the error message could be made more obviously clear on this point, though. But the big win is that the error message tells you why you need Perl 5.010.

This is how I'd do such a thing:

BEGIN { eval '1 // 2' or die
    "Perl version $] unsupported (version 5.010 required to get // ope
+rator)\n" }

I'd actually change "use 5.010;" so that it was much more informative, especially in the interesting situations. I'd delay its impact until after the code has failed to compile (or not). So you'd get information like:

Search pattern not terminated at bin/script line 123.
Perhaps because bin/script requires Perl version 5.010 (and this is on
+ly 5.008_008).

# or

Aborting; Perl version 5.010 required (this is only 5.008_008) by bin/
+script.
Yet it compiled without error -- set PERLANYVER to run anyway.

But it is probably even better (in the short term) to have something like Syntax::Construct that can be installed on old versions of Perl to get this improved behavior.

[davido]

I was hoping, as I posted my thoughts, that I hadn't missed the point to the module. It looks like you've discovered where it brings added value. I appreciate that, and can see now where it can be useful.

[BrowserUk]

This will be taken to be harsh. It is not intended to be so.

This smacks of holiday boredomitis.

In me it manifests itself in the form of expending gratuitous amounts of time attempting to perfect 'good enough' solutions.

In you, it appears to take the form of proposing publishable, but pointless, solutions to invented problems.

Anyone encountering a use Syntax::Construct qw[ ... ]; statement will expend far more time looking up that module and working out what it is 'doing for them'; than they would need to expend if it didn't exist.

Anyone relatively new to Perl (< 4 years) will just assume that the facilities are available through the familiar mechanisms.

Anyone one with longer experience will already be familiar with use 5.010; and use feature qw[ ... ];.

The upshot is that your module would create confusion/waste-the-time-of people in both camps and benefit almost noone.

(You alone might benefit.)

[Jenda]

OK, let me see. I'm writing some code, I need to use some feature that I've heard is not available in some old versions. What do I do ... I basically have three options. First, I can investigate, find out what version introduced that thing and use The.Right.Version. How likely is that I do that? Second, I know my version does support that feature so I add use My.Version.Of.Perl. This means that for no good reason I've disallowed people running older Perls than mine using my script/module. This happens all too often! Third, I specify, in the code, that I want to use that feature. And do not have to know when was the feature introduced.

OK, the other side ... I want to use a module/script. Well ... I might be careful and read the code first, but most likely I'll just run it. In case of a module, I'll run the tests. If the author did the first thing, then either it runs or it tells me my perl is too old. If he did the second ... again it either runs or reports my perl is too old. The catch is I've got no chance knowing which of the two it was and whether the script/module really needs version X.Y or whether M.N would suffice, but the script/module author did not bother checking. In a perfect world use 5.14; means the script/module will not function properly in a lower version. In the real world it more often means the author had 5.14 and that's what he tested the code with.

If the author decided to do the third (actually for him even easier than just use His.Version), I get a compile time message telling me that the script/module uses feature X that was introduced in version X.Y. Pointless, huh?

So ... the only case in which this adds complexity is when someone reads the code, instead of attempting to run or compile-time-check it. And what a huge complexity that is! I see the line, I run "perldoc Syntax::Construct", get told that "this module ensures the specified feature is available in your perl and enables it's use. It reports the necessary perl version in case your perl doesn't support that feature. To test whether your perl supports the requested feture run perl -MSyntax::Construct=... -e 1 in your shell/command prompt."

Huge complexity indeed.

Update: s/\bpdoc\b/perldoc/g; # forgot, pdoc is just a local alias

<!-- Node text goes above. Div tags should contain sig only -- >

[Anonymous Monk]

... investigate ...

perlver does the investigation

... Jenda ...

:)

[BrowserUk]

C:\test>pdoc
'pdoc' is not recognized as an internal or external command,
operable program or batch file.

Okay. Two people.

[Anonymous Monk]

The Solution

Hmmm, perlver?

$ perlver funk


   ------------------------------------
 | file | explicit | syntax  | external |
 | ------------------------------------ |
 | funk | ~        | v5.10.0 | n/a      |
 | ------------------------------------ |
 | Minimum explicit version : ~                             |
 | Minimum syntax version   : v5.10.0                       |
 | Minimum version of perl  : v5.10.0                       |
   ------------------------------------


$ cat funk
$funk //= @ARGV;

so enhance perlver to be more verbose/explicit?

[Anonymous Monk]

Yeah, this really ought to be covered by use feature pragma ... you should submit patches :)

I see you have company in this type of thing with ... any::feature, Syntax::Feature::EachOnArray ... great for experimental flushing out how/why the what works before it makes it into feature

Why? lazy rules :)

[choroba]

The feature pragma has one problem - it comes with Perl itself, so it does not inform you about features in higher versions of Perl.

[Anonymous Monk]

The feature pragma has one problem - it comes with Perl itself, so it does not inform you about features in higher versions of Perl.

feature pragma is pure perl, all it does is twiddle $^Hints, so it can be dual-lived , it should be dual lived , so this problem not much of a problem

sure, Syntax::Construct can be like Modern::Perl and other $^Hints-twiddlers ...

but there is a benefit to having CORE modules that already handle this fundamental operation, both documenting and turning on features, actually do both things and do them well, its called feature after all ...

so it doesn't really need to turn on //= but it can document it  use feature qw[ // ]

you see what I'm getting at, right? perlver is great for finding stuff out, feature is great for documenting and turning it on ... one place to look information, same old vocabulary , perldoc feature

if you keep vocabulary small, and not have 11teen different names for the same thing ...

Syntax::... a new top level namespace that doesn't scream this is about core perl language features ...

This is the general idea

[taint]

Not an effort to take anything away from Syntax::Construct.

But it reminded me of Perl::MinimumVersion::Fast

If nothing else, I think the output from yours (Syntax::Construct) is more elegant/informative.

--Chris

[karlgoethebier]

"The Problem"

Sorry bros - but i really don't know where the problem is.

I swear that i will use...

karls-mac-mini:monks karl$ !!
perl -e 'print qq("What the fuck is say good for?"\n);'
"What the fuck is say good for?"

... until the day i die.

Thanx for any advice (if i miss something), Karl

Update: This was is a serious question...

[choroba]

Are you avoiding all the other features or constructs, as //, current_sub, unicode_strings, /r or /p or \K in regexes? If so, the module does not offer anything to you.

[karlgoethebier]

Thank you very much choroba for your explanation.

Sometimes i sink before i type. Didn't i mention this already ;-(

My best regards, Karl

[choroba]

After two weeks of silence on PrePAN, I released it to CPAN.