headers
Yiyi Hu | 2 Feb 2006 20:02
Picon

Is S05 correct?

Hmm,
There are sevral appears in S05 which use => instead of -> in a for loop.
So, Is this a typo?
eg:
    for  <at> {$<pairs>} => $pair {
        say "Key: $pair[0]";
        say "Val: $pair[1]";
    }

Thanks,
Xinming
Permalink | Reply | 6 comments |
headers
Larry Wall | 2 Feb 2006 20:57
Picon
Gravatar

Re: Is S05 correct?

On Fri, Feb 03, 2006 at 03:02:12AM +0800, Yiyi Hu wrote:
: Hmm,
: There are sevral appears in S05 which use => instead of -> in a for loop.
: So, Is this a typo?
: eg:
:     for  <at> {$<pairs>} => $pair {
:         say "Key: $pair[0]";
:         say "Val: $pair[1]";
:     }

Yes, that's a typo.  Thanks.  It is now fixed on svn.perl.org, and
should propagate to dev.perl.org by tomorrow.

Larry
Permalink | Reply | 5 comments |
headers
Larry Wall | 3 Feb 2006 00:29
Picon
Gravatar

Re: Macros?

On Sun, Jan 29, 2006 at 08:13:44PM +0000, Luke Palmer wrote:
: On 1/29/06, Yuval Kogman <nothingmuch <at> woobling.org> 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 values:
: 
:     macro debug ($var) {
:         qq[print '$var.text() = ' ~ $var.text()]
:     }
:     debug($foo  );
:     # expands to
:     print '$foo   = ' ~ $var  ;
: 
: We 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 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.  As with ordinary operators,
+macros may be classified by their grammatical category.  For a given grammatical
+category, a default parsing rule or set of rules is used, but those rules
+that have not yet been "used" by the time the macro keyword or token is seen
(Continue reading)

Permalink | Reply | 0 comments |
headers
Larry Wall | 3 Feb 2006 02:05
Picon
Gravatar

Re: Macros?

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 the name of the macro is visible elsewhere.  As with
    ordinary operators, macros may be classified by their grammatical
    category.  For a given grammatical category, a default parsing rule or
    set of rules is used, but those rules that have not yet been "used"
    by the time the macro keyword or token is seen can be replaced by
    use of "is parsed" trait.  (This means, for instance, that an infix
    operator can change the parse rules for its right operand but not
    its left operand.)

    In the absence of a signature to the contrary, a macro is called as
    if it were a method on the current match object returned from the
    grammar rule being reduced; that is, all the current parse information
    is available by treating C<self> as if it were a C<$/> object.
    [Conjecture: alternate representations may be available if arguments
    are declared with particular AST types.]

    Macros may return either a string to be reparsed, or a syntax tree
    that needs no further parsing.  The textual form is handy, but the
    syntax tree form is generally preferred because it allows the parser
    and debugger to give better error messages.  Textual substitution
    on the other hand tends to yield error messages that are opaque to
    the user.  Syntax trees are also better in general because they are
    reversible, so things like syntax highlighters can get back to the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Whipp | 3 Feb 2006 06:40

something between "state" and "my"

(from p6i)

Larry Wall wrote:
> On Thu, Feb 02, 2006 at 07:12:08PM +0100, Leopold Toetsch wrote:
> : >... Anyway,
> : >the P6 model of "state" is more like a persistent lexical than like
> : >C's static.  
> : 
> : Sorry for my dumb question - what's the difference then? (Besides that C 
> : dosn't have closures ;)
> 
> That *is* the difference. 
[...]

I was thinking about this discussion on p6i, and I started thinking that 
there's something between "my" and state: a "state" variable that is 
created/initialized on each invocation of a sub but only if it's not 
already in the dynamic scope (i.e. if its not a recursive call). A 
slightly silly example of its use (using "temp state" as the quantifier) 
would be:

   sub factorial(Int $x) {
       temp state Int $result = 1;
       $result *= $x;
       factorial $x-1 if $x > 2;
       return $result if want;
   }
   say factorial 6;

This code is essentially the same as any other recursive factorial
(Continue reading)

Permalink | Reply | 4 comments |
headers
Luke Palmer | 3 Feb 2006 07:45
Picon
Gravatar

Re: something between "state" and "my"

On 2/3/06, Dave Whipp <dave <at> whipp.name> wrote:
>    sub factorial(Int $x) {
>        temp state Int $result = 1;
>        $result *= $x;
>        factorial $x-1 if $x > 2;
>        return $result if want;
>    }
>    say factorial 6;

