use does not work as documented with respect to CHECK and INIT

[p5pRT]

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

Searchable as RT22826$

[p5pRT]

From pcg@goof.com

Created by root@cerebro.laendle

perldoc -f use says​:

  [use] is exactly equivalent to

  BEGIN { require Module; import Module LIST; }

  except that Module must be a bareword.

However\, I found that neither CHECK nor INIT blocks are executed when require is used to load a module\, i.e.​:

  use XYZ;   # CHECK and INIT get run

  require XYZ;   # CHECK and INIT blocks _never_ run\, not even at program end.

So it seems that require keeps CHECK and INIT from running at all.

I hope this isn't just a bug in my 5.8.x snapshot ;)

Perl Info

``` Flags: category=core severity=medium Site configuration information for perl v5.8.1: Configured by root at Tue May 6 03:54:06 CEST 2003. Summary of my perl5 (revision 5.0 version 8 subversion 1 patch 19408) configuration: Platform: osname=linux, osvers=2.4, archname=i686-linux uname='linux cerebro 2.4.18-pre8-ac3 #2 smp tue feb 5 17:35:23 cet 2002 i686 unknown ' config_args='' hint=previous, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='gcc', ccflags ='-I/opt/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-Os -funroll-loops -mcpu=pentium -march=pentium -g', cppflags='-I/opt/include -D_GNU_SOURCE -I/opt/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/opt/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/opt/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ccversion='', gccversion='3.2.3 20030415 (Debian prerelease)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags ='' libpth=/usr/lib /opt/lib libs=-lcrypt -ldl -lm -lc perllibs=-lcrypt -ldl -lm -lc libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared' Locally applied patches: MAINT19332 @INC for perl v5.8.1: /root/src/sex /opt/perl/lib/perl5 /opt/perl/lib/perl5 /opt/perl/lib/perl5 /opt/perl/lib/perl5 . Environment for perl v5.8.1: HOME=/root LANG (unset) LANGUAGE (unset) LC_CTYPE=de_DE@euro LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/root/s2:/root/s:/opt/qt/bin:/opt/bin:/opt/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11/bin:/usr/games:/usr/local/bin:/usr/local/sbin:.:/root/cc/dejagnu/bin PERL5LIB=/root/src/sex PERL5_CPANPLUS_CONFIG=/root/.cpanplus/config PERLDB_OPTS=ornaments=0 PERL_BADLANG (unset) SHELL=/bin/bash ```

[p5pRT]

From pcg@goof.com

On Fri\, Jun 27\, 2003 at 01​:04​:22AM -0000\, perlbug-followup@​perl.org wrote​:

use XYZ; # CHECK and INIT get run

require XYZ; # CHECK and INIT blocks _never_ run\, not even at program end.

So it seems that require keeps CHECK and INIT from running at all.

Correction​: If I use BEGIN around the require\, they indeed get run​:

  perl -e 'BEGIN { require Board }'   perl -e 'BEGIN { require "kgsueme/board.pl" }'

However\, my program driver was loading the main program using a require​:

  require "otherfile";

and when otherfile did the require on Board.pm\, the CHECK and INIT callbacks never got run\, not even after leaving the code executed in require.

--   -----==- |   ----==-- _ |   ---==---(_)__ __ ____ __ Marc Lehmann +--   --==---/ / _ \/ // /\ \/ / pcg@​goof.com |e|   -=====/_/_//_/\_\,_/ /_/\_\ XX11-RIPE --+   The choice of a GNU generation |   |

[p5pRT]

From @rgs

Marc Lehmann perlbugged​:

perldoc -f use says​:

[use] is exactly equivalent to

   BEGIN \{ require Module; import Module LIST; \}

except that Module must be a bareword.

However\, I found that neither CHECK nor INIT blocks are executed when require is used to load a module\, i.e.​:

use XYZ; # CHECK and INIT get run

require XYZ; # CHECK and INIT blocks _never_ run\, not even at program end.

So it seems that require keeps CHECK and INIT from running at all.

Not in a BEGIN block. Execution of CHECK and INIT depend on the transition between compile-time and run-time.

  $ cat x   BEGIN { print "BEGIN\n"; }   CHECK { print "CHECK\n"; }   INIT { print "INIT\n"; }   END { print "END\n"; }   1;   $ perl -e 'require "x"'   BEGIN   END   $ perl -e 'BEGIN{require "x"}'   BEGIN   CHECK   INIT   END

See also perlmod :

  Similar to C\ blocks\, C\ blocks are run just after the   Perl compile phase ends and before the run time begins\, in   LIFO order. C\ blocks are again useful in the Perl compiler   suite to save the compiled state of the program.

But require() happens at runtime\, _after_ CHECK blocks being run. A similar explanation can be given for INIT. So it's not a bug. IMO.

[p5pRT]

From perl5-porters@ton.iguana.be

In article \20030627092205\.2e0498a0\.rgarciasuarez@​\_ree\.\_r\,   Rafael Garcia-Suarez \rgarciasuarez@​free\.fr writes​:

See also perlmod :

Similar to C\<END> blocks\, C\<CHECK> blocks are run just after the
Perl compile phase ends and before the run time begins\, in
LIFO order\.  C\<CHECK> blocks are again useful in the Perl compiler
suite to save the compiled state of the program\.

But require() happens at runtime\, _after_ CHECK blocks being run. A similar explanation can be given for INIT. So it's not a bug. IMO.

I've always seen compile/runtime in perl as a recursive concept\, so a "require" starts it's own new localized compile/runtime. From that point of view\, they SHOULD run.

If the runtime wants something prepared in the CHECK block\, it makes more sense to have it run even under "require". The recursive compile/run model makes it also easier to understand that the require body still gets compiled and when when BEGIN's get run.

[p5pRT]

From @rgs

Ton Hospel wrote​:

In article \20030627092205\.2e0498a0\.rgarciasuarez@​\_ree\.\_r\, Rafael Garcia-Suarez \rgarciasuarez@​free\.fr writes​:

See also perlmod :

Similar to C\<END> blocks\, C\<CHECK> blocks are run just after the
Perl compile phase ends and before the run time begins\, in
LIFO order\.  C\<CHECK> blocks are again useful in the Perl compiler
suite to save the compiled state of the program\.

