paths:
M S06-routines.pod
Log Message:
---
clarify that macros can't be called before they're defined
On Wed, Jun 30, 2010 at 7:33 PM, Jonathan Worthington jonat...@jnthn.netwrote:
Aaron Sherman wrote:
See below for the S06 section I'm referring to.
I'm wondering how we should be reading the description of user-defined
operators. For example, sub infix:(c) doesn't describe
the precedence
, so that's a bug, but the question is, should I expect it to work?
Things get a bit more strange when I try to wrap my head around macros. From
the example:
macro circumfix:«!-- --» ($text) is parsed / .*? / { }
OK, so when a circumfix would be allowed (any expression?) we accept
generation fail.
OK, so that's a bug, but the question is, should I expect it to work?
Yes, I believe it should.
skipping macros bit for somebody else who groks them :-)
I think there's also a bug in the examples when it comes to ±. That can be a
method, sure, that makes sense, but in which case
a compile time switch switch statement is possible with
the existing macros. Would anyone like to take a shot at defining a
macro to do this? Is it possible to jump to something outside of a
macros input that is also evaluated at compile time?
Using '#END' (or rather, q:to'#END') is actually
that defining
something like a compile time switch switch statement is possible with
the existing macros. Would anyone like to take a shot at defining a
macro to do this? Is it possible to jump to something outside of a
macros input that is also evaluated at compile time?
Using '#END' (or rather, q:to
On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote:
On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote:
You don't actually need a macro in that case:
if 0 { q
...
}
Which, of course, eliminates the original desire to have a
code-commenting construct where you just
On 8/20/06, Joshua Hoblitt [EMAIL PROTECTED] wrote:
This is exactly the type of construct that I had in mind. A couple of
questions. Is code inside of a #{}:
- parsed and required to be syntacticly correct?
No. It's a comment. # followed by one or more open bracket characters
creates a
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote:
#{
if $baz {
$foo.bar
}
}
To uncomment, remove the # before the {.
This is exactly the type of construct that I had in mind. A couple of
questions. Is code inside of a #{}:
- parsed and required
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote:
: On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote:
: On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote:
: You don't actually need a macro in that case:
:
: if 0 { q
: ...
: }
:
: Which, of course,
On 8/20/06, Andrew Suffield [EMAIL PROTECTED] wrote:
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote:
#{
if $baz {
$foo.bar
}
}
To uncomment, remove the # before the {.
This is exactly the type of construct that I had in mind. A couple of
questions.
On 8/20/06, Luke Palmer [EMAIL PROTECTED] wrote:
Well, I think you are being too picky.
[snip snarky sarcastic rant]
Hmm, perhaps I'm feeling edgy. Or maybe some of the comments reminded
me of those rediculously long, whiny threads. Anyway, that was
un-called-for.
Luke
On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote:
The important question here is this one:
- when 'uncommented', is it a no-op?
Which isn't true for #{}/{}, because {} introduces new lexical
scope.
Why would you care about introducing a new lexical scope? You would
care
On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote:
On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote:
You don't actually need a macro in that case:
if 0 { q
...
}
Which, of course, eliminates the original desire to have a
code-commenting construct where you just
Stuart Cook schreef:
Larry Wall:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
commented-out code temporarily fails to compile.
How frequent does that happen?
And in that case s/if 0/\#/, as Luke mentioned.
And if the compile failure has to
Stuart Cook schreef:
Larry Wall:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
commented-out code temporarily fails to compile.
How frequent does that happen?
All the time. I often comment out bits of code while I'm refactoring or
It occurred to me that other day that in our in house C code we
somewhat frequently use an idiom that's not easily translated into Perl
5. Our rule is that if your commenting out more then 1 or 2 lines of
code that you wrap it in a CPP if statement. The logic being that
if you haven't deleted
On Fri, Aug 18, 2006 at 11:58:20AM -1000, Joshua Hoblitt wrote:
: It occurred to me that other day that in our in house C code we
: somewhat frequently use an idiom that's not easily translated into Perl
: 5. Our rule is that if your commenting out more then 1 or 2 lines of
: code that you wrap
On 8/19/06, Larry Wall [EMAIL PROTECTED] wrote:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
commented-out code temporarily fails to compile. If that's a
problem, though, you could always write your own macro.
Stuart Cook
Stuart Cook writes:
On 8/19/06, Larry Wall [EMAIL PROTECTED] wrote:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
commented-out code temporarily fails to compile. If that's a
problem, though, you could always write your own macro.
You don't
On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote:
You don't actually need a macro in that case:
if 0 { q
...
}
Which, of course, eliminates the original desire to have a
code-commenting construct where you just change the 0 to a 1. After
all, we already have #{}.
:
: Macros are functions or operators that are called by the compiler as
: soon as their arguments are parsed (if not sooner). The syntactic
: effect of a macro declaration or importation is always lexically
: scoped, even if the name of the macro is visible elsewhere.
:
: And presumably
Hi,
I've read and reread the macro explanation but I'm still not entirely
clear on number of things. The questions and thoughts below are based
on my (mis)understanding.
On 03/02/06 02:05, Larry Wall wrote:
Macros are functions or operators that are called by the compiler as
soon
don't have to rely on
: string concatenation, and we don't have to construct parse trees by
: hand. It's sort of a happy medium. But that is as yet unspecced.
S06 now sez:
+=head2 Macros
+Macros are functions or operators that are called by the compiler as
+soon as their arguments are parsed
After a little more cleanup, S06 now reads:
=head2 Macros
Macros are functions or operators that are called by the compiler as
soon as their arguments are parsed (if not sooner). The syntactic
effect of a macro declaration or importation is always lexically
scoped, even
Perl6 will have macros. Good. Cool. But, sadly, that seems to be close
to the most specific thing anyone says about the subject. There is
some further discussion in Apocalypse Exegesis 6, but nothing in the
Synopsis.
Now, considering that macros are a language feature and that the
Synopses
On Sun, Jan 29, 2006 at 18:53:25 +, Herbert Snorrason wrote:
Perl6 will have macros. Good. Cool. But, sadly, that seems to be close
to the most specific thing anyone says about the subject. There is
some further discussion in Apocalypse Exegesis 6, but nothing in the
Synopsis.
Now
On 1/29/06, Yuval Kogman [EMAIL PROTECTED] wrote:
Aside from that they are normal perl 6 subroutines, that simply get
invoked during compile time instead of during runtime.
With one extra feature. By default (my preference) or with a trait,
parameters can get passed in as ASTs instead of real
On 29/01/06, Yuval Kogman [EMAIL PROTECTED] wrote:
Basically the plan is that when an internal AST language is decided
upon, the macros will be able to get either the source code text, or
an AST.
Two things. First, if the AST path is taken, doesn't that mean that
the AST representation has
On Sun, Jan 29, 2006 at 20:29:43 +, Herbert Snorrason wrote:
On 29/01/06, Yuval Kogman [EMAIL PROTECTED] wrote:
Basically the plan is that when an internal AST language is decided
upon, the macros will be able to get either the source code text, or
an AST.
Two things. First, if the AST
Hi,
just checking: Are anonymous macros allowed?
my $macro = macro ($x) { 100$x };
say $macro(3); # 1003
Of course, anonymous macros can't be called at compile-time, like normal
macros:
my $macro = rand 0.5
?? macro ($x) { 100$x }
:: macro ($x) { 200$x };
say $macro(3); # 1003
On Mon, Jun 13, 2005 at 05:25:59PM +0200, Ingo Blechschmidt wrote:
: just checking: Are anonymous macros allowed?
I have no problem with macros being first-class objects during
the compile. Though the macro itself may have a problem with your
passing it '3' when it is likely expecting an AST
On Fri, Apr 15, 2005 at 12:45:14PM +1200, Sam Vilain wrote:
: Larry Wall wrote:
: Well, only if you stick to a standard dialect. As soon as you start
: defining your own macros, it gets a little trickier.
:
: Interesting, I hadn't considered that.
:
: Having a quick browse through some
Larry Wall wrote:
(B Well, only if you stick to a standard dialect. As soon as you start
(B defining your own macros, it gets a little trickier.
(B
(BInteresting, I hadn't considered that.
(B
(BHaving a quick browse through some of the discussions about macros, many
(Bof the macros I saw
Jonathan Lang writes:
Larry Wall wrote:
So far we've only allowed is parsed on the macro itself, not on
individual arguments. Still, that's an interesting idea.
Forgive me if this has already been addressed, but this could have some
useful applications:
So far, everything I've read
Larry Wall wrote:
So far we've only allowed is parsed on the macro itself, not on
individual arguments. Still, that's an interesting idea.
Forgive me if this has already been addressed, but this could have some
useful applications:
So far, everything I've read about macro parsing concentrates
Larry Wall:
argument. In fact, ??:: could be implemented as an infix:?? macro
that does a special parse looking for a subsequent :: token.
...which gives us another built-in's implementation.
macro infix:?? ($cond, $expr1, $expr2)
is parsed(/:w (Perl6.expr) '::' (Perl6.expr)/) {
On Sun, Aug 03, 2003 at 02:05:50PM -0400, Brent Dax wrote:
: Larry Wall:
: argument. In fact, ??:: could be implemented as an infix:?? macro
: that does a special parse looking for a subsequent :: token.
:
: ...which gives us another built-in's implementation.
:
: macro infix:?? ($cond,
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 arguments
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
On Tue, Mar 11, 2003 at 04:39:05PM +0100, Matthijs van Duin wrote:
: Will infix operators be allowed to be macros instead of subs?
Yes, but they can't retroactively change the rules under which the left
argument was parsed. At most they can rearrange the returned parse
tree. The right argument
Will infix operators be allowed to be macros instead of subs?
They'd be kinda necessary for infix operators for which standard sub
conventions are insufficient and need to diddle the parse tree instead,
such as short-circuiting operators.
It would also allow Damien's original ~ operator (R2L
On Wednesday 23 October 2002 17:58, Luke Palmer wrote:
From: Adriano Nagelschmidt Rodrigues [EMAIL PROTECTED]
[...]
Do you think that Lisp macros make the language more powerful than
others (eg Perl)? I mean, do they really give a competitive
advantage, or are they being overrated (see
Luke Palmer [EMAIL PROTECTED] writes:
If you define powerful as can do more things, then of course not.
Lisp is implemented in C, and C's macros are certainly not essential
[aside: most major common lisp implementations (cmucl, sbcl,
openmcl, mcl, allegro and lispworks) are all native
Speaking about macros, I renember reading somewhere something about
Scheme hygenic macros, but i didn't really understood it.
Do they solve the maintenance problems of Lisp macros? Would they be
applicable to perl?
Thanks for any tips,
-angel
Angel Faus [EMAIL PROTECTED] writes:
Speaking about macros, I renember reading somewhere something about
Scheme hygenic macros, but i didn't really understood it.
Do they solve the maintenance problems of Lisp macros? Would they be
applicable to perl?
Scheme hygenic macros do a lot
On 25 Oct 2002, Marco Baringer wrote:
: Luke Palmer [EMAIL PROTECTED] writes:
: But think of what macros in general provide:
:
:* Multi-platform compatability
:* Easier maintenance
: * Creating/Embedding custom languages. aka - adapting
Luke Palmer writes:
Do you think that Lisp macros make the language more powerful than
others (eg Perl)? I mean, do they really give a competitive
advantage, or are they being overrated (see below)?
If you define powerful as can do more things, then of course not.
No, of course. I guess
On Thu, Oct 24, 2002 at 12:26:41PM -0300, Adriano Nagelschmidt Rodrigues wrote:
Luke Palmer writes:
Lisp is implemented in C, and C's macros are certainly not essential
to its functionality. But think of what macros in general provide:
* Multi-platform compatability
Hi,
Perl is my favorite language, and I'm eagerly following Perl 6 development. So
I would like to ask this question here. Sorry if I'm being inconvenient...
Do you think that Lisp macros make the language more powerful than others (eg
Perl)? I mean, do they really give a competitive advantage
Date: Wed, 23 Oct 2002 18:43:08 -0300
From: Adriano Nagelschmidt Rodrigues [EMAIL PROTECTED]
Hi,
Perl is my favorite language, and I'm eagerly following Perl 6
development. So I would like to ask this question here. Sorry if I'm
being inconvenient...
Do you think that Lisp macros make
these constant-folding operations.
If we define a constant-folding transformation category, then we can limit
the checks to just those category of transformations.
Now I'm growing concerned. It sounds to me like macro authors would have
a very hard time determining exactly how their macros
that of macros. For one thing, it doesn't require
any new syntax!
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
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() unless
the ideas of macros, transformations,
and so on.
What's the current plan in terms of allowing users to extend
the perl syntax and grammar? I haven't really seen any discussion from
Damian, Larry, Simon, etc on how this going to be accomplished. I don't
see it being covered in apocalpypse, since the camel
thinking is to with a Parse::RecDescent type grammar for the
language, which allows runtime extensibility. (wow, what a revolutionary
concept! ;) The rules would obviously not involve translation back into
code, as lisp macros do, but to some syntax tree. What I wanted of macros
then, could simply
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
structure and make decisions upon it. Like the pow(x, constant) example.
I'll leave it up to the macro innovator(s) to figure out how to do that.
But if you can't, you've lost one of the large powers of macros.
Luke
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, which
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 stuff
it interpolates ONLY the
variables in PARAMS into BLOCK for every occurance of the macro. The
macro itself is then treated as a quoting operator (I'm uncomfortable
with forall%x%%y%%z%;, but it seems to be an expected consequence of
this way of defining macros). So, the above would become
. See below
Personally, I'm at a loss for how macros will fit seamlessly in Perl 6.
The examples above return a string, instead of real code (to make it
easier to see how the interpolation works.) The code passes in a block of
code, which magically gets interpolated back into a string as its
the block.
Just out of curiosity, is there anything macros (in the Lisp sense)
can do that source filters can't?
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED
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
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
,
with no bindings, so that they get lexically scoped in the code they are
returned as part of.
Then macros essentially return a string which gets interpolated at the
call site.
macro while ($cond, $body) {
return qs{
GENLABEL:
goto ENDLABEL if( ${ $cond } );
${ $body
of
parameters (and, if/else, etc), different lexical scopes for passed
coderefs (foreach), and so on. Lisp macros provide the ability to
implement the semantics of every single one of these constructs, but
unfortunately, has the horribly monotonous syntax. And so my goal is to
provide those same semantics
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
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
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 don't
72 matches
Mail list logo