That's precisely what "env" variables are for.  The right way:

    sub factorial(Int $x) {
        env $result = 1;
        my sub fact(Int $x) {
            $+result *= $x;
            fact($x - 1) if $x > 2;
            return $result;
        }
        fact($x);
    }

Of course, you can view env variables as implicit parameters.  Given
that, this function might be able to reduce to:

    sub factorial(Int $x) {
        env $+result = 1;   # expecting $+result
                            # param, default to 1
        $+result *= $x;
        fact($x - 1) if $x > 2;
        return $result;
(Continue reading)

Permalink | Reply | 3 comments |
headers
Larry Wall | 3 Feb 2006 20:58
Picon
Gravatar

Re: something between "state" and "my"

On Fri, Feb 03, 2006 at 06:45:23AM +0000, Luke Palmer wrote:
: On 2/3/06, Dave Whipp <dave <at> whipp.name> wrote:
: >    sub factorial(Int $x) {
: >        temp state Int $result = 1;
: >        $result *= $x;
: >        factorial $x-1 if $x > 2;
: >        return $result if want;
: >    }
: >    say factorial 6;
: 
: That's precisely what "env" variables are for.  The right way:
: 
:     sub factorial(Int $x) {
:         env $result = 1;
:         my sub fact(Int $x) {
:             $+result *= $x;
:             fact($x - 1) if $x > 2;
:             return $result;
:         }
:         fact($x);
:     }
: 
: Of course, you can view env variables as implicit parameters.  Given
: that, this function might be able to reduce to:
: 
:     sub factorial(Int $x) {
:         env $+result = 1;   # expecting $+result
:                             # param, default to 1
:         $+result *= $x;
:         fact($x - 1) if $x > 2;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dave Whipp | 3 Feb 2006 21:41

Re: something between "state" and "my"

Larry Wall wrote:

> But that's just my current mental model, which history has shown
> is subject to random tweakage.  And maybe "env $+result" could be a
> special squinting construct that does create-unless-already-created.
> Doesn't feel terribly clean to me though.  If we stick with the +
> twigil always meaning at least one CALLER::, then clarity might be
> better served by
> 
>     env $result := $+result // 1;
> 
> assuming that $+result merely returns undef in the outermost env context.

Wouldn't that bind $result to a constant at the outermost scope -- and 
therefore to that same constant in all inner scopes? If so, then later 
attempts to assign $result would be an error.
Permalink | Reply | 1 comment |
headers
Larry Wall | 3 Feb 2006 22:19
Picon
Gravatar

Re: something between "state" and "my"

On Fri, Feb 03, 2006 at 12:41:47PM -0800, Dave Whipp wrote:
: Larry Wall wrote:
: 
: >But that's just my current mental model, which history has shown
: >is subject to random tweakage.  And maybe "env $+result" could be a
: >special squinting construct that does create-unless-already-created.
: >Doesn't feel terribly clean to me though.  If we stick with the +
: >twigil always meaning at least one CALLER::, then clarity might be
: >better served by
: >
: >    env $result := $+result // 1;
: >
: >assuming that $+result merely returns undef in the outermost env context.
: 
: Wouldn't that bind $result to a constant at the outermost scope -- and 
: therefore to that same constant in all inner scopes? If so, then later 
: attempts to assign $result would be an error.

Hmm, well, it wouldn't work anyway since env variables are readonly
by default outside their "my" scope.  I ought to at least have said

    env $result is rw := $+result // 1;

As for

    my $answer := 42;

I would hope that binding a constant to a rw location is smart enough
to make an anonymous rw copy (or COW).  I think that's what most
existing Perl programmers would expect.  I'm sure a C++ programmer would
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brad Bowman | 5 Feb 2006 02:32

Re: Macros?


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 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 they can be lexically unimported, or whatever the verb is
for what "no" does.

>     As with
>     ordinary operators, macros may be classified by their grammatical
>     category.  For a given grammatical category, a default parsing rule or
>     set of rules is used, but those rules that have not yet been "used"
>     by the time the macro keyword or token is seen can be replaced by
>     use of "is parsed" trait.  (This means, for instance, that an infix
>     operator can change the parse rules for its right operand but not
>     its left operand.)
> 
>     In the absence of a signature to the contrary, a macro is called as
>     if it were a method on the current match object returned from the
>     grammar rule being reduced; that is, all the current parse information
>     is available by treating C<self> as if it were a C<$/> object.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane