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 would want out of a macro in Perl with the
> > existing subroutine/code ref syntax and a special property.
>
> I disagree here. How would I define foreach as a macro (assuming the
> following, simplified syntax).
> foreach $each, @array, {
> print $each;
> };
>
> Since $each is being passed to the foreach macro, the macro needs to
> create a lexical scoping for $each, and place the third argument as a loop
> body, within the context of the scoping it just defined.
That suggested a similar example to me...
In Lisp (or, more likely, Scheme), you get constructs like:
(let ((a 'b) (c 'd) ... ) (...))
being defined as equivalent to:
((lambda (a c ...) (...)) 'b 'd ...)
and the macro system can convert the let into the evaluated lambda.
Suppose we wanted to have a Perl construct that was similar:
my $a = let ($b -> 5, $c -> $x) { $b + $c };
The most similar replacement for the let to the lisp case is:
my $a = &(sub { my ($b, $c) = @_; return $b, $c; })(5, $x);
With the macro system (using qs() for things to be evaluated at
compile time), I could see something like:
macro let (%&)
{ &(sub { my qs(keys @_[0]) = @_; return qs(@_[1]); })(qs(values @_[1]))};
I'm not sure that that would work perfectly offhand (I suspect some
syntax tweaking would be necessary) but it's the basic idea I think
you are going for.
--
Buddha Buck [EMAIL PROTECTED]
"I will not die an ironic death" -- Scott Ian, lead singer for
the metal band Anthrax, after bioterrorist attacks using anthrax.
