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
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
paramet
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
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 es
> > 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;
> > }
>
> And, if we inline the sub, the only difference will be...?
Okay, a bad example, in that it cou
On Wed, 2002-03-27 at 11:31, Dan Sugalski wrote:
> At 10:27 AM -0500 3/27/02, Aaron Sherman wrote:
> > macro mygrep ($code is macroblock, *@list) {
> > my @newlist = ();
> > for @list {
> > push @newlist, $_ if $code.();
> > }
> > return @newlist;
> > }
> >
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
Eric Roode writes:
: Larry Wall writes:
: > I think if we have to go through contortions to get at the outer topic
: > by name, it's better to just name the variable on the outer loop in the
: > first place. Adding -> $varname to the outer loop is safe, because it
: > doesn't change the seman
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.getlin
Larry Wall writes:
> I think if we have to go through contortions to get at the outer topic
> by name, it's better to just name the variable on the outer loop in the
> first place. Adding -> $varname to the outer loop is safe, because it
> doesn't change the semantics of topicality--now that
Aaron Sherman writes:
: Here's an example syntax:
:
: FOO: for @x {
: BAR: for @y {
: my $foo_under FOO:= $_;
: print $_, $foo_under;
: }
: }
I think if we have to go through contortions to get at the outer topic
by name, it's better to just name the variable on the outer loop in the
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
On Tue, 2002-03-26 at 13:19, Larry Wall wrote:
> Aaron Sherman writes:
> : Ok, so am I to take it that you could say:
> :
> : FOO: for @x {
> : BAR: for @y {
> : print $FOO::_;
> : }
> : }
>
> Er, I don't think so.
>
> : Or is OUTER a special-case label?
>
> It's a special case like M
13 matches
Mail list logo
