develooper Front page | perl.perl5.porters | Postings from November 2002

Re: Did the assertion patch/feature submission get overlooked?

Salvador Fandiño
November 30, 2002 08:25
Re: Did the assertion patch/feature submission get overlooked?
Message ID:

I have been working further on the assertions patch.

Main change is that now assertion activation status is lexically 
scooped. I have defined a new flag HINT_ASSERTING for PL_hints (AKA $^H).

> I'm slightly worried about using up a whole one-character command-line
> flag for assertions - such things are a scarce resource - but it may
> be a fair use for such a thing. I want to think further on Salvador's
> comments about the granularity of the -A switch.

In the new version, the -A switch is used with a list of tags:

     perl -Afoo,bar ...

and what it really does is:

     use assertions::activate split(/,/,{foo,bar});

in a similar fashion to '-M' or '-d:' switches.

I can also think about a more generic -A flag usage:

     perl -Aassert=foo,bar -Adebug=cao ...

that would call

     use Activate::assert split(/,/,{foo,bar});
     use Activate::debug split(/,/,{cao};

(actually I almost prefer this second option to the one I have implemented)

Well, following with assertions::activate, calling

   use assertion::activate @tags

convert @tags to a list of regular expressions and stores them in 

then in the perl code, one can use the syntax

   use assertions 'foo';

and assertions in its scope will be activated if 'foo' matches any of 
the RE in @{^ASSERTING}.

You can also use several tags and assertions will be active if all of 
them are selected. If no tag is given, the package name is used as the 
tag. Finally there is

   use assertions '&', @tags;

that checks for the new @tags in addition to the ones already in scope.

In the assertion package attached, there is an file showing 
the different possibilities.

> And I need to look at the code, to see how complete and correct the

> implementation is; Yitzchak already mentioned one issue in this regard,

Following Yitzchak advice, I have updated affected modules (in the first 
version of the patch, I had only changed things in the perl core).

> which suggests there'll be some more work to do to complete the patch.

The part where I am more dubious about the correctness of the 
implementation is in Perl_ck_subr in 'op.c' when assertions are 
optimized out if not activated. I am not completely sure if it is ok to 
just free the assertion op subtree and put a new constant in its place.

Other issue is what happens to lexicals declared inside assertion args. 

  00   use strict;
  01   use warnings;
  02   no assertions;
  04   sub out : assertion { print "@_\n" };
  06   our $o="global";
  08   sub test {
  09        out (my $o="lexical");
  10        print "o=$o\n";
  11   }
  13   test();

assertion call in line 9 is deleted but the my declaration is still 

Alternative behavior would be to open a new scope for the assertion 
args, this could be easily done expanding assertion calls to

     asserting and assertion(@args)

(being 'asserting' 0 or 1, depending on assertions activation).


   - Salva Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About