develooper Front page | perl.perl5.porters | Postings from December 2018

Re: [perl #133669] Silently ignores commonly-misspelled PERL5OPTSenvironment variable

Thread Previous | Thread Next
From:
H.Merijn Brand
Date:
December 9, 2018 11:03
Subject:
Re: [perl #133669] Silently ignores commonly-misspelled PERL5OPTSenvironment variable
Message ID:
20181209120315.2d98ec07@pc09.procura.nl
On Sun, 9 Dec 2018 05:45:01 -0500, David Mertens
<dcmertens.perl@gmail.com> wrote:

> Merijn,
> 
> They must be using some kind of fuzzy string matching (
> https://en.wikipedia.org/wiki/Edit_distance). I think that fuzzy string
> matching only makes sense for variable and function names, where the
> language is *given* a string (i.e. variable or function name) and is asked
> to look it up. Probing the environment is different. For that, the language
> is giving the string and the environment is asked to look it up.
>
> On the one hand, I think this is a bad idea. Compared to a basic
> environment variable lookup by name, it would be rather costly to get all
> environment variable names and perform fuzzy matching. On the other hand,
> if Perl implemented this *in* *general* for environment variable lookups,
> it could make a whole slew of diagnostics *much* more helpful. For example,
> if my script asks for $ENV{SOME_THING} but I erroneously set SOMETHING,
> Perl's fuzzy matching on %ENV misses could warn about which variable was
> set. Furthermore, given that fuzzy matching would only fire on environment
> lookup misses, the cost of fuzzy matching would be fairly small in the
> grand scheme of things.

IMHO fuzzy lookup should *only* be implemented at compile-time logic,
otherwise the implication would be a noticeable slowdown. The gain of
clear and helping error messages on compile-failing scripts would be a
welcome addition.

Furthermore, %ENV is a tricky one, as you cannot check compile-time
which variables will be set run-time: $ENV{DBI_DSN} can be set from a
config file, maybe even in a BEGIN {} block

> The next natural step would be suggesting variable or function names when
> mis-spellings are found. Another step, suggesting keys when hash
> mis-spellings are found, seems like it would be too far unless we
> introduced new syntax for this behavior (i.e. $foo->{{name}} could die with
> a fuzzy matching suggestion on mis-spellings).

Again, only for compile-time fails, otherwise all mixin-like modules
will fail

I for one do *not* like the exception code for one single misspelling
(like $PERL5OPTS). Either do it for all variables that matter at
startup ($PERL5LIB, $PERLIO, ...) or not at all

> David
> 
> On Fri, Dec 7, 2018 at 2:17 AM H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> 
> > On Thu, 06 Dec 2018 12:28:04 -0800, "James E Keenan via RT" <
> > perlbug-followup@perl.org> wrote:
> >  
> > > On Mon, 19 Nov 2018 17:07:44 GMT, leonerd@leonerd.org.uk wrote:  
>  [...]  
> > >
> > > If you could propose a patch (including a test), that would probably
> > > move discussion forward.  
> >
> > Maybe perl6 people could help/chime in
> >
> > $ perl6 -e'my $perl5opt = "monkey"; say $perl5opts'
> > ===SORRY!=== Error while compiling -e
> > Variable '$perl5opts' is not declared. Did you mean '$perl5opt'?
> > at -e:1  
> > ------> my $perl5opt = "monkey"; say ⏏$perl5opts  
> >
> > So they already have the feature to do it for variables, why not
> > steal/borrow their logic for our environmental variables
> >
> > And that could trigger someone else to do it for variables in perl5
> > too :)

-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.29   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About