Re: Disappearing code

2005-08-20 Thread David Formosa \(aka ? the Platypus\)
On Thu, 09 Jan 2003 21:12:07 -0500, John Siracusa
[EMAIL PROTECTED] 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.


Re: Disappearing code

2003-01-14 Thread Piers Cawley
Damian Conway [EMAIL PROTECTED] writes:

 John Siracusa asked:

 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);
 But all those if DEBUGs or DEBUG s were a pain.  So I'm
 wondering what
 the solution will be in Perl 6.

 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 Cdebug is in the example above) causes the immediate sub call to be
 replaced -- during compilation! --  by the returned closure/block.

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.




Re: Disappearing code

2003-01-12 Thread Ken Fox
Damian Conway wrote:

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




Re: Disappearing code

2003-01-12 Thread Damian Conway
Ken Fox wrote:


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




Re: Disappearing code

2003-01-10 Thread Michael G Schwern
On Thu, Jan 09, 2003 at 07:55:20PM -0500, John Siracusa 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.
 
 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   [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance  [EMAIL PROTECTED] Kwalitee Is Job One



Re: Disappearing code

2003-01-10 Thread Michael G Schwern
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.

'off' was a bad name for it.


-- 

Michael G. Schwern   [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance  [EMAIL PROTECTED] Kwalitee Is Job One



Re: Disappearing code

2003-01-10 Thread John Siracusa
On 1/9/03 11:27 PM, Michael G Schwern wrote:
 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




Re: Disappearing code

2003-01-10 Thread Rafael Garcia-Suarez
John Siracusa [EMAIL PROTECTED] wrote:
 
 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...



Re: Disappearing code

2003-01-10 Thread Dan Brook
On Thu, 09 Jan 2003 19:55:20 -0500
John Siracusa [EMAIL PROTECTED] 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



Re: Disappearing code

2003-01-10 Thread John Siracusa
On 1/10/03 11:11 AM, Dan Brook wrote:
 On Thu, 09 Jan 2003 19:55:20 -0500
 John Siracusa [EMAIL PROTECTED] 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




Re: Disappearing code

2003-01-09 Thread Luke Palmer
 Date: Thu, 09 Jan 2003 19:55:20 -0500
 From: John Siracusa [EMAIL PROTECTED]
 
 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 DEBUGs 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#ifdefs 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



Re: Disappearing code

2003-01-09 Thread John Siracusa
On 1/9/03 9:01 PM, Luke Palmer wrote:
 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




Re: Disappearing code

2003-01-09 Thread John Siracusa
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?

-John