Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better English #1029

Closed
p5pRT opened this issue Jan 11, 2000 · 7 comments
Closed

Better English #1029

p5pRT opened this issue Jan 11, 2000 · 7 comments

Comments

@p5pRT
Copy link

p5pRT commented Jan 11, 2000

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

Searchable as RT1980$

@p5pRT
Copy link
Author

p5pRT commented Jan 11, 2000

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
Copy link
Author

p5pRT commented Jan 11, 2000

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
Copy link
Author

p5pRT commented Jan 11, 2000

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
Copy link
Author

p5pRT commented Jan 11, 2000

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
Copy link
Author

p5pRT commented Jan 12, 2000

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
Copy link
Author

p5pRT commented Jan 12, 2000

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
Copy link
Author

p5pRT commented Jan 12, 2000

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant