Better English

[p5pRT]

Migrated from rt.perl.org#1980 (status was 'resolved')

Searchable as RT1980$

[p5pRT]

From rlm@raggy.doubledogmusic.com

There's a great deal of complaining in the English module that you can't
use it unless you can live with a really bad performance hit in all your
regexps. How about an "English​::Good" module? This would basically be
the same thing as the English module, but it wouldn't include the names
MATCH, PREMATCH, and POSTMATCH. English could then import (and
re-export) everything from English​::Good as its own if you absolutely,
positively had to have all the above.

Another approach​: if you need MATCH, PREMATCH, and POSTMASTCH, perhaps
you could invoke a module English​::Bad that would have all these bad
boys in them, and would hammer performance on those unluckies who need
them. In this latter scenario, you would import English, and import
English​::Bad if you used those other variables.

The advantage of the first scheme is it would break no existing scripts;
but then, few people would also receive the benefits unless they RTFM'd.
The advantage of the latter is (I feel, anyway) that most folks don't
really use these variables, so breaking them would help more people
immediately. That is, it's an engineering choice in favor of helping
more people with performance improvements.

Would this work, or am I inhaling something? :-)

Perl Info

Site configuration information for perl 5.00503:

Configured by root at Mon Aug 30 23:08:56 EDT 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=linux, osvers=2.2.5-22smp, archname=i386-linux
    uname='linux porky.devel.redhat.com 2.2.5-22smp #1 smp wed jun 2 09:11:51 edt 1999 i686 unknown '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
    cppflags='-Dbool=char -DHAS_BOOL -I/usr/local/include'
    ccflags ='-Dbool=char -DHAS_BOOL -I/usr/local/include'
    stdchar='char', d_stdstdio=undef, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lc -lposix -lcrypt
    libc=, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00503:
    /usr/home/rlm/src/perls
    /usr/lib/perl5/5.00503/i386-linux
    /usr/lib/perl5/5.00503
    /usr/lib/perl5/site_perl/5.005/i386-linux
    /usr/lib/perl5/site_perl/5.005
    .


Environment for perl 5.00503:
    HOME=/usr/home/rlm
    LANG=en
    LANGUAGE (unset)
    LC_ALL=en_US
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/bin:/bin:/usr/X11R6/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/home/rlm/src/perls:/usr/local/netscape
    PERL5LIB=/usr/home/rlm/src/perls
    PERL_BADLANG (unset)
    SHELL=/bin/bash

[p5pRT]

From [Unknown Contact. See original ticket]

On Jan 11, Rob McMillin said​:

This is a bug report for perl from rlm@​doubledogmusic.com,
generated with the help of perlbug 1.26 running under perl 5.00503.

There's a great deal of complaining in the English module that you can't
use it unless you can live with a really bad performance hit in all your
regexps. How about an "English​::Good" module? This would basically be
the same thing as the English module, but it wouldn't include the names
MATCH, PREMATCH, and POSTMATCH. English could then import (and
re-export) everything from English​::Good as its own if you absolutely,
positively had to have all the above.

The $`, $&, and $' variables have been optimized in a recent version of
Perl, but anyway, I've written a module not unlike your request.

It basically breaks the variables down into the sections they are put in,
in the module itself. Syntax would be​:

  use English​::Good '​:all'; # I'd like The​::New​::English, but hey...

  use English​::Good '​:arg', '​:error', '​:matching';

... and so on.

The module will be available at my web site at some point soon, I guess.

--

  MIDN 4/C PINYAN, USNR, NROTCURPI http​://www.pobox.com/~japhy/
  jeff pinyan​: japhy@​pobox.com perl stuff​: japhy+perl@​pobox.com
  "The Art of Perl" http​://www.pobox.com/~japhy/book/
  CPAN ID​: PINYAN http​://www.perl.com/CPAN/authors/id/P/PI/PINYAN/
  PerlMonth - An Online Perl Magazine http​://www.perlmonth.com/

[p5pRT]

From @samtregar

On Tue, 11 Jan 2000, Rob McMillin wrote​:

regexps. How about an "English​::Good" module? This would basically be

Shouldn't that be English​::Well?

Oh, kill me now.
-sam

[p5pRT]

From [Unknown Contact. See original ticket]

Jeff Pinyan writes​:

On Jan 11, Rob McMillin said​:

This is a bug report for perl from rlm@​doubledogmusic.com,
generated with the help of perlbug 1.26 running under perl 5.00503.

There's a great deal of complaining in the English module that you can't
use it unless you can live with a really bad performance hit in all your
regexps. How about an "English​::Good" module? This would basically be
the same thing as the English module, but it wouldn't include the names
MATCH, PREMATCH, and POSTMATCH. English could then import (and
re-export) everything from English​::Good as its own if you absolutely,
positively had to have all the above.

The $`, $&, and $' variables have been optimized in a recent version of
Perl, but anyway, I've written a module not unlike your request.

My impression is that the patch was withdrawn.

Ilya

[p5pRT]

From @gbarr

There was once a suggestion that use English should be a pragma
(even though it is not all lowercase) to allow the parser to understand
the long names for the variables.

On Tue, Jan 11, 2000 at 04​:38​:35PM -0500, Ilya Zakharevich wrote​:

Jeff Pinyan writes​:

On Jan 11, Rob McMillin said​:

This is a bug report for perl from rlm@​doubledogmusic.com,
generated with the help of perlbug 1.26 running under perl 5.00503.

There's a great deal of complaining in the English module that you can't
use it unless you can live with a really bad performance hit in all your
regexps. How about an "English​::Good" module? This would basically be
the same thing as the English module, but it wouldn't include the names
MATCH, PREMATCH, and POSTMATCH. English could then import (and
re-export) everything from English​::Good as its own if you absolutely,
positively had to have all the above.

The $`, $&, and $' variables have been optimized in a recent version of
Perl, but anyway, I've written a module not unlike your request.

My impression is that the patch was withdrawn.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

From​: Jeff Pinyan [mailto​:jeffp@​crusoe.net]

The $`, $&, and $' variables have been optimized in a recent
version of Perl, but anyway, I've written a module not unlike
your request.

It basically breaks the variables down into the sections they
are put in, in the module itself. Syntax would be​:

Isn't the problem that if Perl even SEES $` and co, it pessimises instantly?
Hence, if your module declares names for these variables, even if they
aren't exported or processed, the user gets the hit.

You need to segregate $`, $& and $' to a separate file, which you only
require if the user requests these variables.

Paul.

[p5pRT]

From @vanstyn

In <714DFA46B9BBD0119CD000805FC1F53BDC39A8@​UKRUX002.rundc.uk.origin-it.com>, "M
oore, Paul" writes​:
:From​: Jeff Pinyan [mailto​:jeffp@​crusoe.net]
:>
:> The $`, $&amp;, and $' variables have been optimized in a recent
:> version of Perl, but anyway, I've written a module not unlike
:> your request.
:>
:> It basically breaks the variables down into the sections they
:> are put in, in the module itself. Syntax would be​:
:
:Isn't the problem that if Perl even SEES $` and co, it pessimises instantly?
:Hence, if your module declares names for these variables, even if they
:aren't exported or processed, the user gets the hit.
:
:You need to segregate $`, $&amp; and $' to a separate file, which you only
:require if the user requests these variables.

eval "" is enough to keep them invisible.

Hugo