But require() happens at runtime\, _after_ CHECK blocks being run. A similar explanation can be given for INIT. So it's not a bug. IMO.

I've always seen compile/runtime in perl as a recursive concept\,

I've never seen compile/runtime in perl as a recursive concept ;-) even if some blocks (BEGIN blocks) are executed as soon as possible\, ie when they've been just compiled.

so a "require" starts it's own new localized compile/runtime. From that point of view\, they SHOULD run.

Basically what you want is that

  eval qq{CHECK{print "CHECK\n"}};   eval qq{INIT{print "INIT\n"}};

be executed at runtime. That's a huge semantic change and I don't see a pressing reason for it.

[p5pRT]

From pcg@goof.com

On Fri\, Jun 27\, 2003 at 08​:48​:39AM -0000\, Rafael Garcia-Suarez \perlbug\-followup@​perl\.org wrote​:

so a "require" starts it's own new localized compile/runtime. From that point of view\, they SHOULD run.

Basically what you want is that

eval qq\{CHECK\{print "CHECK\\n"\}\};
eval qq\{INIT\{print "INIT\\n"\}\};

be executed at runtime. That's a huge semantic change and I don't see a pressing reason for it.

I don't want that (I don't use eval\, just a recursive require). Basically\, when I have a module​:

  body;   INIT { init };

then I want that init is run before body\, as is documented and normally happens. The problem is that this only works when one level of require is used. Wen two levels are used the body is run and the require returns but INIT and CHECK are skipped and *never* executed.

If this is actually intended behaviour it should be documented\, as module authors rely on CHECK and INIT to be run\, regardless of wether their caller was itself executed in a require.

At the very least it should be documented that CHECK and INIT sometimes are simply ignored\, as module authors then may no longer rely on them.

--   -----==- |   ----==-- _ |   ---==---(_)__ __ ____ __ Marc Lehmann +--   --==---/ / _ \/ // /\ \/ / pcg@​goof.com |e|   -=====/_/_//_/\_\,_/ /_/\_\ XX11-RIPE --+   The choice of a GNU generation |   |

[p5pRT]

From @rgs

pcg@​goof.com ( Marc) (A.) (Lehmann ) wrote​:

Basically what you want is that

eval qq\{CHECK\{print "CHECK\\n"\}\};
eval qq\{INIT\{print "INIT\\n"\}\};

be executed at runtime. That's a huge semantic change and I don't see a pressing reason for it.

I don't want that (I don't use eval\, just a recursive require).

Both are about code pulled in at run-time. do("file") is another form of this operation.

Basically\, when I have a module​:

body; INIT { init };

then I want that init is run before body\, as is documented and normally happens.

Where is it documented ? perlmod says\, at the contrary :

  Similar to C\ blocks\, C\ blocks are run just before the   Perl runtime begins execution\, in "first in\, first out" (FIFO) order.

This implies that\, when perl _has_ begin execution\, there is no reason it should run INIT (or CHECK) blocks anymore.

The problem is that this only works when one level of require is used. Wen two levels are used the body is run and the require returns but INIT and CHECK are skipped and *never* executed.

That's not a "require" versus "use" issue\, or a double require issue : that's a compile time versus run time issue.

If this is actually intended behaviour it should be documented\, as module authors rely on CHECK and INIT to be run\, regardless of wether their caller was itself executed in a require.

Doc patches are welcome ;-)

You're probably confused because you've associated "BEGIN blocks" to "compile-time". That's not true. Quoting perlmod again :

  A C\ subroutine is executed as soon as possible\, that is\, the   moment it is completely defined\, even before the rest of the   containing file is parsed.

There's no mention of compile time or run time here (unlike the definitions for CHECK and INIT.) BEGIN blocks that are defined at runtime are executed at runtime.

The docs can probably be improved\, because you're probably not the only one that could be confused by this. As usual\, I'm thinking like somebody who knows perl's internals. You and Ton adopt the safer standpoint of the Perl programmer.

At the very least it should be documented that CHECK and INIT sometimes are simply ignored\, as module authors then may no longer rely on them.

IIRC\, the behaviour of CHECK and INIT blocks haven't changed since they were introduced.

[p5pRT]

From @rgs

I said :

Basically what you want is that

eval qq\{CHECK\{print "CHECK\\n"\}\};
eval qq\{INIT\{print "INIT\\n"\}\};

be executed at runtime. That's a huge semantic change and I don't see a pressing reason for it.

DUH. I should have tried with warnings :

  $ perl -wle 'eval q/CHECK{}INIT{}/'   Too late to run CHECK block at (eval 1) line 1.   Too late to run INIT block at (eval 1) line 1.

(same warnings produced with require. This confirms what I was saying.)

Doc patches are welcome ;-)

Do you like this one ? :

--- pod/perlmod.pod (revision 1484) +++ pod/perlmod.pod (working copy) @​@​ -283\,15 +283\,17 @​@​ value of the program. Beware of changing C\<$?> by accident (e.g. by running something via C\).

-Similar to C\ blocks\, C\ blocks are run just before the -Perl runtime begins execution\, in "first in\, first out" (FIFO) order. -For example\, the code generators documented in L\ make use of -C\ blocks to initialize and resolve pointers to XSUBs. +C\ and C\ blocks are useful to catch the transition between +the compilation phase and the execution phase of perl.

-Similar to C\ blocks\, C\ blocks are run just after the -Perl compile phase ends and before the run time begins\, in -LIFO order. C\ blocks are again useful in the Perl compiler -suite to save the compiled state of the program. +C\ blocks are run just after the Perl compile phase ends and before +the run time begins\, in LIFO order. C\ blocks are again useful in +the Perl compiler suite to save the compiled state of the program. + +C\ blocks are run just before the Perl runtime begins execution\, in +"first in\, first out" (FIFO) order. For example\, the code generators +documented in L\ make use of C\ blocks to initialize and +resolve pointers to XSUBs.

When you use the B\<-n> and B\<-p> switches to Perl\, C\ and C\ work just as they do in B\\, as a degenerate case. Check\,End ;-)

[p5pRT]

From pcg@goof.com

