: >[EMAIL PROTECTED] (Luke Palmer) writes:
: >
: >
: >>I would hope the former. However, what about this compile-time
: >>integral power macro[1]?
: >>
: >> macro power ($x, $p) {
: >> if $p > 0 {
: >> { $x * power($x, $p-1) }
: >> }
: >> else {
: >> { 1 }
:
On Mon, 15 Sep 2003, Piers Cawley wrote:
> Luke Palmer <[EMAIL PROTECTED]> writes:
>
> > Alex Burr writes:
> >> In theory you could write one as a perl6 macro, although it would be
> >> more convenient if there was someway of obtaining the syntax tree of a
> >> previously defined function other t
Austin Hastings <[EMAIL PROTECTED]> writes:
> --- Luke Palmer <[EMAIL PROTECTED]> wrote:
>> Alex Burr writes:
>
>> > But I confidently predict that no-one with write a useful
>> > partial evaluator for perl6. The language is simply too big.
>>
>> Then again, there are some very talented people wi
Luke Palmer <[EMAIL PROTECTED]> writes:
> Alex Burr writes:
>> In theory you could write one as a perl6 macro, although it would be
>> more convenient if there was someway of obtaining the syntax tree of a
>> previously defined function other than quoting it (unless I've missed
>> that?).
>
> Th
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
>
> --- Luke Palmer <[EMAIL PROTECTED]>
> wrote:
>
> > Then again, there are some very talented people
> with a lot of free
> > time in the Perl community; I wouldn't count it
> out.
>
> That looked to me like a "Damian troll", hoping that
> DC wou
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> Alex Burr writes:
> > But I confidently predict that no-one with write a useful
> > partial evaluator for perl6. The language is simply too big.
>
> Then again, there are some very talented people with a lot of free
> time in the Perl community; I wou
Alex Burr wrote:
[EMAIL PROTECTED] (Luke Palmer) writes:
I would hope the former. However, what about this compile-time
integral power macro[1]?
macro power ($x, $p) {
if $p > 0 {
{ $x * power($x, $p-1) }
}
else {
{ 1 }
}
}
That would hopef
Alex Burr writes:
> In theory you could write one as a perl6 macro, although it would be
> more convenient if there was someway of obtaining the syntax tree of a
> previously defined function other than quoting it (unless I've missed
> that?).
There is a large class of cool optimizations possibl
[EMAIL PROTECTED] (Luke Palmer) writes:
> I would hope the former. However, what about this compile-time
> integral power macro[1]?
>
> macro power ($x, $p) {
> if $p > 0 {
> { $x * power($x, $p-1) }
> }
> else {
> { 1 }
> }
> }
>
> 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
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
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 *
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
13 matches
Mail list logo
