-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 wrote:
> 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 leve
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 level of this new op, so how is it parsed? Is there a
default?
The default is
file 'EVAL_1' line 105914178
Eh? What newline? And line 105914178?
OK, 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 / .*? /
ng. Which got me thinking about more
sophisticated compile time flow control. I imagine 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 o
more
sophisticated compile time flow control. I imagine 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 al
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 wou
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 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 coupl
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<
: > >...
: > >> }
: >
: > Wh
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 #{}:
>
> - p
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 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 constru
> "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 wh
"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 fai
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 constru
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 #{}. Incide
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 macr
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
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
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 t
Wall wrote:
: >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.
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
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 if
e would also like a quasiquoting mechanism, so 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 call
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
> >
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 AS
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
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 t
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 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 expect
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)
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 thro
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 m
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
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 concentra
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,
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 () <'::'> ()/) {
return {
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
--- "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
&
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* par
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 arg
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 <~
At 9:54 AM -0700 10/25/02, Larry Wall wrote:
Suppose you have a system in which all farm animals are classified
into the same category, and distinguished by one letter in their
name. All farm animals begin with, say, "snarfu". So we get: ...
A similar problem exists with street names. Some ho
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.
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?
Sche
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
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, sbc
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
&g
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:
> >
> >
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 mo
onvenient...
>
> 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 n
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
nly* on the nodes and subnodes, so we can limit
> the scope of where we have to re-check 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 will be applied.
> PS: Yes, I know I write too much. :)
Your vision of the internals is interesting, but I'm lost without a
concrete example. There are just too many "Perls" that could come from
what you suggest.
s seems like a much better
idea than that of macros. For one thing, it doesn't require
any new syntax!
rhaps
it's too radical for us to use in Perl 6. I haven't heard any of the
heavyweights chime in for or against 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
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() u
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 compl
> 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
plementing the Perl 6 grammer?
My current 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. Wha
; Where the parser sees "macro NAME PARAMS BLOCK" 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
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
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, whic
ernal
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
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
luation 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 se
interpolated as regular text,
> 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{
>
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.
T
no code reference is ever created. It could be abused mercilessly,
> but I can see the massive savings in performance that we would reap,
> especially when translating/compiling this code for native or JIT
> execution. This is because we don't have to fire a function call each
> t
{}) as being exactly the same as eval{} (or
whatever the Perl6 version is), but without the exception trapping.
The only problem is that in Perl, ({}) is already valid syntax (paren
grouping around an anonymous hash). So, you might need to special case
it, or come up with a different syntax (expr{} perh
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
don't have to fire a function call each
>time we execute 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
Your example seems to involve no variable capture at all, in fact, just
passing parameters to a macro. 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 int
> 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
e
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
In RFC 23, Damian Conway <[EMAIL PROTECTED]> proposes a syntax for
"higher-order functions". One example given is related to a proposed
switch statement (RFC 22). A trimmed version is:
> sub beverage {
> switch (shift) {
> case sub{ $_[0] < 10 } { retu
76 matches
Mail list logo