On Fri\, Jun 27\, 2003 at 02​:46​:39PM +0200\, Rafael Garcia-Suarez \rgarciasuarez@&#8203;free\.fr wrote​:

Basically\, when I have a module​:

body; INIT { init };

then I want that init is run before body\, as is documented and normally happens.

Where is it documented ? perlmod says\, at the contrary :

Similar to C\<BEGIN> blocks\, C\<INIT> blocks are run just before the
Perl runtime begins execution\, in "first in\, first out" \(FIFO\) order\.

This implies that\, when perl _has_ begin execution\, there is no reason it should run INIT (or CHECK) blocks anymore.

So that means only the very first module to be use'd will have it's init and check functions run since the body of a module is "run" long before it's caller? That makes a lot of less sense than my interpretation\, I think.

Also\, you said earlier that it would work in BEGIN blocks\, which isn't true\, either. IT *sometimes* happens when used in BEGIN blocks\, and at other times not\, and there is no way to find out about that.

I now understand that there is some point in time where these blocks are run\, and the time before is called compiletime (despite a lot of code is executed outside BEGIN blocks)\, and the phase after that point is callwed runtime\, despite the fact there some of the code is executed inside BEGIN blocks.

My basic point is that perl begins execution of code long before your proposed "runtime" begins\, however\, there is no definition of runtime anywhere\, except that code inside BEGIN is executed at parsing time (which according to you is *after* compiletime\, which simply makes no sense to me).

Ok\, I admit I didn't know all that subtle differences between compiletime and the time at which my code is compiled\, but is there any non-fuzzy definition of when this point happens? A definition that works? I don't see why the semantics of my code needs to change so drastically when my program is executed from another one by "do"'ing it\, for example.

And the problem for me is that my code doesn't work when run that way\, which means that all my Gtk2-widgets don't work under these circumstances that I cnanot even foresee. So... do you know of a workaround? Gtk2 needs to fix packages after they are compiled so they work as GObjectClasses\, and when these programs are executed fro other programs they fail with mysterious error messages.

Also\, I think the fact that INIT blocks sometimes are skipped and this is outside the scope of a module writer makes them very unreliable to use.

Doc patches are welcome ;-)

Yes\, as always ;)

You're probably confused because you've associated "BEGIN blocks" to "compile-time". That's not true. Quoting perlmod again :

A C\<BEGIN> subroutine is executed as soon as possible\, that is\, the
moment it is completely defined\, even before the rest of the
containing file is parsed\.

There's no mention of compile time or run time here (unlike the definitions for CHECK and INIT.) BEGIN blocks that are defined at runtime are executed at runtime.

Yes\, and perl code is parsed and the compiled\, but that's also not called compiletime.

Frankly\, I think the use of compile-time to mean some unspecified part of a program run is not practical\, and at the moment I couldn't give any sensible definition of that time that makes sense to me. IT looks completely arbitrary.

The docs can probably be improved\, because you're probably not the only one that could be confused by this. As usual\, I'm thinking like somebody who knows perl's internals. You and Ton adopt the safer standpoint of the Perl programmer.

Well\, even if the docs could be improved I wonder abouit wether this behaviour makes sense. As a programmer\, I want determinism\, and as a module author\, INIT and CHECK are pretty unreliable to use\, since they are sometimes quietly ignored.

Would te semantic change you were talking about (== "making them run for me") really that much of a problem? I mean\, if the semantic change actually makes them work as expected on the perl level\, why is that bad?

If it's "just" :) the work\, then I offer to make a try at a patch to do that (maybe with a little help?).

At the very least it should be documented that CHECK and INIT sometimes are simply ignored\, as module authors then may no longer rely on them.

IIRC\, the behaviour of CHECK and INIT blocks haven't changed since they were introduced.

So....? Almost nobody uses them...

--   -----==- |   ----==-- _ |   ---==---(_)__ __ ____ __ Marc Lehmann +--   --==---/ / _ \/ // /\ \/ / pcg@​goof.com |e|   -=====/_/_//_/\_\,_/ /_/\_\ XX11-RIPE --+   The choice of a GNU generation |   |

[p5pRT]

From pcg@goof.com

On Fri\, Jun 27\, 2003 at 03​:10​:58PM +0200\, Rafael Garcia-Suarez \rgarciasuarez@&#8203;free\.fr wrote​:

Doc patches are welcome ;-)

Do you like this one ? :

As a matter of fatc\, I always like patches\, of course\, but I don't see what the patch below does\, since there are a lot of compile and execution phases during the course of a perl program execution.

So the documentation is just confusing because it talks about "the" compilephase\, but the programmer can never know which one is meant\, and why there is only one of them even if the programmer sees a lot of them.

As it stands now\, the INIT and CHECK functions sound more like a hack\, since that's the only perl feature that behaves completely different depending on something completely outside of a module author's scope.

What I mean is that a feature that sometimes gets run and sometimes not depending on an action taken completely outside even the whole perl program (it could be run from another program using do) sounds pretty unreliable.

Or\, put differently​: the point at which *the* compilephase ends and *the* runtime starts is completely arbitrary and not really detectable on the perl level. The exactly *same* sourcecode can have them executed at arbitrary times\, or not at all. To me that simply sounds like a bad feature that could be improved.

As I take it now\, INIT and CHECK are only meant to serialize/deserialize non-perl data. If they were documented as such it would IMHO be better\, since a normal perl module has no use for it since they are sometimes skipped.

So.. thanks for clearing up the confusion in my mind and educating me about the real semantics.

Do you have any idea how I can make some code run after a module of mine is use'd but before the use'ing module starts execution? Source filters could probably do what I want by appending a BEGIN block... hmm... Or maybe you have a better idea?

Thanks a lot for the discussion!

--   -----==- |   ----==-- _ |   ---==---(_)__ __ ____ __ Marc Lehmann +--   --==---/ / _ \/ // /\ \/ / pcg@​goof.com |e|   -=====/_/_//_/\_\,_/ /_/\_\ XX11-RIPE --+   The choice of a GNU generation |   |

[p5pRT]

From @rgs

pcg@​goof.com ( Marc) (A.) (Lehmann ) wrote​:

As a matter of fatc\, I always like patches\, of course\, but I don't see what the patch below does\, since there are a lot of compile and execution phases during the course of a perl program execution.

