Re^2: Perl syntax checking without `perl -c` (bareword)

> "Can't use bareword ("syntactic_sugar") ...".

Well yeah, I guess if those modules are supposed to export functions ° and you call them without parens this might produce bareword errors (and many others).

So declaring a sub syntactic_sugar is already also changing syntax, because it allows to call them as barewords.

Hence you'll need to fake-export them too. ;)

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery}

UPDATE

°) or constants, which are actually implemented as functions.

Here the diagnostics https://perldoc.perl.org/perldiag#Can't-use-bareword-(%22%25s%22)-as-%25s-ref-while-%22strict-refs%22-in-use

Comment on Re^2: Perl syntax checking without `perl -c` (bareword) Download Code

Replies are listed 'Best First'.
Re^3: Perl syntax checking without `perl -c` (bareword) by kcott (Archbishop) on Dec 04, 2020 at 23:20 UTC
"Hence you'll need to fake-export them too. ;)" Yes, I was aware of that and even considered doing it. The main criteria, when thinking about doing that, were: how long that would take; how long disaster recovery would take; and, what useful coding I would not be doing while doing this instead. I tend not to make too many mistakes. Mostly they involve keyboard errors: not pressing or releasing the shift key fast enough; hitting an adjacent key by mistake; and the like. E.g. `my @x = qw{a b c}: # slow release of shift: got ':' instead of ';' my $y - $x[2]; # hit adjacent key: got '-' instead of '='` [download] Thankfully these are pretty rare and easily fixed. Other types of errors, such as logic errors, are not syntax errors and are only found when testing. — Ken	[reply] [d/l]
Re^4: Perl syntax checking without `perl -c` (bareword) by LanX (Saint) on Dec 05, 2020 at 01:48 UTC
> how long that would take; how long disaster recovery would take; and, what useful coding I would not be doing while doing this instead. yeah, that's what I meant initially, how much does one want to invest for a temporary 90% solution. But this thread has also become an intellectual challenge and it's still possible to have a better solution. So for completeness: The dynamic %INC hook shown here could be extended to provide an import routine which exports all symbols requested. This won't cover subs with special prototypes or subs which are exported by defaults though, but will get you closer to your "unreasonable" goal. ;-) Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^5: Perl syntax checking without `perl -c` [perl lint] by kcott (Archbishop) on Dec 06, 2020 at 02:55 UTC
"So for completeness: ..." The following is somewhat negative information, but perhaps useful to know for someone coming to this thread in the future. I had previously done an internet search for "perl lint". I came across these two modules: B::Lint In its raw form (i.e. `perl -MO=Lint file_with_perl_code`) this seemed to act pretty much identically to `perl -c file_with_perl_code`. It does have a number of options but none turn off executing code. Perl::Lint I think this falls into the category of abandonware: not touched in over four years; about 95% of testers failed to install the module; dead link to TPF grant proposal. I did manage to force-install it; however, running it with my $work code produced errors (related to Perl::Lint code). I created a very simple `bad.pl` (with the typos I indicated above) purely as a test: although its SYNOPSIS shows running it on a `bar.pl` file, it complained about no `package` declaration; not ending with `1;`; and other things which suggest the code only works on modules, not scripts. — Ken	[reply] [d/l] [select]