Re: Adverbs
Larry Wall wrote:
> You might have to write that
>
>@list ==> $foo.act :bar('baz');
>
> I think or the colon on the method would be taken as starting a list.
> I dunno, depends on whether .act: is considered a "longest token",
> I guess. I could argue it the other way as well, and :bar is a longest
> token compared to :.
Eh? What's this bit about lists and colons? (This is one of the
things that worries me about Perl 6: there seem to be all sorts of
"edge cases" which crop up at the most unexpected times.)
--
Jonathan "Dataweaver" Lang
Re: Adverbs
One other point: act $foo, @list, bar => 'baz'; is actually the same as: act($foo, @list, bar => 'baz'); which might or might not dispatch to a method on $foo, depending on whether (and how) &act is defined. Jonathan probably meant: act $foo: @list, bar => 'baz'; for the indirect object syntax. Damian
Re: Adverbs
On Mon, Apr 24, 2006 at 08:30:04PM -0700, Jonathan Lang wrote:
: Larry Wall wrote:
: > Jonathan Lang wrote:
: > : How do you define new adverbs, and how does a subroutine go about
: > : accessing them?
: >
: > Adverbs are just optional named parameters. Most of the magic is in
: > the call syntax.
:
: Ah. So every part of a Capture Object has an alternate call syntax:
:
: act $foo, @list, bar => 'baz';
:
: is the same as
:
: @list ==> $foo.act:bar('baz');
:
: right?
You might have to write that
@list ==> $foo.act :bar('baz');
I think or the colon on the method would be taken as starting a list.
I dunno, depends on whether .act: is considered a "longest token",
I guess. I could argue it the other way as well, and :bar is a longest
token compared to :.
: (And if this is the case, the one capability that the adverb notation
: provides that the more traditional named parameter notation doesn't
: have is a way to let a particular key to exist without being defined.)
Without being specified, anyway. The default values are always defined.
Larry
Re: Adverbs
Larry Wall wrote:
> Jonathan Lang wrote:
> : How do you define new adverbs, and how does a subroutine go about
> : accessing them?
>
> Adverbs are just optional named parameters. Most of the magic is in
> the call syntax.
Ah. So every part of a Capture Object has an alternate call syntax:
act $foo, @list, bar => 'baz';
is the same as
@list ==> $foo.act:bar('baz');
right?
(And if this is the case, the one capability that the adverb notation
provides that the more traditional named parameter notation doesn't
have is a way to let a particular key to exist without being defined.)
--
Jonathan "Dataweaver" Lang
[svn:perl6-synopsis] r8935 - doc/trunk/design/syn
Author: larry
Date: Mon Apr 24 19:38:40 2006
New Revision: 8935
Modified:
doc/trunk/design/syn/S02.pod
Log:
Clarifications on adverbs.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podMon Apr 24 19:38:40 2006
@@ -14,7 +14,7 @@
Date: 10 Aug 2004
Last Modified: 24 Apr 2006
Number: 2
- Version: 31
+ Version: 32
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -1187,9 +1187,8 @@
=item *
-There is now a generalized adverbial form of Pair notation:
-
-The following table shows the correspondence:
+There is now a generalized adverbial form of Pair notation. The
+following table shows the correspondence to the "fatarrow" notation:
Fat arrow Adverbial pair
= ==
@@ -1215,8 +1214,12 @@
turns into C<('a')> rather than C<('a',)>.
Two or more adverbs can always be strung together without intervening
-punctuation anywhere a single adverb is acceptable. When used as named
-arguments, you may put comma between. See S06.
+punctuation anywhere a single adverb is acceptable. When used as
+named arguments in an argument list, you may put comma between,
+because they're just ordinary named arguments to the function, and
+a fatarrow pair would work the same. When modifying an operator
+(that is, when one occurs where an operator is expected), you may
+not put commas between, and the fatarrow form is not allowd. See S06.
The negated form (C<:!a>) and the sigiled forms (C<:$a>, C<:@a>,
C<:%a>) never take an argument and don't care what the next character is.
@@ -1224,11 +1227,19 @@
The other forms of adverb (including the bare C<:a> form) I
look for an immediate bracketed argument, and will slurp it up.
-If that's not intended, you must use whitespace between the adverb
-and the opening bracket.
-
-Despite not being a subscript, the brackets are parsed as postfix operators,
-and may be separated from their C<:foo> with dot or "long dot".
+If that's not intended, you must use whitespace between the adverb and
+the opening bracket. The syntax of individual adverbs is the same
+everywhere in Perl 6. There are no exceptions based on whether an
+argument is wanted or not. Except as noted above, the parser always
+looks for the brackets. Despite not indicating a true subscript,
+the brackets are similarly parsed as postfix operators. As postfixes
+the brackets may be separated from their initial C<:foo> with either
+dot or "long dot", but nothing else.
+
+Regardless of syntax, adverbs used as named arguments generally show
+up as optional named parameters to the function in question--even
+if the function is an operator or macro. The function in question
+neither knows nor cares how weird the original syntax was.
=item *
Re: Adverbs
On Mon, Apr 24, 2006 at 06:58:04PM -0700, Jonathan Lang wrote: : How do you define new adverbs, and how does a subroutine go about : accessing them? Adverbs are just optional named parameters. Most of the magic is in the call syntax. Larry
Adverbs
How do you define new adverbs, and how does a subroutine go about accessing them? -- Jonathan Lang
Re: S05: Interpolated hashes?
On Mon, Apr 24, 2006 at 08:00:55AM -0700, Larry Wall wrote:
: If you want to reset to before the key for some reason, you can always
: set .pos to $.beg, or whatever the name of the method is. Hmm,
: that looks like it's unspecced.
I'm wrong, it's already specced as .from and .to methods. So you can write
mytoken => rule { :pos($.from) ... }
to start parsing from the beginning of the key. (Optional arg to
:pos and :continue just added to S05, by the way.)
Larry
[svn:perl6-synopsis] r8934 - doc/trunk/design/syn
Author: larry Date: Mon Apr 24 17:55:46 2006 New Revision: 8934 Modified: doc/trunk/design/syn/S05.pod Log: Random cleanup. Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podMon Apr 24 17:55:46 2006 @@ -14,9 +14,9 @@ Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and Larry Wall <[EMAIL PROTECTED]> Date: 24 Jun 2002 - Last Modified: 22 Apr 2006 + Last Modified: 24 Apr 2006 Number: 5 - Version: 22 + Version: 23 This document summarizes Apocalypse 5, which is about the new regex syntax. We now try to call them I because they haven't been @@ -117,6 +117,11 @@ location. (Use C<:p> for that.) The pattern you supply to C has an implicit C<:c> modifier. +The C<:continue> modifier takes an optional argument of type C +which specifies the point at which to start scanning for a match. +This should not be used unless you know what you're doing, or just +happen to like hard-to-debug infinite loops. + =item * The C<:p> (or C<:pos>) modifier causes the pattern to try to match only at @@ -140,6 +145,10 @@ Also note that any regex called as a subrule is implicitly anchored to the current position anyway. +The C<:pos> modifier takes an optional argument of type C +which specifies the point at which to attempt a match. This should not +be used lightly. Put it in the category of a "goto". + =item * The new C<:w> (C<:words>) modifier causes whitespace sequences to be @@ -502,7 +511,7 @@ / \Q$var\E / -However, if C<$var> contains a Regex object, instead of attempting to +However, if C<$var> contains a C object, instead of attempting to convert it to a string, it is called as a subrule, as if you said C<< <$var> >>. (See assertions below.) This form does not capture, and it fails if C<$var> is tainted. @@ -519,7 +528,7 @@ As with a scalar variable, each element is matched as a literal -unless it happens to be a Regex object, in which case it is matched +unless it happens to be a C object, in which case it is matched as a subrule. As with scalar subrules, a tainted subrule always fails. All values pay attention to the current C<:ignorecase> setting. @@ -544,9 +553,10 @@ =item * -If it is a Regex object, it is executed as a subrule, with an initial -position I the matched key. As with scalar subrules, a tainted -subrule always fails, and no capture is attempted. +If it is a C object, it is executed as a subrule, with an +initial position I the matched key. (This is further described +below under the C<< <%hash> >> notation.) As with scalar subrules, +a tainted subrule always fails, and no capture is attempted. =item * @@ -595,9 +605,11 @@ / / # was /(? /# match whitespace by :w policy - / /# match a space char + / / # match only at a particular StrPos +# short for + The C assertion implements lookbehind by reversing the syntax tree and looking for things in the opposite order going to the left. It is illegal to do lookbehind on a pattern that cannot be reversed. @@ -621,7 +633,7 @@ =item * A leading C<$> indicates an indirect subrule. The variable must contain -either a Regex object, or a string to be compiled as the regex. The +either a C object, or a string to be compiled as the regex. The string is never matched literally. By default C<< <$foo> >> is captured into C<< $ >>, but you can @@ -643,9 +655,9 @@ =item * A leading C<@> matches like a bare array except that each element is -treated as a subrule (string or Regex object) rather than as a literal. +treated as a subrule (string or C object) rather than as a literal. That is, a string is forced to be compiled as a subrule instead of being -matched literally. (There is no difference for a Regex object.) +matched literally. (There is no difference for a C object.) By default C<< <@foo> >> is captured into C<< $ >>, but you can use the C<< <[EMAIL PROTECTED]> >> form to suppress capture, and you can always say @@ -727,7 +739,7 @@ =item * In any case of regex interpolation, if the value already happens to be -a Regex object, it is not recompiled. If it is a string, the compiled +a C object, it is not recompiled. If it is a string, the compiled form is cached with the string so that it is not recompiled next time you use it unless the string changes. (Any external lexical variable names must be rebound each time though.) Subrules may not be @@ -864,26 +876,7 @@ The C<\G> sequence is gone. Use C<:p> instead. (Note, however, that it makes no sense to use C<:p> within a pattern, since every internal pattern is implicitly anchored to the current position.) -To anchor to a particular position in the general case you can use -the C<< >> assertion to say that the current position -is the sa
Re: Smoke [5.9.4] 27938 FAIL(X) linux 2.6.15-20-386 [debian] (i686/1 cpu)
Op een mooie winterdag (Sunday 23 April 2006 17:30),schreef Steve Peters: > [EMAIL PROTECTED] wrote: > > Automated smoke report for 5.9.4 patch 27938 > > kirk: Intel(R) Celeron(R) CPU 2.00GHz (GenuineIntel 1994MHz) (i686/1 cpu) > > onlinux - 2.6.15-20-386 [debian] > > using cc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) > > smoketime 17 hours 54 minutes (average 1 hour 7 minutes) > > > > Summary: FAIL(X) [snip] > > [perlio] -DDEBUGGING -Duseithreads -Duselongdouble > > Inconsistent test results (between TEST and harness): > > ../ext/threads/t/free.t.FAILED--expected test 15, saw > > test 16 > > What's happening above is that TEST cannot handle seeing tests come in > out of order, while harness can. I'm scanning Test::Harness::TAP a bit, > but it seems to be unspecified whether this is OK or not. Should TEST > care if the tests are reported out of order? Windows makefiles don't have a "test_harness:" target and the test/test-notty/ _test targets all use harness, so no need to blame TEST. I will raise the question once again "Why don't we use TEST on mswin32?". (I should probably change that message for mswin32 while Test::Smoke is using harness for both runs) Good luck, Abe -- I admit that there was too much waving the chicken and too little looking at the chicken's genome in that change. -- Jarkko Hietaniemi on p5p @ 2003-08-11
Re: [perl #37850] [BUG] tcl build trouble on win32
On 4/22/06, Will Coleda via RT <[EMAIL PROTECTED]> wrote: > This issue is long dead, isn't it? > this has been fixed some time ago, yes. however, tcl's not building for me right now for a different reason... link -nologo -nodefaultlib -debug -dll -out:tcl_group.dll "lib-tcl_group.obj" "tclobject.obj" "tclstring.obj" "tclint.obj" "tclfloat.obj" "tcllist.obj" "tclarray.obj" oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib "D:/usr/local/parrot/bug/libparrot.lib" Creating library tcl_group.lib and object tcl_group.exp tcllist.obj : error LNK2019: unresolved external symbol _interpinfo_p referenced in function _Parrot_TclList_get_string tcl_group.dll : fatal error LNK1120: 1 unresolved externals partial link tcl_group.dll failed (24576) NMAKE : fatal error U1077: 'cd' : return code '0x2' ~jerry
[perl #38969] parrot source does not conform to standards
# New Ticket Created by jerry gay # Please include the string: [perl #38969] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38969 > running `per tools/dev/check_source_standards.pl` is disheartening, as there are thousands upon thousands of source standards exceptions. this is likely a combination of three things: 1) the standards (docs/pdds/clip/pdd07_codingstd.pod) is out-of-date wrt reality 2) the script is out-of-date wrt standards 3) the parrot coders are *really* sloppy wrt standards, or are not paying careful attention to them there are a few things that must be done to address this: 1) make sure the standards reflect reality addressed by the design team, by reviewing and approving the coding standard doc 2) make sure the script reflects the standards this can be fixed by anybody who can read english and C, and write perl 3) make sure parrot coders are mindful of the standard this can be fixed by running this script regularly, and generating an RT ticket with the results. svn can subsequently be used to blame the committers at fault :) ~jerry
Re: S05: Interpolated hashes?
On 4/24/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> If you want to reset to before the key for some reason, you can always
> set .pos to $.beg, or whatever the name of the method is. Hmm,
> that looks like it's unspecced.
>
BEGIN
.beg looks over-huffmanized to me. .begin is more natural to
english-speaking programmers, who have been using begin and end for
decades. if .beg will be used as .end's pair, i suggest this be kept
consistent, and BEGIN{} blocks be renamed as well.
BEGging the compiler to execute a block first is a mnemonic device,
but it doesn't work with the first example.
END
~jerry
Re: [PATCH] Re: What version of perl is required?
On 4/24/06, Andy Dougherty <[EMAIL PROTECTED]> wrote: > The patch included below changes lib/Parrot/Revision.pm and > lib/Parrot/Distribution.pm back to 5.006, and appears to be > the minimal change needed to get back to building with perl-5.6.x. > i'm of the "don't repeat yourself" camp, so as of r12404, the 'use version' lines have been removed entirely from lib/Parrot/*, and 'use 5.006;' is specified only in Configure.pl. > Looking further, the following files still require 5.008: > > ./languages/m4/lib/Parrot/Test/M4/Gnu.pm:use 5.008; > ./languages/m4/lib/Parrot/Test/M4/PIR.pm:use 5.008; > ./languages/m4/lib/Parrot/Test/M4.pm:use 5.008; > ./languages/m4/tools/scrutinize.pl:use 5.008; > > I haven't looked in languages/m4 for a long time, so I don't have > any useful comment on those. > i'll leave languages/* files up to their authors for now. > ./lib/Pod/Simple/TranscodeSmart.pm:use 5.008; > > This contains the singularly unhelpful comment: > > ## Anything before 5.8.0 is GIMPY! > > I have no idea what that was intended to mean. > uggh. (external dependencies)-- this will need to be followed up on outside the commits i've just made. > ./t/codingstd/cppcomments.t:use 5.008; > > Offhand, I don't see why ./t/codingstd/cppcomments.t really needs > 5.008, but I haven't had time check it out carefully. > it's not needed. fixed in r12410. > ./tools/dev/check_source_standards.pl:use 5.008; > ./tools/dev/mk_manifest_and_skip.pl:use 5.008; > > These are developer tools; their requirements needn't be the same as those > required for ordinary users to build parrot. > true, but fixed in r12414 anyway. > As before, I have no strong opinion on which version to use, but the main > parrot README certainly ought to reflect reality. > that seems to be fixed already. unless andy has missed anything, or i have fixed it improperly, the only remaining issues related to perl minimum version requirements are languages/ and external libraries, as of 12414. ~jerry
Re: S05: Interpolated hashes?
On Mon, Apr 24, 2006 at 05:22:25PM +0100, [EMAIL PROTECTED] wrote:
: Why don't we just have work as an assertation, instead of having this
: strange "as if" thing?
'Cause the point of most parsing is to rapidly move on, not to rehash the
ground you already covered. And if you really do need to reparse, you
need to set the position *anyway*, so $.beg works fine for that,
and $ itself works fine for retraversing the key if you need to.
In fact, that's true in either direction, so you can negatively traverse
$ in reverse within a lookbehind:
token macro_only_after_foo ($isparsed) {
< $ >> <$isparsed>
}
Larry
[perl #38967] Parrot 0.5.0
# New Ticket Created by Will Coleda # Please include the string: [perl #38967] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38967 > Placeholder (milestone) for the Parrot 0.5.0 release.
[svn:perl6-synopsis] r8933 - doc/trunk/design/syn
Author: larry
Date: Mon Apr 24 11:19:24 2006
New Revision: 8933
Modified:
doc/trunk/design/syn/S02.pod
Log:
Clarification requested by spinclad++.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podMon Apr 24 11:19:24 2006
@@ -14,7 +14,7 @@
Date: 10 Aug 2004
Last Modified: 24 Apr 2006
Number: 2
- Version: 30
+ Version: 31
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -371,7 +371,7 @@
system of type declarations. C automatically supports promotion
to arbitrary precision, as well as holding C and C values.
-(C may support arbitrary-precision floating-point arithmatic, but
+(C may support arbitrary-precision floating-point arithmetic, but
is not required to unless we can do so portably and efficiently.)
C supports arbitrary precision rational arithmetic. However,
@@ -1215,7 +1215,7 @@
turns into C<('a')> rather than C<('a',)>.
Two or more adverbs can always be strung together without intervening
-punctuation anywhere a single adverb is acceptible. When used as named
+punctuation anywhere a single adverb is acceptable. When used as named
arguments, you may put comma between. See S06.
The negated form (C<:!a>) and the sigiled forms (C<:$a>, C<:@a>,
@@ -1532,7 +1532,7 @@
(and other type names) are predeclared, or prefixed with the C<::>
type sigil when you're declaring a new one.) A consequence of this
is that there's no longer any "C". Since the syntax
-for method calls is distinguished from sub calls, it is only unreconized
+for method calls is distinguished from sub calls, it is only unrecognized
sub calls that must be treated specially.
You still must declare your subroutines, but an unrecognized bare
@@ -1588,14 +1588,25 @@
foo bar 1 # foo(bar(1)) -- both subject to postdeclaration
-- never taken as indirect object
foo $bar: 1# $bar.foo(1) -- indirect object even if
declared sub
-foo bar(): # bar().foo(1) -- even if foo declared sub
-foo bar baz: 1 # foo(bar baz: 1) -- colon controls "bar", not foo.
+ -- $bar considered one token
+foo (bar()): # bar().foo(1) -- even if foo declared sub
+foo bar(): # illegal -- bar() is two tokens.
+foo .bar: # foo(.bar:)-- colon chooses .bar to listopify
+foo bar baz: 1 # foo(baz.bar(1)) -- colon controls "bar", not foo.
foo (bar baz): 1 # bar(baz()).foo(1) -- colon controls "foo"
$foo $bar # illegal -- two terms in a row
$foo $bar: # illegal -- use $bar.$foo for indirection
(foo bar) baz: 1 # illegal -- use $baz.$(foo bar) for indirection
-Parens are required around any indirect object that would be ambiguous.
+The indirect object colon only ever dominates a simple term, where
+"simple" includes classes and variables and parenthesized expressions,
+but explicitly not method calls, because the colon will bind to a
+trailing method call in preference. An indirect object that parses
+as more than one token must be placed in parentheses, followed by
+the colon. In short, only an identifier followed by a simple term
+followed by a postfix colon is C parsed as an indirect object,
+but that form will C be parsed as an indirect object regardless
+of whether the identifier is otherwise declared.
=item *
[perl #38968] Parrot 0.4.4
# New Ticket Created by Will Coleda # Please include the string: [perl #38968] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38968 > Placeholder (milestone) for the Parrot 0.4.4 release.
[PATCH] Re: What version of perl is required?
On Sun, 23 Apr 2006, Bernhard Schmalhofer wrote: > Will Coleda schrieb: > > > This change was made here: > > > > r11744 | bernhard | 2006-02-26 05:55:39 -0500 (Sun, 26 Feb 2006) | 7 lines > > > > Bernhard, was the upgrade to 5.8 intentional and necessary? > > In February I was fairly sure that Perl 5.8.0 was already required. But I must > have mixed that up > as I can't find that mentioned on p6i. > > The reason for making an explicit check was that I didn't recall whether > 'our' was introduced in 5.6.0 or 5.8.0. As 'our' was introduced in 5.6.0, > I have lowered the requirements for Configure.pl to 5.006. Thanks, but, alas, it now fails at Determining whether ICU is installedno.Perl v5.8.0 required--this is only v5.6.2, stopped at lib/Parrot/Revision.pm line 25. The patch included below changes lib/Parrot/Revision.pm and lib/Parrot/Distribution.pm back to 5.006, and appears to be the minimal change needed to get back to building with perl-5.6.x. Looking further, the following files still require 5.008: ./languages/m4/lib/Parrot/Test/M4/Gnu.pm:use 5.008; ./languages/m4/lib/Parrot/Test/M4/PIR.pm:use 5.008; ./languages/m4/lib/Parrot/Test/M4.pm:use 5.008; ./languages/m4/tools/scrutinize.pl:use 5.008; I haven't looked in languages/m4 for a long time, so I don't have any useful comment on those. ./lib/Pod/Simple/TranscodeSmart.pm:use 5.008; This contains the singularly unhelpful comment: ## Anything before 5.8.0 is GIMPY! I have no idea what that was intended to mean. ./t/codingstd/cppcomments.t:use 5.008; Offhand, I don't see why ./t/codingstd/cppcomments.t really needs 5.008, but I haven't had time check it out carefully. ./tools/dev/check_source_standards.pl:use 5.008; ./tools/dev/mk_manifest_and_skip.pl:use 5.008; These are developer tools; their requirements needn't be the same as those required for ordinary users to build parrot. As before, I have no strong opinion on which version to use, but the main parrot README certainly ought to reflect reality. diff -r -u parrot-current/lib/Parrot/Distribution.pm parrot-andy/lib/Parrot/Distribution.pm --- parrot-current/lib/Parrot/Distribution.pm Tue Mar 14 19:15:06 2006 +++ parrot-andy/lib/Parrot/Distribution.pm Mon Apr 24 12:07:49 2006 @@ -31,7 +31,7 @@ use strict; use warnings; -use 5.008; +use 5.006; use Data::Dumper; use ExtUtils::Manifest; diff -r -u parrot-current/lib/Parrot/Revision.pm parrot-andy/lib/Parrot/Revision.pm --- parrot-current/lib/Parrot/Revision.pm Sat Mar 4 19:15:04 2006 +++ parrot-andy/lib/Parrot/Revision.pm Mon Apr 24 12:07:43 2006 @@ -22,7 +22,7 @@ use strict; use warnings; -use 5.008; +use 5.006; our $svn_entries = undef; -- Andy Dougherty [EMAIL PROTECTED]
Re: S05: Interpolated hashes?
On Mon, Apr 24, 2006 at 08:00:55AM -0700, Larry Wall wrote: > On Mon, Apr 24, 2006 at 09:49:36AM -0500, Jonathan Scott Duff wrote: > : But what if your subrule needs to know exactly which key matched or > : needs to match the key again for some reason? The second passage says > : that you may access they actual text that matched with $ and you > : may again match the actual key that matched with the assertion. > > Close, but that last bit isn't quite true. If you read the passage > again carefully, you'll note the magic words "as if". There is no > actual assertion, only the remaining smile, like a Cheshire cat. > If you want to reset to before the key for some reason, you can always > set .pos to $.beg, or whatever the name of the method is. Hmm, > that looks like it's unspecced. Why don't we just have work as an assertation, instead of having this strange "as if" thing? -=- James Mastros, theorbtwo
Re: S05: Interpolated hashes?
Thanks, Scott & Larry. IMHO, the explanation about and $ could be moved to where the bare hash behaviour is explained as hash-in-angles-section already says "A leading % matches like a bare hash except ..." On 4/24/06, Larry Wall <[EMAIL PROTECTED]> wrote: > If you want to reset to before the key for some reason, you can always > set .pos to $.beg, or whatever the name of the method is. Hmm, > that looks like it's unspecced. This seems interesting. From day-to-day it becames harder to fully understand this perl6 thing, but I like it :) -- Markus Laire
[svn:perl6-synopsis] r8931 - doc/trunk/design/syn
Author: larry Date: Mon Apr 24 08:18:48 2006 New Revision: 8931 Modified: doc/trunk/design/syn/S02.pod Log: A postdeclaration may not change the syntax away from listop parsing rules. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podMon Apr 24 08:18:48 2006 @@ -1552,6 +1552,10 @@ since that's a run-time dispatch, and all multis are effectively visible at the point of the controlling C declaration. +Parsing of a provisional call is always done the same way list operators +are treated. If a postdeclaration bends the syntax to be inconsistent +with that, it is an error of the inconsistent signature variety. + If the unrecogized subname is followed by C<< postcircumfix:<( )> >>, it is compiled as a provisional function call of the parenthesized form. If it is not, it is compiled as a provisional function call of
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Monday 24 April 2006 07:56, Michael Peters wrote: > Not only would this make it easier to have a harness look for something > other than TAP (maybe some other protocol from some other language) but > it also means I can parse test runs after they've been run on a > completely different machine even. Ian and I wrote about this in the Perl Testing book. I don't see the sample code online for some reason, but it's in chapter 3. -- c
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
Shlomi Fish wrote: > On Monday 24 April 2006 01:46, Michael Peters wrote: >> Shlomi Fish wrote: >>> On Sunday 23 April 2006 22:35, chromatic wrote: On Sunday 23 April 2006 12:05, Shlomi Fish wrote: > This debate demonstrates why a plugin system is necessary for a test > harness. No, it demonstrates why a well-defined test output protocol is useful. >>> I agree that a well-defined test output protocol is useful. However, are >>> you implying that assuming we have that, one can write several different >>> test harnesses to process such test outputs? (I'm just guessing.) >>> >>> Wouldn't that imply duplicate code, duplicate functionality and/or >>> duplicate effort? Shouldn't we try to avoid that by making sure that we >>> have one *good* test harness codebase that can be customised using >>> plug-ins, and extensions? >> How about a good TAP parser module that does nothing but parse TAP. Then >> it could be used in all kinds of test harness permutations. > > Am I missing something or isn't that what > Test::Harness:Straps/Test::Run::Straps are for? If not, I suppose I can > extract a class out of Test::Run::Straps that will provide a reusable TAP > parser. It's close, but it's still a test harness first and foremost (even though it's pretty easy to subclass). If you extract out the TAP parsing portion into a separate module I think we'd be in good shape. It can be extremely useful to have the TAP parsing and test running separated out. Not only would this make it easier to have a harness look for something other than TAP (maybe some other protocol from some other language) but it also means I can parse test runs after they've been run on a completely different machine even. -- Michael Peters Developer Plus Three, LP
Re: S05: Interpolated hashes?
On Mon, Apr 24, 2006 at 09:49:36AM -0500, Jonathan Scott Duff wrote: : But what if your subrule needs to know exactly which key matched or : needs to match the key again for some reason? The second passage says : that you may access they actual text that matched with $ and you : may again match the actual key that matched with the assertion. Close, but that last bit isn't quite true. If you read the passage again carefully, you'll note the magic words "as if". There is no actual assertion, only the remaining smile, like a Cheshire cat. If you want to reset to before the key for some reason, you can always set .pos to $.beg, or whatever the name of the method is. Hmm, that looks like it's unspecced. Larry
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Monday 24 April 2006 01:46, Michael Peters wrote: > Shlomi Fish wrote: > > On Sunday 23 April 2006 22:35, chromatic wrote: > >> On Sunday 23 April 2006 12:05, Shlomi Fish wrote: > >>> This debate demonstrates why a plugin system is necessary for a test > >>> harness. > >> > >> No, it demonstrates why a well-defined test output protocol is useful. > > > > I agree that a well-defined test output protocol is useful. However, are > > you implying that assuming we have that, one can write several different > > test harnesses to process such test outputs? (I'm just guessing.) > > > > Wouldn't that imply duplicate code, duplicate functionality and/or > > duplicate effort? Shouldn't we try to avoid that by making sure that we > > have one *good* test harness codebase that can be customised using > > plug-ins, and extensions? > > How about a good TAP parser module that does nothing but parse TAP. Then > it could be used in all kinds of test harness permutations. Am I missing something or isn't that what Test::Harness:Straps/Test::Run::Straps are for? If not, I suppose I can extract a class out of Test::Run::Straps that will provide a reusable TAP parser. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: S05: Interpolated hashes?
On Mon, Apr 24, 2006 at 04:50:43PM +0300, Markus Laire wrote: > In Synopsis 5 (version 22), > > Under "Variable (non-)interpolation" it's said that > > An interpolated hash matches the longest possible key of the hash as a > literal, or fails if no key matches. (A "" key will match anywhere, > provided no longer key matches.) > > > And under "Extensible metasyntax (<...>)" it's said that > > With both bare hash and hash in angles, the key is counted as > "matched" immediately; that is, the current match position is set to > after the key token before calling any subrule in the value. That > subrule may, however, magically access the key anyway as if the > subrule had started before the key and matched with assertion. > That is, $ will contain the keyword or token that this subrule > was looked up under, and that value will be returned by the current > match object even if you do nothing special with it within the match. > > > I don't quite understand how these relate to each other. First text is > clear enough, but second seems to be something totally different. Indeed, they are saying different things about what happens when you match a hash against a string. > Could someone give an example of what difference there's between > "interpolated hash matches the longest possible key of the hash as a > literal, or fails if no key matches." and "the key is counted as > "matched" immediately; that is, the current match position is set to > after the key token before calling any subrule in the value. ..." > > I don't quite understand if the key is matched in the second version > or if it's just counted as "matched", whatever that means, and why the > description is so dis-similar to the first quote. What those two passages are saying is that when you match with a hash, the longest key that matches will trigger the value portion of the hash to execute (what "execute" means depends on the nature of the value. See S05 for more details) Given, for example, the following: my %hash = ( 'foo'=> ..., 'food' => ..., ); "I need some food for breakfast" ~~ /%hash/; That first passage says that "food" must match since it's the longest key that matches, so whatever the ... for the "food" key is will execute. The second passage says that the "match cursor" is placed just after the key that matched. So any subsequent matches to that string that do not reset the cursor will start just after the word "food". But what if your subrule needs to know exactly which key matched or needs to match the key again for some reason? The second passage says that you may access they actual text that matched with $ and you may again match the actual key that matched with the assertion. In my example, $ will contain the text "food" . Also, by using the assertion, you can start matching at the beginning of the key (rather than just after it) and again match the same key of the hash that caused the match to succeed in the first place. Why would you need to match the key again? Maybe your subrule needs to know what came before the key in order to perform some action: req() if m:c/ / # require des() if m:c/ / # desire I assume that is somehow magically anchored to the spot where the key actually matched. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
S05: Interpolated hashes?
In Synopsis 5 (version 22), Under "Variable (non-)interpolation" it's said that An interpolated hash matches the longest possible key of the hash as a literal, or fails if no key matches. (A "" key will match anywhere, provided no longer key matches.) And under "Extensible metasyntax (<...>)" it's said that With both bare hash and hash in angles, the key is counted as "matched" immediately; that is, the current match position is set to after the key token before calling any subrule in the value. That subrule may, however, magically access the key anyway as if the subrule had started before the key and matched with assertion. That is, $ will contain the keyword or token that this subrule was looked up under, and that value will be returned by the current match object even if you do nothing special with it within the match. I don't quite understand how these relate to each other. First text is clear enough, but second seems to be something totally different. Could someone give an example of what difference there's between "interpolated hash matches the longest possible key of the hash as a literal, or fails if no key matches." and "the key is counted as "matched" immediately; that is, the current match position is set to after the key token before calling any subrule in the value. ..." I don't quite understand if the key is matched in the second version or if it's just counted as "matched", whatever that means, and why the description is so dis-similar to the first quote. -- Markus Laire
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On 23 Apr 2006, at 20:05, Shlomi Fish wrote: [snip] This debate demonstrates why a plugin system is necessary for a test harness. If it has it, then one can write a plugin to control whether or not percentages are displayed. So for example, you can install a plugin that does that, and put this in your .bash_profile: [snip] That's not the issue for me. I can already write my own test runners without too much effort. For me the issue is why we're removing a useful (to a few people anyway), already implemented feature from the default test runner. Although I agree with Michael and chromatic that a separate TAP parser would be most pleasant. Cheers, Adrian
Re: Smoke [5.9.4] 27938 FAIL(X) linux 2.6.15-20-386 [debian] (i686/1 cpu)
On 4/24/06, Abe Timmerman <[EMAIL PROTECTED]> wrote: > I will raise the question once again "Why don't we use TEST on mswin32?". Interesting question, especially in light of the fact that TEST doesnt seem to have any obvious Win32 no-no's, and in fact has Win32 specific support, so presumably somebody has at some point been using it. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
Andy Lester wrote: > I'm approaching the end of this release cycle. I really want to get > this released. > > I've removed the meaningless percentages of tests that have failed. > If you rely on the output at the end, it's different now. I'm not attached to percentages, which I wasn't looking at anyway, but when several tests fail, the header is repeated for each test. Failed Test Stat Wstat Total Fail List of Failed ---
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
Michael Peters wrote: Shlomi Fish wrote: On Sunday 23 April 2006 22:35, chromatic wrote: On Sunday 23 April 2006 12:05, Shlomi Fish wrote: This debate demonstrates why a plugin system is necessary for a test harness. No, it demonstrates why a well-defined test output protocol is useful. I agree that a well-defined test output protocol is useful. However, are you implying that assuming we have that, one can write several different test harnesses to process such test outputs? (I'm just guessing.) Wouldn't that imply duplicate code, duplicate functionality and/or duplicate effort? Shouldn't we try to avoid that by making sure that we have one *good* test harness codebase that can be customised using plug-ins, and extensions? How about a good TAP parser module that does nothing but parse TAP. Then it could be used in all kinds of test harness permutations. And of course, we also need TAP::SAX :) Sort of a funny, but it probably should be written, since SAX is a nice standardised event model with plenty of existing code. (hence Perl::SAX and Pod::SAX et al). Adam K
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
chromatic wrote: On Sunday 23 April 2006 15:46, Michael Peters wrote: How about a good TAP parser module that does nothing but parse TAP. Then it could be used in all kinds of test harness permutations. That's exactly what I want and precisely why I think a well-defined TAP is more important than a plugin system for any particular harness. Hear hear. Personally, I don't even WANT the harness output, or even the harness (or at least, the result tracking functionality), I just want to run the tests, capture the TAP and then deal with it on an as-needed basis elsewhere. Adam K
Re: What version of perl is required?
Bernhard Schmalhofer wrote: Will Coleda schrieb: There was an agreement on 5.6.1 a few weeks back on IRC, if I recall correctly, I haven't heard anything about 5.8. This change was made here: r11744 | bernhard | 2006-02-26 05:55:39 -0500 (Sun, 26 Feb 2006) | 7 lines Configuration: - Sprinkle a few 'use warnings;' - Some code beautification - Explicit use of Parrot::BuildUtil::parrot_version() - Use the 'our' syntax in Configure.pl - $description in the steps, needs no trailing '...' Bernhard, was the upgrade to 5.8 intentional and necessary? In February I was fairly sure that Perl 5.8.0 was already required. But I must have mixed that up as I can't find that mentioned on p6i. The reason for making an explicit check was that I didn't recall whether 'our' was introduced in 5.6.0 or 5.8.0. As 'our' was introduced in 5.6.0, I have lowered the requirements for Configure.pl to 5.006. CU, Bernhard I'm not sure if this has anything to do with this, but I know that perl 5.6 on OS X had troubles with parsing pmc files. (in my case at least, then after an upgrade to 5.8, the problems were gone) Maybe this is it? klaas-jan
[svn:perl6-synopsis] r8928 - doc/trunk/design/syn
Author: larry Date: Mon Apr 24 00:59:42 2006 New Revision: 8928 Modified: doc/trunk/design/syn/S02.pod Log: Rules for parsing and compiling unrecognized identifiers. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podMon Apr 24 00:59:42 2006 @@ -12,7 +12,7 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 10 Aug 2004 - Last Modified: 23 Apr 2006 + Last Modified: 24 Apr 2006 Number: 2 Version: 30 @@ -1531,7 +1531,67 @@ always be taken to mean a subroutine or method name. (Class names (and other type names) are predeclared, or prefixed with the C<::> type sigil when you're declaring a new one.) A consequence of this -is that there's no longer any "C". +is that there's no longer any "C". Since the syntax +for method calls is distinguished from sub calls, it is only unreconized +sub calls that must be treated specially. + +You still must declare your subroutines, but an unrecognized bare +identifier is provisionally compiled as a subroutine call on that +assumption that such a declaration will occur by the end of the current +compilation unit. If it is not, the compile fails at C time. +(You are still free to predeclare subroutines explicitly, of course.) +The postdeclaration may be in any lexical or package scope that +could have made the declaration visible to the provisional call had the +declaration occurred before rather than after than the provisional +call. This fixup is done only for provisional calls. If there +is I real predeclaration visible, it always takes precedence. +In case of multiple ambiguous postdeclarations, either they must all +be multis, or a compile-time error is declared and you must predeclare, +even if one postdeclaration is obviously "closer". A single +C predeclaration may make all postdeclared C work fine, +since that's a run-time dispatch, and all multis are effectively +visible at the point of the controlling C declaration. + +If the unrecogized subname is followed by C<< postcircumfix:<( )> >>, it is +compiled as a provisional function call of the parenthesized form. +If it is not, it is compiled as a provisional function call of +the list operator form, which may or may not have an argument list. +When in doubt, the attempt is made to parse an argument list. As with +any list operator, an immediate postfix operator means there are no +arguments, whereas anything following whitespace will be interpreted +as an argument list if possible. It is illegal for a provisional +subroutine call to be followed by a colon postfix, since such a colon +is allowed only on an indirect object or a method call in dot form. +(It is also allowed on a label when a statement is expected.) +So for any undeclared identifier "C": + +foo.bar# foo().bar -- postfix prevents args +foo .bar # foo($_.bar) -- no postfix starts with whitespace +foo. .bar # foo().bar -- long dot, so postfix +foo++ # foo()++ -- postfix +foo 1,2,3 # foo(1,2,3)-- args always expected after listop +foo + 1# foo(+1) -- term always expected after listop +foo; # foo();-- no postfix, but no args either +foo: # label -- must be label at statement boundary. + -- illegal otherwise +foo: bar: # two labels in a row +.foo: # $_.foo: 1 -- must be "dot" method with : args +.foo(1)# $_.foo(1) -- must be "dot" method with () args +.foo # $_.foo() -- must be "dot" method with no args +.$foo: # $_.$foo: 1-- indirect "dot" method with : args +foo bar: 1 # bar.foo(1)-- bar must be predecl as class or sub + -- foo method call even if declared sub +foo bar 1 # foo(bar(1)) -- both subject to postdeclaration + -- never taken as indirect object +foo $bar: 1# $bar.foo(1) -- indirect object even if declared sub +foo bar(): # bar().foo(1) -- even if foo declared sub +foo bar baz: 1 # foo(bar baz: 1) -- colon controls "bar", not foo. +foo (bar baz): 1 # bar(baz()).foo(1) -- colon controls "foo" +$foo $bar # illegal -- two terms in a row +$foo $bar: # illegal -- use $bar.$foo for indirection +(foo bar) baz: 1 # illegal -- use $baz.$(foo bar) for indirection + +Parens are required around any indirect object that would be ambiguous. =item *