So the documentation is just confusing because it talks about "the" compilephase\, but the programmer can never know which one is meant\, and why there is only one of them even if the programmer sees a lot of them.

Perhaps should it be more precise : the compile / run time phase of the main program

Or\, put differently​: the point at which *the* compilephase ends and *the* runtime starts is completely arbitrary and not really detectable on the perl level.

Except by testing the definedness of $^S. (But this doesn't work from inside CHECK/INIT blocks.)

As I take it now\, INIT and CHECK are only meant to serialize/deserialize non-perl data. If they were documented as such it would IMHO be better\, since a normal perl module has no use for it since they are sometimes skipped.

INIT/CHECK and their current semantics are used by the perl compiler. Most notably\, modifying the current semantics of CHECK would break the central O module\, and thus the whole compiler suite.

Do you have any idea how I can make some code run after a module of mine is use'd but before the use'ing module starts execution? Source filters could probably do what I want by appending a BEGIN block... hmm... Or maybe you have a better idea?

What do you mean ? From the module or from the calling program ? Can't you do this by simply putting code at the end of the use'd module ?

[p5pRT]

From @gsar

On Fri\, 27 Jun 2003 10​:42​:16 +0200\, Rafael Garcia-Suarez wrote​:

Basically what you want is that

eval qq{CHECK{print "CHECK\n"}}; eval qq{INIT{print "INIT\n"}};

be executed at runtime. That's a huge semantic change and I don't see a pressing reason for it.

I think Larry wished for them to be tracked and run per-optree rather than only for the main optree\, but I never got around to adding that in. The archives may yield more insight.

Sarathy gsar@​ActiveState.com

[p5pRT]

From @rgs

Gurusamy Sarathy wrote​:

On Fri\, 27 Jun 2003 10​:42​:16 +0200\, Rafael Garcia-Suarez wrote​:

Basically what you want is that

eval qq{CHECK{print "CHECK\n"}}; eval qq{INIT{print "INIT\n"}};

be executed at runtime. That's a huge semantic change and I don't see a pressing reason for it.

I think Larry wished for them to be tracked and run per-optree rather than only for the main optree\, but I never got around to adding that in. The archives may yield more insight.

And now time has passed\, and Perl 6 defines new special blocks. As usual\, I prefer divergence to be avoided.

(As I pointed out somewhere else\, modifying CHECK to be run after its enclosing file compilation will break the O module\, since   perl -MO=Foo foo.pl should run O's CHECK block _after_ foo.pl is compiled.)

[p5pRT]

From pcg@goof.com

On Fri\, Jun 27\, 2003 at 04​:11​:48PM +0200\, Rafael Garcia-Suarez \rgarciasuarez@&#8203;free\.fr wrote​:

INIT/CHECK and their current semantics are used by the perl compiler.

I gave this a bit of thought\, too. It seems that they are *only* useful with regards to the perl compiler\, is this true? I'd think documenting them as such would be the most sensible thing indeed\, as they sound like a great thing in general\, but are only useful for the very specific problem of serializing/deserializing data structures for the perl compiler (and as such\, sound pretty much compiler-specific).

The next quetsion would be why theese blocks run at all\, since under normal circumstances running them will incur an unnecessary performance degradation\, as modules will unnecessarily prepare for being compiled and restored later\, which is completely unnecessary.

It sounds to me as if CHECK and INIT were designed for two different things​: the documented usage (which is confusing to me)\, and the compiler.

I wonder if there is any valid use for them outside of the compiler\, and\, if not\, maybe they should be ignored unless the program gets compiled?

is use'd but before the use'ing module starts execution? Source filters could probably do what I want by appending a BEGIN block... hmm... Or maybe you have a better idea?

What do you mean ? From the module or from the calling program ?

From the module. The module needs to modify the calling "class" so that it complies with the requirenment of a GObjectClass\, basically some added functions (not methods\, unfortunately).

And I wanted to avoud having to put the "use Glib​::Object​::Subclass" meaning "I am a subclass of" at the end of the module\, or using "use .." and a seperate "register sth." call.

Can't you do this by simply putting code at the end of the use'd module ?

Yes\, but that's not simple to do\, except using a source filter\, which isn't simple (for me\, especially as it adds dependencies\, or incurs xs trickery)\, but it seems the only practical way to do it.

--   -----==- |   ----==-- _ |   ---==---(_)__ __ ____ __ Marc Lehmann +--   --==---/ / _ \/ // /\ \/ / pcg@​goof.com |e|   -=====/_/_//_/\_\,_/ /_/\_\ XX11-RIPE --+   The choice of a GNU generation |   |

[p5pRT]

From pcg@goof.com

On Fri\, Jun 27\, 2003 at 03​:15​:30PM -0000\, Rafael Garcia-Suarez \perlbug\-followup@&#8203;perl\.org wrote​:

I think Larry wished for them to be tracked and run per-optree

I guess larry "thought perl".

(As I pointed out somewhere else\, modifying CHECK to be run after its enclosing file compilation will break the O module\, since

So it semes the only *option* would be to leave them as they are\, as special support for the compiler.

And if we wanted INIT/CHECK on a per optree basis we would probably need to define new special blocks for this new and semantically different purpose.

(Do we really want to waste these nice short names for the very rarely used compiler? ;) Ok\, I understand it cannot be changed easily anymore :)

--   -----==- |   ----==-- _ |   ---==---(_)__ __ ____ __ Marc Lehmann +--   --==---/ / _ \/ // /\ \/ / pcg@​goof.com |e|   -=====/_/_//_/\_\,_/ /_/\_\ XX11-RIPE --+   The choice of a GNU generation |   |

[p5pRT]

From @rgs

pcg( Marc)@​goof(A.).(Lehmann )com wrote​:

On Fri\, Jun 27\, 2003 at 04​:11​:48PM +0200\, Rafael Garcia-Suarez \rgarciasuarez@&#8203;free\.fr wrote​:

INIT/CHECK and their current semantics are used by the perl compiler.

I gave this a bit of thought\, too. It seems that they are *only* useful with regards to the perl compiler\, is this true? I'd think documenting them as such would be the most sensible thing indeed\, as they sound like a great thing in general\, but are only useful for the very specific problem of serializing/deserializing data structures for the perl compiler (and as such\, sound pretty much compiler-specific).

The next quetsion would be why theese blocks run at all\, since under normal circumstances running them will incur an unnecessary performance degradation\, as modules will unnecessarily prepare for being compiled and restored later\, which is completely unnecessary.

You are now confusing me. Serialization/deserialization ? Performance degradation ?

It sounds to me as if CHECK and INIT were designed for two different things​: the documented usage (which is confusing to me)\, and the compiler.

Those are hooks\, used by various modules of the compiler suite\, and historically introduced for it.

Here's how it works :   perl -MO=Backend foo.pl 1. uses the O module\, calls O->import 2. O turns on the internal equivalent of the -c command-line switch   ("exit interpreter when compilation phase has ended") (in a BEGIN   block) 3. O defines on the fly a CHECK block that loads the specified B​::Backend   module\, and calls the compile() function of it. 4. B​::Backend​::compile() is then called after compilation has finished\,   and can introspect the internal state of perl through the API defined   by the B module.

I wonder if there is any valid use for them outside of the compiler\, and\, if not\, maybe they should be ignored unless the program gets compiled?

I bet some modules on CPAN use them. Look in the Acme​::* namespace\, for example.

Every self-verification that needs to be run after the program has finished loading\, but before it's executed\, is a job for CHECK or INIT blocks.

\<http​://perl.apache.org/docs/1.0/guide/porting.html#CHECK_And_INIT_Blocks>

is use'd but before the use'ing module starts execution? Source filters could probably do what I want by appending a BEGIN block... hmm... Or maybe you have a better idea?

What do you mean ? From the module or from the calling program ?

From the module. The module needs to modify the calling "class" so that it complies with the requirenment of a GObjectClass\, basically some added functions (not methods\, unfortunately).

IIUC : Your module Foo should add some functions in every module X that uses it. Sounds like a job for a custom import() method.

And I wanted to avoud having to put the "use Glib​::Object​::Subclass" meaning "I am a subclass of" at the end of the module\, or using "use .." and a seperate "register sth." call.

Can't you do this by simply putting code at the end of the use'd module ?

Yes\, but that's not simple to do\, except using a source filter\, which isn't simple (for me\, especially as it adds dependencies\, or incurs xs trickery)\, but it seems the only practical way to do it.

or eval("") ?

[p5pRT]

From @nwc10

On Fri\, Jun 27\, 2003 at 04​:11​:48PM +0200\, Rafael Garcia-Suarez wrote​:

INIT/CHECK and their current semantics are used by the perl compiler. Most notably\, modifying the current semantics of CHECK would break the central O module\, and thus the whole compiler suite.

I'm not convinced that this in itself is really a valid argument. The O module ships with the perl interpreter\, to date it has never had a separate life on CPAN\, and given that it poking deeply in the guts of perl I doubt it ever will. Hence changes to the interpreter that break the compiler can be accompanied by changes to the compiler that fix the compiler.

This doesn't affect any of the rest of anyone's reasoning\, and despite reading the rest of the thread now\, I still don't have an opinion on what should be done. (Oh\, apart from "nothing" not being an option - at a minimum better documentation of what we have)

Nicholas Clark

[p5pRT]

From pcg@goof.com

On Sat\, Jun 28\, 2003 at 11​:47​:13AM +0200\, Rafael Garcia-Suarez \rgarciasuarez@&#8203;free\.fr wrote​:

You are now confusing me. Serialization/deserialization ? Performance degradation ?

INIT and CHECK serve no purpose except when compiling\, it seems (I can't imagine a use for them in their current incarnation\, maybe you have a convincing example\, though\, but I doubt it\, since a module author can't even depend on them being executed).

As such\, executing them without compiling is just unnecessary extra work\, and given that they are used to serialize/deserialize XS data so the compiler can see them\, this looks like it's only costing performance in the common case *if* modules are using INIT/CHECK at all.

Here's how it works :

Yupp.. so if they are created just to suit the (important) requirements of the compiler modules\, why are they run on normal execution? This would only make since if they are useful outside the scope of compiling a program (And I am unsure although not totally convinced that they aren't useful outside that).

I wonder if there is any valid use for them outside of the compiler\, and\, if not\, maybe they should be ignored unless the program gets compiled?

I bet some modules on CPAN use them. Look in the Acme​::* namespace\, for example.

The Acme​::* namespace surely contains a lot of modules that are pratically useful.... Frankly\, these are fun modules exploiting various aspects of the perl interpreter and get broken every other release.

\<http​://perl.apache.org/docs/1.0/guide/porting.html#CHECK_And_INIT_Blocks>

This document claims that CHECK and INIT blocks don't work in apache. As such\, they are not useful within apache and every module using it will not have them run.

This is just another data point that shows that people expect them to "work" (I mean\, the author of that document is just as confused as I was\, as he is expecting them to "work"\, but thinks they don't\, because the definition of run-time and compile-time in perl is totally difefrent formt he definition these blocks use). As a matter of fact\, the above document is wrong as the blocks indeed "work"\, as such it needs updating.

And that's from the mod_perl porting FAQ!

From the module. The module needs to modify the calling "class" so that it complies with the requirenment of a GObjectClass\, basically some added functions (not methods\, unfortunately).

IIUC : Your module Foo should add some functions in every module X that

Adding some fucntioons won't make them run magically after the module has been parsed\, though\, or is there a trick\, a replacement for CHECK that happens to be executed then?

uses it. Sounds like a job for a custom import() method.

How would one do that? The import method is called at the point of the use\, and I'd _really_ like to avoid having to tell people that they ahve to put the "use" statement at the _bottom_ of their class definitions.

Yes\, but that's not simple to do\, except using a source filter\, which isn't simple (for me\, especially as it adds dependencies\, or incurs xs trickery)\, but it seems the only practical way to do it.

or eval("") ?

How would I do this with eval("")? The difficult question is how to get the "" part of the eval\, since perl hasn't even parsed it yet. That's why I meant a source filter does work.

You see\, the problem indeed is difficult ;->

--   -----==- |   ----==-- _ |   ---==---(_)__ __ ____ __ Marc Lehmann +--   --==---/ / _ \/ // /\ \/ / pcg@​goof.com |e|   -=====/_/_//_/\_\,_/ /_/\_\ XX11-RIPE --+   The choice of a GNU generation |   |

[p5pRT]

From @rgs

pcg( Marc)@​goof(A.).(Lehmann )com wrote​:

\<http​://perl.apache.org/docs/1.0/guide/porting.html#CHECK_And_INIT_Blocks>

This document claims that CHECK and INIT blocks don't work in apache. As such\, they are not useful within apache and every module using it will not have them run.

They work very well with apache ; they don't work with the Apache​::Registry framework\, often used to port CGI scripts. That's a point of incompatibility between CGI scripts and Apache​::Registry scripts. And that's exactly the same problem than the one you originally reported. Hence my pointing to this document.

This is just another data point that shows that people expect them to "work" (I mean\, the author of that document is just as confused as I was\, as he is expecting them to "work"\, but thinks they don't\, because the definition of run-time and compile-time in perl is totally difefrent formt he definition these blocks use). As a matter of fact\, the above document is wrong as the blocks indeed "work"\, as such it needs updating.

Patches welcome. Although I think you're assuming a bit too much about the original intent of the author of this part of this document. I happen to know this person very well ; his forename begins with "Rafa".

OK for the moment I'm inclined to apply my proposed doc patch until someone with higher powers settles. I haven't found anything in the Apocalypses about CHECK blocks ; the only reference I got is this unhelpful post from Larry :   http​://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=20030415181942.GA11245%40wall.org

[p5pRT]

From @pjcj

On Sat\, Jun 28\, 2003 at 06​:27​:21PM +0200\, Marc A. Lehmann wrote​:

INIT and CHECK serve no purpose except when compiling\, it seems (I can't imagine a use for them in their current incarnation\, maybe you have a convincing example\, though\, but I doubt it\, since a module author can't even depend on them being executed).

Yupp.. so if they are created just to suit the (important) requirements of the compiler modules\, why are they run on normal execution? This would only make since if they are useful outside the scope of compiling a program (And I am unsure although not totally convinced that they aren't useful outside that).

I wonder if there is any valid use for them outside of the compiler\, and\, if not\, maybe they should be ignored unless the program gets compiled?

Maybe more for information than anything else\, but I use CHECK in Devel​::Cover. After the program is compiled\, but before it starts to run\, I prepare to collect the coverage information. I don't think that is an argument either for or against the current behaviour.

A quick grep of my .cpanplus directory only showed one other module using CHECK (Attribute​::Handlers)\, but a few more using INIT.

Thinking just as a Perl programmer\, the idea of multiple compile and run sessions\, each executing their own BEGIN\, CHECK\, INIT and END blocks seems to make sense and seems to simplfy the conceptual model of what gets exectued when. But I suspect that any change along those lines would require names other than CHECK and INIT.

-- Paul Johnson - paul@​pjcj.net http​://www.pjcj.net

[p5pRT]

From perl5-porters@ton.iguana.be

In article \20030628181900\.GF3985@&#8203;pjcj\.net\,   Paul Johnson \paul@&#8203;pjcj\.net writes​:

Thinking just as a Perl programmer\, the idea of multiple compile and run sessions\, each executing their own BEGIN\, CHECK\, INIT and END blocks seems to make sense and seems to simplfy the conceptual model of what gets exectued when.

END is an exception however. It's more like C atexit\, and runs just before interpreter destruction instead of the end of a (local) runtime. I really don't think you want require END blocks to run before you get a chance to use what got required.

[p5pRT]

From @rgs

Paul Johnson wrote​:

Maybe more for information than anything else\, but I use CHECK in Devel​::Cover. After the program is compiled\, but before it starts to run\, I prepare to collect the coverage information. I don't think that is an argument either for or against the current behaviour.

Actually Devel​::Cover relies on the current behaviour of CHECK. When using

  perl -MDevel​::Cover yourprog args

it's important that the CHECK block defined in Devel​::Cover is run after "yourprog" is parsed.

Thinking just as a Perl programmer\, the idea of multiple compile and run sessions\, each executing their own BEGIN\, CHECK\, INIT and END blocks seems to make sense and seems to simplfy the conceptual model of what gets exectued when. But I suspect that any change along those lines would require names other than CHECK and INIT.

IMHO this new kind of special sub requires only one name. That would be a block that is run when a file and/or block has finished being parsed\, but before it's executed. The little distinction between CHECK and INIT makes little sense here\, as it's only useful to distinguish between cases where the -c switch is present or not.

[p5pRT]

From @pjcj

On Sat\, Jun 28\, 2003 at 09​:25​:15PM +0200\, Rafael Garcia-Suarez wrote​:

Paul Johnson wrote​:

Maybe more for information than anything else\, but I use CHECK in Devel​::Cover. After the program is compiled\, but before it starts to run\, I prepare to collect the coverage information. I don't think that is an argument either for or against the current behaviour.

Actually Devel​::Cover relies on the current behaviour of CHECK. When using

perl \-MDevel​::Cover yourprog args

it's important that the CHECK block defined in Devel​::Cover is run after "yourprog" is parsed.

Right. I just meant that if the behaviour changed I wouldn't kick up a fuss - I'd just change Devel​::Cover.

Thinking just as a Perl programmer\, the idea of multiple compile and run sessions\, each executing their own BEGIN\, CHECK\, INIT and END blocks seems to make sense and seems to simplfy the conceptual model of what gets exectued when. But I suspect that any change along those lines would require names other than CHECK and INIT.

IMHO this new kind of special sub requires only one name. That would be a block that is run when a file and/or block has finished being parsed\, but before it's executed. The little distinction between CHECK and INIT makes little sense here\, as it's only useful to distinguish between cases where the -c switch is present or not.

I agree. And Ton is correct about the END block too. Perl6 calls these subs PRE and POST\, but doesn't mention anything about a state between compilation and running. Perl6 also mentions FIRST and LAST blocks.

-- Paul Johnson - paul@​pjcj.net http​://www.pjcj.net

[p5pRT]

From @rgs

Paul Johnson wrote​:

I agree. And Ton is correct about the END block too. Perl6 calls these subs PRE and POST\, but doesn't mention anything about a state between compilation and running. Perl6 also mentions FIRST and LAST blocks.

PRE and POST ? Hey\, but we do have them !

  http​://search.cpan.org/author/ABERGMAN/Hook-Scope-0.04/Scope.pm

(NB. this module seems to be in flux.)

[p5pRT]

From nick.ing-simmons@elixent.com

Rafael Garcia-Suarez \rgarciasuarez@&#8203;free\.fr writes​:

Thinking just as a Perl programmer\, the idea of multiple compile and run sessions\, each executing their own BEGIN\, CHECK\, INIT and END blocks seems to make sense and seems to simplfy the conceptual model of what gets exectued when. But I suspect that any change along those lines would require names other than CHECK and INIT.

IMHO this new kind of special sub requires only one name. That would be a block that is run when a file and/or block has finished being parsed\, but before it's executed. The little distinction between CHECK and INIT makes little sense here\, as it's only useful to distinguish between cases where the -c switch is present or not.

Not so.

Another way of looking at this​:

CHECK is an END block for compile phase.

INIT is a BEGIN block for run phase.

In particular if you "compile" using B​:: modules by running the CHECK block\, then the INIT block is run "later" (different day\, another machine) when the code is run.

So modules like Tk which need initialization to be done on each run and which wish to be B​:: friendly have to do that initialization in an INIT block. (Or an XS called INIT or ...)

-- Nick Ing-Simmons http​://www.ni-s.u-net.com/

[p5pRT]

From pcg@goof.com

On Mon\, Jun 30\, 2003 at 08​:30​:19AM -0000\, Nick Ing-Simmons \perlbug\-followup@&#8203;perl\.org wrote​:

In particular if you "compile" using B​:: modules by running the CHECK block\, then the INIT block is run "later" (different day\, another machine) when the code is run.

So modules like Tk which need initialization to be done on each run and which wish to be B​:: friendly have to do that initialization in an INIT block. (Or an XS called INIT or ...)

But Tk cannot use INIT for this currently as there is no guarentee that INIT is even run\, or that Tk is only used after INIT has been run. For example\, if Tk requires that INIT to be run to initialize itself this would mean that one cannot use the Tk module from another module\, as it isn't initialized yet (which is not the case).

Worse\, since sometimes INIT isn't called at all Tk mustn't depend on it being run at all.

As such\, CHECK and INIT can only make sense as a kind of suspend/resume mechanism. Sure\, you could just init on module load and then again within INIT\, detecting that it already is initialized and skip it.

But then the code in CHECK/INIT is run everytime\, even when not used\, which is a potential performance hit since INIT isn'T needed in 99% of the cases as no compiler is involved.

In the case of Tk this might be a trivial pointer check\, but in other modules that build complex data structures this might not be the case. Sure\, one could probably always try to optimize this\, but the point is that INIT/CHECK isn't really a good solution to the suspend/resume problem\, not a solution at all to my scoping issues\, and not a good solution for analyzer tools such as profilers.

Since my immediate urges (getting my problem solved\, easy solution​: none ;) have been "solved"\, I am currently not arguing because I darely need a rewrite\, but for the sake of design.

And now it looks to me as if CHECK/INIT is not a properly designed language feature. For compiler support\, I would expect it not to run when the compiler is not used. For my kind of scoping problems it would be needed to run afetr each compile/run phase\, and for profilers or other tools\, it doesn't matter much\, as a profiler is usually called within the contetx of the main program\, and if it's called from a module\, I guess the intent was the module to be profiled\, not the whole program. Wether that's doable is another question\, but the fact that "use module-that-uses-init" cannot rely on INIT beign run at all is a good indication to me that such tools either cannot rely on INIT or must be able to work without it.

--   -----==- |   ----==-- _ |   ---==---(_)__ __ ____ __ Marc Lehmann +--   --==---/ / _ \/ // /\ \/ / pcg@​goof.com |e|   -=====/_/_//_/\_\,_/ /_/\_\ XX11-RIPE --+   The choice of a GNU generation |   |

[p5pRT]

From nick.ing-simmons@elixent.com

Marc) (Lehmann \pcg@&#8203;goof\.com writes​:

On Mon\, Jun 30\, 2003 at 08​:30​:19AM -0000\, Nick Ing-Simmons \perlbug\-followup@&#8203;perl\.org wrote​:

In particular if you "compile" using B​:: modules by running the CHECK block\, then the INIT block is run "later" (different day\, another machine) when the code is run.

So modules like Tk which need initialization to be done on each run and which wish to be B​:: friendly have to do that initialization in an INIT block. (Or an XS called INIT or ...)

But Tk cannot use INIT for this currently as there is no guarentee that INIT is even run\, or that Tk is only used after INIT has been run.

This is clearly "Fear Uncertainty and Doubt". Tk _does_ use INIT and it works.

For example\, if Tk requires that INIT to be run to initialize itself this would mean that one cannot use the Tk module from another module\, as it isn't initialized yet (which is not the case).

That isn't what I said/meant. Tk can be used if Tk.pm (and Tk/*.pm) body/ies have been executed or the INIT blocks have been run.

Worse\, since sometimes INIT isn't called at all Tk mustn't depend on it being run at all.

As such\, CHECK and INIT can only make sense as a kind of suspend/resume mechanism.

Now that is close to what I said. Someone was suggesting INIT could go - I was pointing out that it was a necessary part of the resume process.

Sure\, you could just init on module load and then again within INIT\, detecting that it already is initialized and skip it.

That is what Tk does.

But then the code in CHECK/INIT is run everytime\, even when not used\, which is a potential performance hit since INIT isn'T needed in 99% of the cases as no compiler is involved.

As I recall the CHECK only happens when a compiler puts it there\, and you only do INIT if you have done CHECK so they all disapear without the compile.

Now\, if you want to use CHECK/INIT for something other than compile/run then you have to reconcile what happens with what you want...

In the case of Tk this might be a trivial pointer check\, but in other modules that build complex data structures this might not be the case.

It wasn't a trivial check in Tk till I made it so.

Sure\, one could probably always try to optimize this\, but the point is that INIT/CHECK isn't really a good solution to the suspend/resume problem\, not a solution at all to my scoping issues\, and not a good solution for analyzer tools such as profilers.

Never intended as such ?

Since my immediate urges (getting my problem solved\, easy solution​: none ;) have been "solved"\, I am currently not arguing because I darely need a rewrite\, but for the sake of design.

And now it looks to me as if CHECK/INIT is not a properly designed language feature.

Correct ;-)

For compiler support\, I would expect it not to run when the compiler is not used.

For my kind of scoping problems it would be needed to run afetr each compile/run phase\, and for profilers or other tools\, it doesn't matter much\, as a profiler is usually called within the contetx of the main program\, and if it's called from a module\, I guess the intent was the module to be profiled\, not the whole program. Wether that's doable is another question\, but the fact that "use module-that-uses-init" cannot rely on INIT beign run at all is a good indication to me that such tools either cannot rely on INIT or must be able to work without it. -- Nick Ing-Simmons http​://www.ni-s.u-net.com/

[p5pRT]

From pcg@goof.com

On Mon\, Jun 30\, 2003 at 02​:46​:01PM -0000\, Nick Ing-Simmons \perlbug\-followup@&#8203;perl\.org wrote​:

So modules like Tk which need initialization to be done on each run and which wish to be B​:: friendly have to do that initialization in an INIT block. (Or an XS called INIT or ...)

But Tk cannot use INIT for this currently as there is no guarentee that INIT is even run\, or that Tk is only used after INIT has been run.

This is clearly "Fear Uncertainty and Doubt". Tk _does_ use INIT and it works.

I don't understand that reaction... Tk would simply NOT work properly if it would rely on what you said... You have to initialize Tk _again_\, and only if necessary\, in an INIT block\, to make it work.

If you implement what you claim (initialize Tk within INIT)\, then how would you cope with the situation where INIT isn't run?

Basically\, "initialization on each run" is _not_ done within INIT\, since INIT simply isn't called on "each run".

isn't initialized yet (which is not the case).

That isn't what I said/meant. Tk can be used if Tk.pm (and Tk/*.pm) body/ies have been executed or the INIT blocks have been run.

That is indeed probably what you meant\, but I wasn't sure from what you wrote.

As I recall the CHECK only happens when a compiler puts it there\, and you only do INIT if you have done CHECK so they all disapear without the compile.

I don't understand this sentence... when does the compiler put CHECK anywhere? Isn't it program and module authors who put it somewhere? And what do you mean that INIT is only done if you have done CHECK? There is no need to define CHECK to get a INIT run.

If I understand this correctly\, this would mean that thes eprograms wouldn't die​:

  perl -e 'CHECK { die }'   perl -e 'INIT { die }'

but they do.

Sure\, one could probably always try to optimize this\, but the point is that INIT/CHECK isn't really a good solution to the suspend/resume problem\, not a solution at all to my scoping issues\, and not a good solution for analyzer tools such as profilers.

Never intended as such ?

Well... last I was told that INIT/CHECK indeed was cdreated to solve the suspend/resume problem of the compiler. Now... what *was* it created for? ;)

--   -----==- |   ----==-- _ |   ---==---(_)__ __ ____ __ Marc Lehmann +--   --==---/ / _ \/ // /\ \/ / pcg@​goof.com |e|   -=====/_/_//_/\_\,_/ /_/\_\ XX11-RIPE --+   The choice of a GNU generation |   |

[p5pRT]

From nick.ing-simmons@elixent.com

Marc) (Lehmann \pcg@&#8203;goof\.com writes​:

On Mon\, Jun 30\, 2003 at 02​:46​:01PM -0000\, Nick Ing-Simmons \perlbug\-followup@&#8203;perl\.org wrote​:

So modules like Tk which need initialization to be done on each run and which wish to be B​:: friendly have to do that initialization in an INIT block. (Or an XS called INIT or ...)

But Tk cannot use INIT for this currently as there is no guarentee that INIT is even run\, or that Tk is only used after INIT has been run.

INIT is guarenteed to run after a B​::* compile.

This is clearly "Fear Uncertainty and Doubt". Tk _does_ use INIT and it works.

I don't understand that reaction... Tk would simply NOT work properly if it would rely on what you said... You have to initialize Tk _again_\, and only if necessary\, in an INIT block\, to make it work.

If you implement what you claim (initialize Tk within INIT)\, then how would you cope with the situation where INIT isn't run?

It is run after a B​::* compile.

In the normal non-compiled case the bodies of Tk.pm et. al. do the initialize.

Basically\, "initialization on each run" is _not_ done within INIT\, since INIT simply isn't called on "each run".

It is if thing is B​::* compiled - which is what I was discussing. If I B​:: compile script and then run it 1009 times all 1009 runs are initialized by INIT - which is what 'each' meant.

isn't initialized yet (which is not the case).

That isn't what I said/meant. Tk can be used if Tk.pm (and Tk/*.pm) body/ies have been executed or the INIT blocks have been run.

That is indeed probably what you meant\, but I wasn't sure from what you wrote.

What you quote above is clearly discussing "wish to be B​:: friendly". The _entire_ point of the original mail was to say

"Whoa there you cannot loose INIT is is needed in B​::* compiled scripts"

As I recall the CHECK only happens when a compiler puts it there\, and you only do INIT if you have done CHECK so they all disapear without the compile.

I don't understand this sentence... when does the compiler put CHECK anywhere?

lib/O.pm line 28

However\, it seems I mis-remembered how it works and INIT blocks are indeed run in a normal non-compiled case as well (ugh!).

Sure\, one could probably always try to optimize this\, but the point is that INIT/CHECK isn't really a good solution to the suspend/resume problem\, not a solution at all to my scoping issues\, and not a good solution for analyzer tools such as profilers.

Never intended as such ?

Well... last I was told that INIT/CHECK indeed was cdreated to solve the suspend/resume problem of the compiler.   ^^^^^^^^^^^^^^^

Of the compiler is the critical clause ;-)
It suits the compiler - and that is all that was really considered. Only the compiler really uses 'em - so if they are tweaked to make them more generaly useful then compiler needs to be fixed to match new spec.

Now... what *was* it created for?

The compiler.

-- Nick Ing-Simmons http​://www.ni-s.u-net.com/

[p5pRT]

@rgs - Status changed from 'new' to 'resolved'