> I could see something like:
>
> method operator.( $self: $function ) {
> if( $function eq "inc" ) { ++%self.funcount{$_[2]}; }
> else { $self.inc( $function ) }
> }
>
> That would count how many times you called each function.
Sounds a lot like aspect-oriented programming. If what you want
> but wait, there's more... what does:
>
> @multi_dim[$a][$b][$c]
>
> give?
It's representation hiding. I can change my layout from hashes to arrays
without the clients of my code having to know. :)
Seriously, the above argument might actually hold some merit when changing
a matrix to a sparse m
> > 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
> > - 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
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
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
> 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 are inc
