In E6 Damien writes about macros:
"As soon as it has parsed that subroutine call (including its argument
list) it will detect that the subroutine &request is actually a macro, so
it will immidiately call &request with the specified arguments".
If macroness is found *after* parsing the arguments,
--- "Abhijit A. Mahabal" <[EMAIL PROTECTED]> wrote:
> In E6 Damien writes about macros:
>
> "As soon as it has parsed that subroutine call (including its
> argument
> list) it will detect that the subroutine &request is actually a
> macro, so
> it will immidiately call &request with the specified
On Sat, Aug 02, 2003 at 08:40:26AM -0700, Austin Hastings wrote:
: You're both right.
Well, actually, I think Damian misspoke slightly. I only aim for
95% accuracy in the Apocalypses (or I'd never get them done). So I
think it's pretty spectacular if Damian gets to 99.44% accuracy in
the Exegese
While we seem to be on the subject of hashing out macro semantics,
here's a question I've had awhile.
What do macros do about being passed variables?
Let's say I make a C macro:
macro square ($x) {
{ $x * $x }
}
And then I have code.
my $var = 10;
print square $var;
Do
On Sat, Aug 02, 2003 at 01:18:01PM -0600, Luke Palmer wrote:
: While we seem to be on the subject of hashing out macro semantics,
: here's a question I've had awhile.
:
: What do macros do about being passed variables?
:
: Let's say I make a C macro:
:
: macro square ($x) {
: { $x *
As I understand it, the comments in the following two subs are correct.
sub foo (@array) {
my $x = @array[0]; # ok, allowed to read
@array[0] = "something"; # compile fails because '@array is ro'
}
sub bar (@array_2d) {
my $x = @array[0]; # ok, allo
Damian Conway <[EMAIL PROTECTED]> writes:
>
> From a Perl 6 perspective, it seems likely that C<%_> will be the name
>commonly used for the "slurpy hash" of a subroutine. Just as C<@_> will often
>be the name used for the "slurpy array". See Exegesis 6 for more details.
>
>Indeed, when it comes t
> Damian Conway <[EMAIL PROTECTED]> writes:
> >Hence, making C<%_> mean something different in core Perl 5 might possibly be
> >"forwards incompatible".
Representing the Backwards Compatiblity Police, I've had co-workers use
%_ as the globalist of all global hashes. %_ transends all packages and
> As I understand it, the comments in the following two subs are correct.
>
> sub foo (@array) {
> my $x = @array[0]; # ok, allowed to read
> @array[0] = "something"; # compile fails because '@array is ro'
> }
>
> sub bar (@array_2d) {
> my $x = @array[0]
On Sun, Aug 03, 2003 at 01:37:16AM +0200, Abigail wrote:
> I am fond of doing
>
> local %_ = @_;
>
> as one of the first statements of a subroutine. That, or
>
> my %args = @_;
>
> I like the latter because it uses a lexical variable, but I like the
> former because %_ fits with @_ and
On Sat, Aug 02, 2003 at 04:33:19PM -0700, Michael G Schwern wrote:
: I'm not making an argument against %_, just noting that *_ is used
: opportunisticly and you will break a few programs.
Not necessarily. If Perl 6 were to use %_ as parameter name, it
would be lexically scoped, and hide any pac
This is a rather silly question:
The code:
macro foo() { return {my $x = 7} }
foo;
print $x;
is equivalent to which of the following?
{my $x = 7}
print $x;
or
my $x = 7;
print $x;
Thanx,
abhi.
On Sat, Aug 02, 2003 at 07:10:46PM -0600, Luke Palmer wrote:
: Yeah, I think so. It might be that the first C<@array[0] =
: "something"> is actually valid, and the only things that would be
: invalid would be calling mutating methods on the array itself (like
: C).
Maybe not even that restrictiv
Larry Wall wrote:
[snip]
> Nope. $x and $p are syntax trees.
Macros are passed syntax trees as arguments, but return coderefs?
That's... odd.
I would expect that a macro would be expected to *return* a syntax
tree... which could then undergo (more) macro-expansion.
Sortof like how in lisp, a
Perl5 map and grep allow the first argument to be an expression which is
passed to the function instead of being evaluated. (Sort of a bare block.)
What does the signature for this look like? Is it done with "is parsed"
tricks, or will perl6 require the "map BLOCK LIST" syntax?
I was recently bit
On Sat, Aug 02, 2003 at 09:53:07PM -0600, John Williams wrote:
: Perl5 map and grep allow the first argument to be an expression which is
: passed to the function instead of being evaluated. (Sort of a bare block.)
: What does the signature for this look like? Is it done with "is parsed"
: tricks,
On Sat, Aug 02, 2003 at 10:29:05PM -0500, Abhijit A. Mahabal wrote:
: This is a rather silly question:
:
: The code:
: macro foo() { return {my $x = 7} }
: foo;
: print $x;
:
: is equivalent to which of the following?
:
: {my $x = 7}
: print $x;
:
: or
:
: m
> Larry Wall wrote:
> [snip]
> > Nope. $x and $p are syntax trees.
>
>
>
> Macros are passed syntax trees as arguments, but return coderefs?
>
> That's... odd.
>
> I would expect that a macro would be expected to *return* a syntax
> tree... which could then undergo (more) macro-expansion.
Ke
On Sat, Aug 02, 2003 at 08:16:19PM -0700, Larry Wall wrote:
> On Sat, Aug 02, 2003 at 04:33:19PM -0700, Michael G Schwern wrote:
> : I'm not making an argument against %_, just noting that *_ is used
> : opportunisticly and you will break a few programs.
>
> Not necessarily. If Perl 6 were to us
19 matches
Mail list logo
