On Sat, 2002-03-30 at 21:41, Michel J Lambert wrote:
> > > Too late. I'm going there... :)
> > Good for you. I was hoping transformations could make it :)
>
> Why didn't you chime in support before, then? I feel like Aaron and I are
> the only ones who are opinionated on this matter...
Hopefully
Luke Palmer [mailto:[EMAIL PROTECTED]] wrote:
> Then the macro would not recieve 4 as the second argument,
> rather 2*6/3 in syntax tree form. Would the macro have to
> do its own constant folding? I hope not. So how could it
> check whether this thing was an integer? How could it
> differentiate
> > Too late. I'm going there... :)
> Good for you. I was hoping transformations could make it :)
Why didn't you chime in support before, then? I feel like Aaron and I are
the only ones who are opinionated on this matter...
> Here's something I was wondering. Say you wanted to write a pow() macr
On Fri, Mar 29, 2002 at 11:23:26PM -0700, Luke Palmer wrote:
> > Too late. I'm going there... :)
> Good for you. I was hoping transformations could make it :)
>
> Here's something I was wondering. Say you wanted to write a pow() macro
> (from a previous example) that would forward to C's pow() u
Michel J Lambert wrote in perl.perl6.language :
> Has anyone done any thinking along the
> lines of how we are implementing the Perl 6 grammer?
Simon Cozens did. I don't know the details exactly.
Note also that the grammar and the parser are not the difficult part;
the perl 5 lexer is very compl
> Too late. I'm going there... :)
Good for you. I was hoping transformations could make it :)
Here's something I was wondering. Say you wanted to write a pow() macro
(from a previous example) that would forward to C's pow() unless the
exponent was an integer, in which case it would optimize to
> > - Transformation: they can look inside the structure of their arguments.
>
> Ok, here's where I think you don't want to go. I understand the power,
Too late. I'm going there... :)
Letting it sit in my mind for a few days, I have a couple new ideas,, or
rather, ideas I've read about elsewhere
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 P
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
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, whic
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
struct
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
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
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
> 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 searched the archives with Google (what, no internal search engine??),
and found the thread on perl6 macros, which I did read.
>From what I saw, it mostly concentrated on using macros for speed. That
should be a minor argument, especially considering this is perl. :)
Common Lisp macros
22 matches
Mail list logo
