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 @{$pairs} = $pair {
say Key: $pair[0];
say Val: $pair[1];
}
Thanks,
Xinming
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 @{$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
Re: Macros?
On Sun, Jan 29, 2006 at 08:13:44PM +, Luke Palmer wrote:
: 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 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
+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.)
+
+A macro is called as if it were a method on the current match object returned
+from the grammar rule being reduced.
+
+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
+original language and know which parts of the derived program come
+from which parts of the user's view of the program.
+
+In aid of returning syntax tree, Perl provides a quasiquoting mechanism
+using the keyword code, followed by a block intended to represent an AST:
+
+return code { say $a };
+
+[Conjecture: Other keywords are possible if we have more than one AST type.]
+
+Within a quasiquote, variable and function names resolve first of all
+according to the lexical scope of the macro definition, and if unrecognized in
+that scope, are assumed to be bound from the scope of the macro call
+each time it is called. If they cannot be bound from the scope of
+the macro call, a compile-time exception is thrown.
+
+Variables that resolve from the lexical scope of the macro definition
+will be inserted appropriately depending on the type of the variable,
+which may be either a syntax tree or a string. (Again, syntax tree
+is preferred.) The case is similar to that of a macro called from
+within the quasiquote, insofar as reparsing only happens with the
+string version of interpolation, except that such a reparse happens at
+macro call time rather than macro definition time, so its result cannot
+change the parsers expections about what follows the interpolated variable.
+
+Hence, while the quasiquote itself is being parsed, the syntactic
+interpolation of a variable into the quasiquote always results in
+the expectation of an operator following the variable. (You must
+use a call to a submacro if you want to expect something else.)
+Of course, the macro definition as a whole can expect whatever it
+likes afterwards, according to its syntactic category. (Generally,
+a term expects a following postfix or infix operator, and an operator
+expects a following term or prefix operator.)
+
+In case of name ambiguity, prefix with CCOMPILING:: to indicate a name in
+the compiling scope, and COUTER:: to indicate a name in the macro
definition's
+scope.
+
+[Conjecture: Due to these dwimmy scoping rules, there is no need of
+a special unquote construct as in Scheme et al.]
Larry
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 Cself 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
original language and know which parts of the derived program come
from which parts of the user's view of the program.
In aid of returning syntax tree, Perl provides a quasiquoting
mechanism using the keyword CODE, followed by a block intended to
represent an AST:
return CODE { say $a };
[Conjecture: Other keywords are possible if we have more than one
AST type.]
Within a quasiquote, variable and function names resolve first of
all according to the lexical scope of the macro definition, and if
unrecognized in that scope, are assumed to be bound from the scope
of the macro call each time it is called. If they cannot be bound
from the scope of the macro call, a compile-time exception is thrown.
Variables that resolve from the lexical scope of the macro definition
will be inserted appropriately depending on the type of the variable,
which may be either a syntax tree or a string. (Again, syntax tree
is preferred.) The case is similar to that of a macro called from
within the quasiquote, insofar as reparsing only happens with the
string version of interpolation, except that such a reparse happens
at macro call time rather than macro definition time, so its result
cannot change the parser's expectations about what follows the
interpolated variable.
Hence, while the quasiquote itself is being parsed, the syntactic
interpolation of a variable into the quasiquote always results in
the expectation of an operator following the variable. (You must
use a call to a submacro if you want to expect something else.)
Of course, the macro definition as a whole can expect whatever it
likes afterwards, according to its syntactic category. (Generally,
a term expects a following postfix or infix operator, and an operator
expects a following term or prefix operator.)
In case of name ambiguity, prefix with CCOMPILING:: to indicate a
name in the compiling scope, and anything else (such as COUTER::)
to indicate a name in the macro definition's scope, since that's the
default. In particular, any variable declared within the quasiquote
block is assumed to scope to the quasiquote; to scope the declaration
to the macro call's scope, you must say
my COMPILING::$foo = 123;
env COMPILING::@bar = ();
our COMPILING::%baz;
or some such if you wish to force the compiler to install the variable
into the symbol table being constructed by the macro call.
[Conjecture: Due to these dwimmy scoping rules, there is no need of
a special unquote construct as in Scheme et al.]
Larry
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
function, except that it doesn't use call-stack semantics to maintain
its state. (I know P6 will do tail recursion, but sometimes I find
myself building complex args/return values to pass state from one
iteration to the next.)
Equivalent code without this feature is:
sub factorial(Int $x) {
my Int $result = 1;
my sub fact1(Int $x) {
$result *= $x;
fact1 $x-1 if $x 2;
}
fact1 $x
return $result;
}
Dave.
Re: something between state and my
On 2/3/06, Dave Whipp [EMAIL PROTECTED] 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;
}
Luke
