Re: Perl6 Macros

2002-03-28 Thread Luke Palmer
How about we implement some way to peer into coderefs? Maybe just on the top level, with attributes, or maybe a syntax tree (probably not). Because here, what both arguments (in the discussion) are missing, is the ability to look at their arguments' (the uh, ones you pass in) internal

Re: Perl6 Macros

2002-03-28 Thread Simon Cozens
Aaron Sherman: This just brought something to mind when I re-read it. I was thinking about how this would transform back into Perl, and I thought... gee, you can't do that easily because you're taking the result of a block, and Perl can only do that via function call or eval, Or do, which

Re: Perl6 Macros

2002-03-28 Thread Aaron Sherman
On Wed, 2002-03-27 at 19:46, Michel J Lambert wrote: Macros could add something to Perl, but I don't see why having a macro return a string instead of looking and acting like a subroutine would be a bad thing. In fact, as I pointed out before, you can do almost all of the scoping stuff

Re: Perl6 Macros

2002-03-28 Thread Aaron Sherman
On Thu, 2002-03-28 at 10:19, Aaron Sherman wrote: Here's what I suggest as a compromise: macro forall ($iterator, $list, $block) { my ltmp = ($list); foreach $iterator - ltmp $block } forall{$var}{@list}{{print;}}; Where the parser sees macro NAME PARAMS BLOCK

Re: Perl6 Macros

2002-03-27 Thread Aaron Sherman
On Tue, 2002-03-26 at 16:26, Michel J Lambert wrote: An example of where variable capture is needed is: macro println ($a) { return EOF; print $a; print \n; EOF } for my $b (1..100) { println $b; } Ok, I don't get it. I'm willing to concede that I'm dense, but I need to

Re: Perl6 Macros

2002-03-27 Thread Dan Sugalski
At 10:27 AM -0500 3/27/02, Aaron Sherman wrote: I *can* see some advantage in: macro mygrep ($code is macroblock, *@list) { my @newlist = (); for @list { push @newlist, $_ if $code.(); } return @newlist; } @x = mygrep {/\S/} $fh.getlines();

Re: Perl6 Macros

2002-03-27 Thread Larry Wall
Dan Sugalski writes: : Just out of curiosity, is there anything macros (in the Lisp sense) : can do that source filters can't? Avoid reparsing the language themselves? Larry

Re: Perl6 Macros

2002-03-27 Thread Michel J Lambert
New syntax is 'qs', aka quote sub, which is similar to q, except that it interpolates all of: ${..} {..} and %{..} All subroutines which are interpolated, are interpolated as regular text, with no bindings, so that they get lexically scoped in the code they are returned as part of. Then macros

Re: Perl6 Macros

2002-03-27 Thread Aaron Sherman
First impression: Don't go there. Longer answer: On Wed, 2002-03-27 at 16:29, Michel J Lambert wrote: New syntax is 'qs', aka quote sub, which is similar to q, except that it interpolates all of: ${..} {..} and %{..} All subroutines which are interpolated, are interpolated as regular text,

Re: Perl6 Macros

2002-03-27 Thread Michel J Lambert
Basically, one of the goals of Perl6 was to allow for you to implement any perl construct, in perl. None of the operators were to use any special features that could not be done by regular subroutines. And personally, I don't see how we're going to be able to do all this lazy evaluation of

Re: Perl6 Macros

2002-03-27 Thread Buddha Buck
Michel J Lambert [EMAIL PROTECTED] writes: Macros could add something to Perl, but I don't see why having a macro return a string instead of looking and acting like a subroutine would be a bad thing. In fact, as I pointed out before, you can do almost all of the scoping stuff that you

Re: Perl6 Macros

2002-03-26 Thread Michel J Lambert
macro foo($a,$b) { return( $c // $a+$b ); } print foo(1,2), \n; my $c=100; print foo(1,2) \n; Yeah, your example provided is correct. It's called variable capture, and there's some work required by common lisp macros to ensure that unwanted variable capture does not occur. I don't