"Disappearing" code
John Siracusa
under some conditions, but not there under others? I'm thinking of the
spiritual equivalent of #ifdef, only Perlish.
In Perl 5, there were many attempts to use such a feature for debugging and
assertions. What everyone wanted to do was write code like this:
debug("Doing foo with $bar and $baz");
foo($bar, $baz);
And then have the entire call to debug() just plain disappear when the
program was run with a certain flag, or when a particular constant was set,
or whatever. The closest we got in Perl 5, AFAIK, was stuff this:
use constant DEBUG => 0;
...
debug("Doing foo with $bar and $baz") if DEBUG;
foo($bar, $baz);
But all those "if DEBUG"s or "DEBUG &&"s were a pain. So I'm wondering what
the solution will be in Perl 6.
-John
Luke Palmer
> From: John Siracusa <sira...@mindspring.com>
>
> Has there been any discussion of how to create code in Perl 6 that's there
> under some conditions, but not there under others? I'm thinking of the
> spiritual equivalent of #ifdef, only Perlish.
>
> In Perl 5, there were many attempts to use such a feature for debugging and
> assertions. What everyone wanted to do was write code like this:
>
> debug("Doing foo with $bar and $baz");
> foo($bar, $baz);
> And then have the entire call to debug() just plain disappear when the
> program was run with a certain flag, or when a particular constant was set,
> or whatever. The closest we got in Perl 5, AFAIK, was stuff this:
>
> use constant DEBUG => 0;
> ...
> debug("Doing foo with $bar and $baz") if DEBUG;
> foo($bar, $baz);
Well, I just do:
sub debug {
print STDERR shift, "\n" if DEBUG;
}
And hopefully (I don't know P5 internals so well) that optimizes to a
no-op so there's not even a function call there. But it's a
negligible overhead anyway.
> But all those "if DEBUG"s or "DEBUG &&"s were a pain. So I'm wondering what
> the solution will be in Perl 6.
Not that C code is devoid of C<#ifdef>s everywhere there's conditional
code....
I don't see how you could do much without actually labeling what you
wanted to disappear. You could always use:
sub debug(&code) {
&code() if DEBUG;
}
For a more versatile and readable solution. I'm not sure what could
be more concise than that.
Luke
John Siracusa
> Well, I just do:
>
> sub debug {
> print STDERR shift, "\n" if DEBUG;
> }
>
> And hopefully (I don't know P5 internals so well) that optimizes to a
> no-op so there's not even a function call there.
I don't know P5 internals so well either, but I'm guessing you'll still get
the function call to debug().
> But it's a negligible overhead anyway.
Hey, it adds up! Okay, maybe it doesn't...but still, Perl 6 Should Be Able
To Do This! :) And I'd also like inline constructs like:
ASSERT $foo > 5 && is_happy(blah);
that may or may not be the same as the debug situation in Perl 6.
> I don't see how you could do much without actually labeling what you
> wanted to disappear.
I basically want a language-level guarantee that the call to debug()
disappears entirely under certain conditions. I don't want to have to rely
on details of the optimizer or whatever.
-John
John Siracusa
> I would assume it to be a compiler hint via subroutine attribute.
>
> sub debug ($msg) is off {
> print STDERR $msg;
> }
>
> some "this subroutine is a no-op if a flag is set" attribute.
Hm, not quite as convenient as setting a package global (constant)
somewhere. Maybe that same "off" bit could be set "from a distance" at
compile time?
-John
Michael G Schwern
> Has there been any discussion of how to create code in Perl 6 that's there
> under some conditions, but not there under others? I'm thinking of the
> spiritual equivalent of #ifdef, only Perlish.
>
> In Perl 5, there were many attempts to use such a feature for debugging and
> assertions. What everyone wanted to do was write code like this:
>
> debug("Doing foo with $bar and $baz");
> foo($bar, $baz);
I would assume it to be a compiler hint via subroutine attribute.
sub debug ($msg) is off {
print STDERR $msg;
}
some "this subroutine is a no-op if a flag is set" attribute.
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
Michael G Schwern
That would be the "if a flag is set" part. Point is, its easily handled
by some sort of subroutine attribute which looks at some flag somewhere.
'off' was a bad name for it.
John Siracusa
> On Thu, Jan 09, 2003 at 11:15:49PM -0500, John Siracusa wrote:
>> On 1/9/03 10:10 PM, Michael G Schwern wrote:
>>> I would assume it to be a compiler hint via subroutine attribute.
>>>
>>> sub debug ($msg) is off {
>>> print STDERR $msg;
>>> }
>>>
>>> some "this subroutine is a no-op if a flag is set" attribute.
>>
>> Hm, not quite as convenient as setting a package global (constant)
>> somewhere. Maybe that same "off" bit could be set "from a distance" at
>> compile time?
>
> That would be the "if a flag is set" part. Point is, its easily handled
> by some sort of subroutine attribute which looks at some flag somewhere.
Well, er, don't we need to decide what the subroutine attribute is, so that
the compiler will know to honor it and make the code "disappear"? It
doesn't seem like a feature that can be added from "userland" after the fact
(but maybe I'm wrong...)
-John
Rafael Garcia-Suarez
>
> Well, er, don't we need to decide what the subroutine attribute is, so that
> the compiler will know to honor it and make the code "disappear"? It
> doesn't seem like a feature that can be added from "userland" after the fact
> (but maybe I'm wrong...)
In Perl 5 that could be done from userland, as you say, by using an
optree manipulator (optimizer.pm for example). This could even be
lexically scoped. [Once the compiler hints are fixed.]
I expect Perl 6 to ship with (Parrot::* ?) modules that allow to examine and
to modify the compiled form of the programs. Something that probably Java 6
will not have...
Dan Brook
John Siracusa <sira...@mindspring.com> wrote:
> Has there been any discussion of how to create code in Perl 6 that's
> there under some conditions, but not there under others? I'm thinking
> of the spiritual equivalent of #ifdef, only Perlish.
If the perl6 command-line options are anything like perl5 then you
can just use the -P switch if preprocessor commands are your thing.
> In Perl 5, there were many attempts to use such a feature for
> debugging and assertions.
There has also been a proposal for patching perl5 to add assertions
which was recently discussed[1] on p5p, which if accepted has
implications for assertions in perl6 surely.
Dan
[1]
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-11/msg00325.html
John Siracusa
> On Thu, 09 Jan 2003 19:55:20 -0500
> John Siracusa <sira...@mindspring.com> wrote:
>> Has there been any discussion of how to create code in Perl 6 that's
>> there under some conditions, but not there under others? I'm thinking
>> of the spiritual equivalent of #ifdef, only Perlish.
>
> If the perl6 command-line options are anything like perl5 then you
> can just use the -P switch if preprocessor commands are your thing.
Source filtering is not exactly the solution I'm looking for... :)
-John
Damian Conway
Something like this:
module Debug;
my $debugging = 1;
method import ($debug) { $debguuging = $debug }
sub debug is immediate is exported (@message) {
return $debugging ?? { print $*STDERR: @message; } :: {;}
}
then:
use Debug;
debug("Doing foo with $bar and $baz");
and to deactivate the debug statements:
use Debug 0;
debug("Doing foo with $bar and $baz");
"Immediate" subroutines are executed as soon as they are parsed (i.e. they're
like named BEGIN blocks).
Returning a closure/block from an immediate sub called in a void context
(as C<debug> is in the example above) causes the immediate sub call to be
replaced -- during compilation! -- by the returned closure/block.
Voila! Perl 6 is its own macro language.
Damian
John Siracusa
> "Immediate" subroutines are executed as soon as they are parsed (i.e. they're
> like named BEGIN blocks).
>
> Returning a closure/block from an immediate sub called in a void context
> (as C<debug> is in the example above) causes the immediate sub call to be
> replaced -- during compilation! -- by the returned closure/block.
>
> Voila! Perl 6 is its own macro language.
Sweet :)
-John
Ken Fox
> sub debug is immediate is exported (@message) {
> return $debugging ?? { print $*STDERR: @message; } :: {;}
> }
Won't @message need lazy evaluation? How will Perl know to
delay interpolation until the result of the "macro" is called
at run time?
- Ken
Damian Conway
> Won't @message need lazy evaluation? How will Perl know to
> delay interpolation until the result of the "macro" is called
> at run time?
Good point. It would also need to be slurped.
So that's:
sub debug is immediate is exported (*@message is lazy) {
return $debugging ?? { print $*STDERR: @message; } :: {;}
}
Damian
Piers Cawley
So, one could implement 'assert' in the same package with something
like:
sub assert is immediate is exported
( rx/<expr>/ &expr ; $message = "Assertion failed " )
{
return $debugging ?? { &expr() || die $message } :: { ; }
}
For bonus points one could have the assertion die if it's called in a
non void context, but I'll leave that as an exercise for the
interested reader.
David Formosa
<sira...@mindspring.com> wrote:
[...]
> Hey, it adds up! Okay, maybe it doesn't...but still, Perl 6 Should Be Able
> To Do This! :) And I'd also like inline constructs like:
>
> ASSERT $foo > 5 && is_happy(blah);
macro debug ($code) is parsed (/{Perl6::Block}/) {
if ($debug) {
$code
} else {
""
}
}
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.