[svn:parrot-pdd] r12153 - trunk/docs/pdds/clip
Author: rgrjr Date: Sat Apr 8 19:23:27 2006 New Revision: 12153 Modified: trunk/docs/pdds/clip/pddXX_exceptions.pod (contents, props changed) Log: Add keywords to reflect usage. Modified: trunk/docs/pdds/clip/pddXX_exceptions.pod == --- trunk/docs/pdds/clip/pddXX_exceptions.pod (original) +++ trunk/docs/pdds/clip/pddXX_exceptions.pod Sat Apr 8 19:23:27 2006 @@ -1,5 +1,5 @@ # Copyright: 2001-2006 The Perl Foundation. -# $Id: $ +# $Id$ =head1 NAME @@ -12,7 +12,7 @@ =head1 VERSION -$Revision: $ +$Revision$ =head1 DESCRIPTION
Re: [perl #38888] PGE::P5Regexp failures.
Patrick R. Michaud [EMAIL PROTECTED] wrote: At any rate, I suspect pbc_merge is the culprit. If you have any simple(-ish ;-) test cases that demonstrate the particular issue, I'll probably have a little time in the next few days to investigate. I've not really had enough time to follow Parrot changes of late to know if there's anything that happened that was likely to need changes from pbc_merge; it could just be a bug in there from the beginning, of course. Thanks, Jonathan
Re: [selenium-dev] Selenium RC driver
On Thu, Apr 06, 2006 at 11:06:00PM -0700, Dan Fabulich wrote: Good points there... Here's my two cents (and a bit). 0) Not explicitly highlighted, Selenium Core generates an XML file with a full description of its API; this is enough information to generate copious javadoc, ndoc, rdoc, pydoc, or POD perldoc. We should use it for something perl-ish, one way or another. Agreed. 1) It's worth noting that the other drivers (java, c#, python, ruby) *do* have build code. For python/ruby, there's just enough build code to run XSLT to generate code, run some tests, and generate doc, but the c# code requires running it through csc and the java code is compiled by Maven. A makefile would therefore not be out of place. 2) As clever as the AUTOLOAD code is, it can be very opaque to end users. Since the AUTOLOAD code has no explicit definition of click (for example), users can't grep through the code for its implementation, and they have to consult the Selenium website for reference documentation. While we could use the Core XML to merely generate POD documentation, at that point we're really 90% of the way towards generating all of the Perl code, which I would probably prefer. I'm not particularly concerned about this one way or another. Provided the documentation is there people can look at the source or not as they please. No doubt some poeple would prefer the minimal AUTOLOAD code and others the more explicit longhand. Since it is machine generated we are keeping DRY whichever way we go. 3) It's never been clear to me what to do with code that is partly Perl and partly something else. CPAN is full of pure Perl (or Perl + C) projects, but Selenium will always be a multi-lingual project (for the browser-side JavaScript alone, if not also the Java server). What do people normally do with that kind of project? I don't see a problem with that sort of thing going on CPAN, at least not from that point of view, but I do wonder if it is worthwhile given that it will exist as part of Selenium itself. I suppose the advantage would be that it would be possible to use standard perl installation mantras to install Selenium. 4) I'm happy to volunteer to maintain a *thin* Perl driver that does not include its own back-end code. Such a driver should be no longer and no more complex than the Python, Ruby, Java or C# drivers, and can/should include automatically generated code/doc. If the project is bigger than that, though, someone else will need to do it. What is the state of this at the moment? I need it now, otherwise I'll be using the Ruby driver ;-) I have some time to work on it at the moment, but I might not have in a few days. Luke mentioned he had the basics of something, and you have volunteered here. Is there something I can assist with? As far as strategy is concerned, I think this is the right way to go. I don't see any point in rewriting the Java code if it is doing everything necessary (I discovered I needed a fairly recent (or possibly just not ancient) version of java to get it to work), and being consistent with the other languages seems to provide many benefits. I'm on freenode #selenium if anyone wants to discuss this there. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [selenium-dev] Perl Selenium RC driver
Paul Johnson wrote: I'm not particularly concerned about this one way or another. Provided the documentation is there people can look at the source or not as they please. No doubt some poeple would prefer the minimal AUTOLOAD code and others the more explicit longhand. Since it is machine generated we are keeping DRY whichever way we go. Good point. It's also worth noting that the current Test::WWW::Selenium stuff actually uses AUTOLOAD in two places, and a natural choice might be to split the difference. Right now, the code uses AUTOLOAD to run arbitrary commands on the Selenium Server (so it doesn't have to define commands like click open, etc. explicitly), and it also uses AUTOLOAD around those commands to define testing modifiers like _ok, _like, _is, _contains, etc. IMO, generating the modifiers is considerably less confusing than generating *all* of the commands from the bottom up; it might be a good idea to leave in the AUTOLOAD stuff for the testing modifiers but literally define click, open etc. in the code (automatically by code generation). Re: CPAN... I don't see a problem with that sort of thing going on CPAN, at least not from that point of view, but I do wonder if it is worthwhile given that it will exist as part of Selenium itself. I suppose the advantage would be that it would be possible to use standard perl installation mantras to install Selenium. I'd think it'd be worth putting up on CPAN in some form, I think, if it could be done cleanly, for that reason alone. But the idea of CPAN is that you should be able to just go to CPAN and -install your module and then, after a short wait, you should be ready to begin using it. When the module has dependencies on other non-Perl non-C code, that presumably means you're going to have to install another interpreter as well. I could certainly imagine a CPAN module that would automatically install Java (Alien::Java?), but that seems Really Weird to me, perhaps especially because Java isn't Free-as-in-Speech software. I'd sooner imagine someone writing an Alien::Python CPAN module or an Alien::Ruby module! What is the state of this at the moment? I need it now, otherwise I'll be using the Ruby driver ;-) Well, if you need it Now (tm) then you *should* use the Ruby driver. :-) I have some time to work on it at the moment, but I might not have in a few days. Luke mentioned he had the basics of something, and you have volunteered here. Is there something I can assist with? Not really. Writing an RC-compatible thin Perl driver is a matter of a day; I've done it, and it sounds like Luke's got one, and some other folks have also written one. I think the only thing to do now is decide what to do with all this code we've written. -Dan
Re: [selenium-dev] Perl Selenium RC driver
On Mon, Apr 10, 2006 at 10:26:14AM -0700, Dan Fabulich wrote: Paul Johnson wrote: Re: CPAN... I don't see a problem with that sort of thing going on CPAN, at least not from that point of view, but I do wonder if it is worthwhile given that it will exist as part of Selenium itself. I suppose the advantage would be that it would be possible to use standard perl installation mantras to install Selenium. I'd think it'd be worth putting up on CPAN in some form, I think, if it could be done cleanly, for that reason alone. But the idea of CPAN is that you should be able to just go to CPAN and -install your module and then, after a short wait, you should be ready to begin using it. When the module has dependencies on other non-Perl non-C code, that presumably means you're going to have to install another interpreter as well. I could certainly imagine a CPAN module that would automatically install Java (Alien::Java?), but that seems Really Weird to me, perhaps especially because Java isn't Free-as-in-Speech software. I'd sooner imagine someone writing an Alien::Python CPAN module or an Alien::Ruby module! I don't think it is a big problem to say you need to have selenium installed to use this module - here's what to do. Or maybe would you like me to install it for you? What is the state of this at the moment? I need it now, otherwise I'll be using the Ruby driver ;-) Well, if you need it Now (tm) then you *should* use the Ruby driver. :-) OK. How about Real Soon Now? ;) I have some time to work on it at the moment, but I might not have in a few days. Luke mentioned he had the basics of something, and you have volunteered here. Is there something I can assist with? Not really. Writing an RC-compatible thin Perl driver is a matter of a day; I've done it, and it sounds like Luke's got one, and some other folks have also written one. I think the only thing to do now is decide what to do with all this code we've written. Is your code checked in? I had a discussion with Luke on IRC and we threw a few ideas around, but I wasn't aware that either you or anyone else had any code written, and I don't think Luke was either. It might be an idea for you, Luke and anyone else with any code to get together somehow and see how to push this forward, either in this thread or on IRC. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
[svn:perl6-synopsis] r8625 - doc/trunk/design/syn
Author: larry
Date: Mon Apr 10 11:04:44 2006
New Revision: 8625
Modified:
doc/trunk/design/syn/S02.pod
Log:
Refactored long dot and embedded comments to be more orthogonal, so that
foo.#{ bar }.baz is now just a long dot whose ws happens to match #{}.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podMon Apr 10 11:04:44 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 10 Aug 2004
- Last Modified: 7 Apr 2006
+ Last Modified: 10 Apr 2006
Number: 2
- Version: 21
+ Version: 22
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -44,6 +44,7 @@
not to use thin spaces where they will make adjoining tokens look like
a single token. On the other hand, Perl doesn't use indentation as syntax,
so you are free to use any whitespace anywhere that whitespace makes sense.
+Comments always count as whitespace.
=back
@@ -79,34 +80,50 @@
=item *
Embedded comments are supported as a variant on quoting syntax, introduced
-by C.# and delimited by user-selected characters.
+by C# plus any user-selected bracketing characters (including Unicode):
-say .#( embedded comment ) hello, world!;
+say #( embedded comment ) hello, world!;
-$object.#/ embedded comments /.say;
+$object.#{ embedded comments }.say;
-$object.#[
+$object.#「
embedded comments
-].say;
+」.say;
-The delimiters of the C.#// embedded comment form may be chosen
-from the same set that are valid for ordinary Cq// quote forms,
-and follow the same policy on the nesting of bracketing characters.
-Unlike the other two forms of comment, the embedded form does not
-count as whitespace.
-
-As a variant of the embedded form, a single dot followed by a space
-is equivalent to C.#. (plus an extra dot at the end) so you can
-write a small (generally whitespace only) comment as:
+There must be no space between the # and the opening bracket character.
+Brackets may be nested following the same policy as ordinary quote brackets.
+
+=item *
+
+In addition to the general comment forms above, there is a whitespace-only
+comment form that begins and ends with a single dot, separated by whitespace,
+which is equivalent to a single dot:
%hash. .{$key}
@array. .{$key}
-which is useful for lining up postfixes. This is known as the long dot,
+This is useful for lining up postfixes. This is known as the long dot,
partly because it substitutes for a dot without the need for a third dot:
$object. .say();
+The whitespace in the middle may include any of the comment forms above.
+Because comments always count as whitespace, the dots in
+
+$object.#{ foo }.say
+
+reduce to a long dot rather than the range operator. Valid ways to
+insert a line break into a sequence of methods calls include:
+
+$object. # comment
+.say
+
+$object.#[ comment
+].say
+
+$object.
+.say
+
=item *
In general, whitespace is optional in Perl 6 except where it is needed
@@ -139,21 +156,18 @@
$x. .++
-$x.#..++
-
-$x. comment .++
-
$x.#( comment ).++
$x.
.++
-$x.#.
+$x.# comment
+ # more comment
.++
-$x.#[ # comment
- # more comment
-].++
+$x.#『 comment
+ more comment
+』.++
$x.#[ comment 1
comment 2
@@ -164,14 +178,38 @@
].++
A consequence of the postfix rule is that (except when delimiting a
-a quote or comment) a dot with whitespace in front of it is always
-considered a method call on C$_ where a term is expected. If a
-term is not expected at this point, it is a syntax error. (Unless,
-of course, there is an infix operator of that name beginning with
-dot. You could, for instance, define a Fortranly C infix:.EQ.
-if the fit took you. But you'll have to be sure to always put
-whitespace in front of it, or it would be interpreted as a postfix
-method call instead.)
+a quote or terminating a long dot) a dot with whitespace in front
+of it is always considered a method call on C$_ where a term is
+expected. If a term is not expected at this point, it is a syntax
+error. (Unless, of course, there is an infix operator of that name
+beginning with dot. You could, for instance, define a Fortranly C
+infix:.EQ. if the fit took you. But you'll have to be sure to
+always put whitespace in front of it, or it would be interpreted as
+a postfix method call instead.)
+
+For example,
+
+foo .method
+
+and
+
+foo
+.method
+
+will always be interpreted as
+
+foo $_.method
+
+but never as
+
+foo.method
+
+Use some variant of
+
+foo.
+.method
+
+if you mean the postfix method call.
=back
@@ -509,7 +547,7 @@
Whitespace is not allowed before
Re: [svn:perl6-synopsis] r8625 - doc/trunk/design/syn
+insert a line break into a sequence of methods calls include:
s/methods/method/
A consequence of the postfix rule is that (except when delimiting a
...
+a quote or terminating a long dot) a dot with whitespace in front
Too many a's.
+you to insert optional whitespace and commentsbetween dots:
How about inserting whitespace between keywords?
On a lighter note:
+MyType. .::. .{'$foo'}
Perl 6, the language of executable ASCII art. The old camel-duplication
script has got nothing on this.
Signed,
Your friendly neighbourhood proof-reader.
--
And I see losing love is like a window in your heart: everybody sees
you're blown apart; everybody sees the wind blow in Graceland.
-- Paul Simon, 1986 ... I am the Dance Commander, and I order FUN!
http://surreal.istic.org/ - Installing Windows in your heart since 2003.
pgp769CYAKtux.pgp
Description: PGP signature
Re: [selenium-dev] Perl Selenium RC driver
Paul Johnson wrote: Is your code checked in? I had a discussion with Luke on IRC and we threw a few ideas around, but I wasn't aware that either you or anyone else had any code written, and I don't think Luke was either. It might be an idea for you, Luke and anyone else with any code to get together somehow and see how to push this forward, either in this thread or on IRC. I haven't checked in my code because I didn't want to unnecessarily fork Luke's stuff. Luke's stuff (as you may already know) is available on CPAN: http://search.cpan.org/dist/Test-WWW-Selenium/ Note that this is a thick driver that is not (yet) compatible with the Java Selenium Server. Last we'd discussed the matter, Luke/Orlando were planning to add some support for an RC-compatible Http backend in addition to the File and InMemory backends that are already up there and implemented. Luke, what are your current thoughts? Should we go ahead with a thin perl driver that generates its Selenium click/open/etc. commands and then uses AUTOLOAD to create the _ok, _contains etc. stuff? -Dan
Re: [svn:perl6-synopsis] r8625 - doc/trunk/design/syn
On Mon, Apr 10, 2006 at 11:04:45AM -0700, [EMAIL PROTECTED] wrote:
Embedded comments are supported as a variant on quoting syntax, introduced
-by C.# and delimited by user-selected characters.
+by C# plus any user-selected bracketing characters (including Unicode):
I don't think that any design documentation defined or tabulated what is
a bracketing character:
http://google.com/search?q=site%3Adev.perl.org+%22bracketing+character%22
let alone how a user selects more of them.
-$object.#/ embedded comments /.say;
+$object.#{ embedded comments }.say;
'{' clearly is a bracketing character. But '/' wasn't?
Can I select # as a bracketing character for my obfuscations? :-)
Nicholas Clark
[svn:perl6-synopsis] r8631 - doc/trunk/design/syn
Author: larry
Date: Mon Apr 10 13:22:51 2006
New Revision: 8631
Modified:
doc/trunk/design/syn/S02.pod
Log:
Clarifications suggested by Nick++ and Daniel++.
Also pilfered the q[[[ ... ]]] multibracket mechanism from pod.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podMon Apr 10 13:22:51 2006
@@ -46,6 +46,15 @@
so you are free to use any whitespace anywhere that whitespace makes sense.
Comments always count as whitespace.
+=item *
+
+For some syntactic purposes, Perl distinguishes bracketing characters
+from non-bracketing. Bracketing characters are defined as any Unicode
+characters with either bidirectional mirrorings or Ps/Pe properties.
+(In practice, though, you're safest using matching characters with
+Ps/Pe properties, though ASCII angle brackets are a notable exception,
+since they're bidirectional but not in the Ps/Pe set.)
+
=back
=head1 Molecules
@@ -80,7 +89,7 @@
=item *
Embedded comments are supported as a variant on quoting syntax, introduced
-by C# plus any user-selected bracketing characters (including Unicode):
+by C# plus any user-selected bracket characters (see definition above):
say #( embedded comment ) hello, world!;
@@ -91,7 +100,27 @@
」.say;
There must be no space between the # and the opening bracket character.
-Brackets may be nested following the same policy as ordinary quote brackets.
+(There may be the Iappearance of space for some double-wide
+characters, however, such as the corner quotes above.) Brackets may
+be nested following the same policy as ordinary quote brackets.
+
+=item *
+
+For all quoting constructs that use user-selected brackets, multiple,
+adjacent, identical opening brackets must always be matched by
+an equal number of adjacent closing brackets. Use of two or more
+brackets disables bracket counting within the quoted text and merely
+scans for the closing set of brackets. Hence this comment legally
+contains unmatched brackets and even an unmatched C{{:
+
+#{{
+ Comment contains unmatched { and { { { { and {{ and } and } } but not:
+}}
+
+Note however that bare circumfix or postcircumfix C ... is
+not a user-selected bracket, but the ASCII variant of the C «...»
+interpolating word list. Only C# and the Cq-style quoters (including
+Cm, Cs, Ctr, and Crx) enable subsequent user-selected brackets.
=item *
@@ -113,7 +142,7 @@
$object.#{ foo }.say
reduce to a long dot rather than the range operator. Valid ways to
-insert a line break into a sequence of methods calls include:
+insert a line break into a sequence of method calls include:
$object. # comment
.say
@@ -157,6 +186,7 @@
$x. .++
$x.#( comment ).++
+$x.#((( comment ))).++
$x.
.++
@@ -178,7 +208,7 @@
].++
A consequence of the postfix rule is that (except when delimiting a
-a quote or terminating a long dot) a dot with whitespace in front
+quote or terminating a long dot) a dot with whitespace in front
of it is always considered a method call on C$_ where a term is
expected. If a term is not expected at this point, it is a syntax
error. (Unless, of course, there is an infix operator of that name
@@ -547,7 +577,7 @@
Whitespace is not allowed before the parens, but there is a
corresponding C.() operator, plus the long dot forms that allow
-you to insert optional whitespace and commentsbetween dots:
+you to insert optional whitespace and comments between dots:
foo. .($arg1, $arg2);
foo.#[
Re: The whatever context
On Sun, Apr 09, 2006 at 02:43:16PM +0300, Yuval Kogman wrote:
: Hi...
:
: I think that Perl 6 should have a whatever context, which is
: essentially:
:
: I want either array or scalar or whatever... You choose
:
: so that functions like grep can return an array in whatever
: context. This is best demonstrated using an example:
:
: my $x = grep { ... } @list; # returns count
I think that's already whatever context. $x contains the resulting array.
It's only if you later say +$x that you'll get the number of elems.
Larry
Re: The whatever context
On Mon, Apr 10, 2006 at 14:25:35 -0700, Larry Wall wrote:
: my $x = grep { ... } @list; # returns count
I think that's already whatever context. $x contains the resulting array.
It's only if you later say +$x that you'll get the number of elems.
Just for grep or for any function?
If just grep that means that grep simply doesn't use want.
If it's any function, then it means that all are constants are
list or whatever, and all we really have are coercers.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpKustGNNHeZ.pgp
Description: PGP signature
Re: Another dotty idea
Damian Conway wrote:
I'm not enamoured of the .# I must confess. Nor of the #. either. I wonder
whether we need the dot at all. Or, indeed, the full power of arbitrary
delimiters after the octothorpe.
Agreed.
What if we restricted the delimiters to the five types of balanced brackets?
And then simply said that, when any comment specifier (i.e. any octothorpe) is
followed immediately by an opening bracket, the comment extends to the
corresponding closing bracket?
Then you could have:
#[ This is a comment ]
#( This is a comment )
#{ This is a comment }
# This is a comment
#« This is a comment »
This does mean that if you comment out blocks with s/^/#/, you mess up on:
#sub foo
#{
# if foo { }
#}
That would also mean that # is *always* the comment introducer
(and the *only* comment introducer).
I agree with this goal.
I propose this form: #* *#
As a leading * on a line is unusual, and it also has visual similarity
to multi-line comments in C.
As for gappy dotting, that would become:
$x#[ ].foo()
or:
$x.# foo()
For comparison:
$x#* *#.foo()
or:
$x.#* *#foo()
Re: Another dotty idea
On Tue, Apr 11, 2006 at 12:26:13PM +1200, Sam Vilain wrote:
: This does mean that if you comment out blocks with s/^/#/, you mess up on:
:
: #sub foo
: #{
: # if foo { }
: #}
Well, actually, that still works. To be certain though, you could always
use s/^/##/ or s/^/# /. Even better is:
=begin UNUSED
sub foo
{
if foo { }
}
=end UNUSED
And I don't really care if that's not what people are used to.
The whole point of Perl 6 is to change How Things Work.
Larry
Re: Another dotty idea
On 4/10/06 8:38 PM, Larry Wall wrote:
Even better is:
=begin UNUSED
sub foo
{
if foo { }
}
=end UNUSED
And I don't really care if that's not what people are used to.
The whole point of Perl 6 is to change How Things Work.
Do you care that it's harder to visually pick out the commented-out portions
of a file at a glance using that syntax? I really don't want to give up
s/^/#/ commenting. Double ##s seem like overkill to me. Then I have to use
triple ### for the thicker parts in my little ASCII art comment header
thingies.
###
### Blah blah
###
## Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
## Ut et magna. Sed feugiat sollicitudin purus. Duis eget sem
## faucibus nibh dapibus sollicitudin. Sed egestas, nisl quis
## pharetra lacinia, libero urna tempus enim, non varius pede
sub foo
{
## bar();
## my $baz = blee();
## $baz--;
return 123;
}
No sir, I don't like it.
-John
Re: Another dotty idea
Larry Wall wrote:
On Tue, Apr 11, 2006 at 12:26:13PM +1200, Sam Vilain wrote:
: This does mean that if you comment out blocks with s/^/#/, you mess up on:
:
: #sub foo
: #{
: # if foo { }
: #}
Well, actually, that still works.
Oh, true :-)
But this fragment dies:
#sub foo
#{
# bar { } unless baz
#}
Unless you consider the idea of balancing the {}'s inside the comment,
which I think would be just plain nasty.
The #* .. *# form actually has a natural follow-on I didn't think of before:
#[ This is a comment ]#
#( This is a comment )#
#{ This is a comment }#
# This is a comment #
#« This is a comment »#
While technically the same thing applies to code that uses these delimited, it
means that the block I gave is now a parsefail. #-comments directly following
closing braces are probably sufficiently uncommon for this not to be such a
problem.
To be certain though, you could always
use s/^/##/ or s/^/# /.
I guess that works, but it breaks convention of # somewhat.
Even better is:
=begin UNUSED
sub foo
{
if foo { }
}
=end UNUSED
And I don't really care if that's not what people are used to.
The whole point of Perl 6 is to change How Things Work.
Sure, but there is still the principle of least surprise to worry about.
Sam.
Re: Another dotty idea
On Tue, Apr 11, 2006 at 12:54:50PM +1200, Sam Vilain wrote:
: Larry Wall wrote:
:
: On Tue, Apr 11, 2006 at 12:26:13PM +1200, Sam Vilain wrote:
: : This does mean that if you comment out blocks with s/^/#/, you mess up on:
: :
: : #sub foo
: : #{
: : # if foo { }
: : #}
:
: Well, actually, that still works.
:
:
:
: Oh, true :-)
:
: But this fragment dies:
:
: #sub foo
: #{
: # bar { } unless baz
: #}
:
:
: Unless you consider the idea of balancing the {}'s inside the comment,
: which I think would be just plain nasty.
I don't see how that's different at all from the first example.
: The #* .. *# form actually has a natural follow-on I didn't think of before:
:
: #[ This is a comment ]#
: #( This is a comment )#
: #{ This is a comment }#
: # This is a comment #
: #« This is a comment »#
:
: While technically the same thing applies to code that uses these
: delimited, it means that the block I gave is now a parsefail.
: #-comments directly following closing braces are probably sufficiently
: uncommon for this not to be such a problem.
Yes, Audrey made that suggestion too, but I think it's uglier for
the envisioned uses.
: To be certain though, you could always
: use s/^/##/ or s/^/# /.
:
:
:
: I guess that works, but it breaks convention of # somewhat.
You may have noticed that I don't mind breaking conventions somewhat. :-)
: Even better is:
:
: =begin UNUSED
: sub foo
: {
: if foo { }
: }
: =end UNUSED
:
: And I don't really care if that's not what people are used to.
: The whole point of Perl 6 is to change How Things Work.
:
:
:
: Sure, but there is still the principle of least surprise to worry about.
The problem with the Principle of Least Surprise is that you can use it
to justify just about anything by picking the right set of people. :-)
I freely admit that the current definition will surprise a few Perl 5
programmers. I'm more worried about what will look clean in 10 years.
Larry
Re: Another dotty idea
On Mon, Apr 10, 2006 at 08:46:02PM -0400, John Siracusa wrote: : Do you care that it's harder to visually pick out the commented-out portions : of a file at a glance using that syntax? I really don't want to give up : s/^/#/ commenting. Double ##s seem like overkill to me. Then I have to use : triple ### for the thicker parts in my little ASCII art comment header : thingies. I think commenting out code with # is sufficiently antisocial that you should probably do it with . Then it's *really* easy to pick out your commented portions at a glance. Plus it won't interfere visually with your ### blocks. And it has the additional advantage of keeping your tabs lined up. :-) Larry
Re: Another dotty idea
On 4/10/06 9:11 PM, Larry Wall wrote: I think commenting out code with # is sufficiently antisocial that you should probably do it with . What's antisocial about it? What's the alternative for quickly commenting out a few lines? Braced #[ ... ]# pairs are not as easy to mindlessly place quickly as a few # at the start of each line. -John
Re: Another dotty idea
Larry Wall wrote:
: But this fragment dies:
:
: #sub foo
: #{
: # bar { } unless baz
: #}
I don't see how that's different at all from the first example.
“#sub foo” is parsed as a comment token
“#{
# bar { }” is the next comment token
then we get “unless baz”
Unless you are balancing {}'s inside the # blocks, like q{ } does.
Sam.
Re: Another dotty idea
Damian Conway wrote:
Larry wrote:
I really prefer the form where .#() looks like a no-op method
call, and can provide the visual dot for a postfix extender. It
also is somewhat less likely to happen by accident the #., I
think. And I think the front-end shape of .# is more
recognizable as different from #, while #. requires a small
amount of visual lookahead, and is the same square shape on the
front, and could easily be confused with a normal line-ending
comment.
I'm not enamoured of the .# I must confess. Nor of the #. either. I
wonder whether we need the dot at all. Or, indeed, the full power
of arbitrary delimiters after the octothorpe.
How committed are we to spaces?
If we impose an adjacent-space requirement on the range operators, we
could just repeat dots endlessly:
given ($x) { when (0 .. 9) {...}}
$obj..method(); # These line up in proportional font. Sorry.
$newobjmethod();
$longobjname.method();
Frankly, I don't line up my method calls like this, so it's not much
of a concern. But I also use spaces around operators, so I'm okay with
my coding style becoming syntax. :)
=Austin
Re: Another dotty idea
On Tue, Apr 11, 2006 at 01:21:32PM +1200, Sam Vilain wrote:
: Larry Wall wrote:
:
: : But this fragment dies:
: :
: : #sub foo
: : #{
: : # bar { } unless baz
: : #}
: I don't see how that's different at all from the first example.
:
:
:
: “#sub foo” is parsed as a comment token
: “#{
: # bar { }” is the next comment token
:
: then we get “unless baz”
:
: Unless you are balancing {}'s inside the # blocks, like q{ } does.
That is how it is specced, and why the first example works.
Larry
Re: Another dotty idea
Damian Conway wrote:
I'm not enamoured of the .# I must confess. Nor of the #. either. I
wonder whether we need the dot at all. Or, indeed, the full power of
arbitrary delimiters after the octothorpe.
What if we restricted the delimiters to the five types of balanced
brackets? And then simply said that, when any comment specifier (i.e.
any octothorpe) is followed immediately by an opening bracket, the
comment extends to the corresponding closing bracket?
Then you could have:
#[ This is a comment ]
#( This is a comment )
#{ This is a comment }
# This is a comment
#« This is a comment »
This is a much better idea, disconnected from the question of putting
spaces in method calls. It's particularly nice if you say the magic
words multi-line comment.
(Please, spare me the hand-wringing about pod.)
I'll even pay you a closing hash (]#, }#, )#, etc.) if you put it in.
For extra credit, make them nest.
=Austin
int context ?
hello perlisticers (my first post) i read in the perl6 book second edition something called /Integer context/ and /Numeric context/ Ican understand the difference but since nowhere in the synopses i read a word abou integer context im not shore if these concept is thrown away. is it the case. i thought that operations like shifting that can anly aplied to integer may be here in some danger to rethought. your loyal follower sir lichtkind
[svn:perl6-synopsis] r8637 - doc/trunk/design/syn
Author: larry Date: Mon Apr 10 19:21:56 2006 New Revision: 8637 Modified: doc/trunk/design/syn/S04.pod Log: Bare block executes immediately; return of closure must be explicit. Modified: doc/trunk/design/syn/S04.pod == --- doc/trunk/design/syn/S04.pod(original) +++ doc/trunk/design/syn/S04.podMon Apr 10 19:21:56 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 19 Aug 2004 - Last Modified: 6 Apr 2006 + Last Modified: 10 Apr 2006 Number: 4 - Version: 13 + Version: 14 This document summarizes Apocalypse 4, which covers the block and statement syntax of Perl. @@ -287,6 +287,10 @@ useful for the do-once block, since it is offically a loop and can take therefore loop control statements. +Although a bare block is no longer a do-once loop, it still executes +immediately as in Perl 5. If you wish to return a closure from a +function, you must use an explicit Creturn. + =head1 Switch statements A switch statement is a means of topicalizing, so the switch keyword
RE: [svn:perl6-synopsis] r8637 - doc/trunk/design/syn
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, April 10, 2006 10:22 PM
To: perl6-language@perl.org
Subject: [svn:perl6-synopsis] r8637 - doc/trunk/design/syn
Author: larry
Date: Mon Apr 10 19:21:56 2006
New Revision: 8637
Modified:
doc/trunk/design/syn/S04.pod
Log:
Bare block executes immediately; return of closure must be explicit.
Modified: doc/trunk/design/syn/S04.pod
+Although a bare block is no longer a do-once loop, it still executes
+immediately as in Perl 5. If you wish to return a closure from a
+function, you must use an explicit Creturn.
+
How does the sub keyword fit in here? Is there any difference between
the lines
return {say Hello World;};
and
return sub {say Hello World;};
?
Joe Gottman
[svn:perl6-synopsis] r8638 - doc/trunk/design/syn
Author: larry Date: Mon Apr 10 19:34:44 2006 New Revision: 8638 Modified: doc/trunk/design/syn/S02.pod Log: Force # on the left margin to be line-end comment regardless of brackets. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podMon Apr 10 19:34:44 2006 @@ -104,6 +104,11 @@ characters, however, such as the corner quotes above.) Brackets may be nested following the same policy as ordinary quote brackets. +As a special case to facilitate commenting out sections of code with +Cs/^/#/, C# on the left margin is always considered a line-end +comment rather than an embedded comment, even if followed by a +bracketing character. + =item * For all quoting constructs that use user-selected brackets, multiple,
Re: [svn:perl6-synopsis] r8637 - doc/trunk/design/syn
On Mon, Apr 10, 2006 at 10:32:33PM -0400, Joe Gottman wrote:
:How does the sub keyword fit in here? Is there any difference between
: the lines
: return {say Hello World;};
: and
: return sub {say Hello World;};
: ?
Effectively, no, for these examples. In the second case you could
omit the return since you're not returning a bare block, so it's
not ambiguous. (The other difference is that the explicit sub form
allows you to return from within the closure.)
Larry
[svn:perl6-synopsis] r8641 - doc/trunk/design/syn
Author: larry
Date: Mon Apr 10 20:41:31 2006
New Revision: 8641
Modified:
doc/trunk/design/syn/S02.pod
Log:
Revised q foo to do bracket counting of long brackets internally.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podMon Apr 10 20:41:31 2006
@@ -112,15 +112,13 @@
=item *
For all quoting constructs that use user-selected brackets, multiple,
-adjacent, identical opening brackets must always be matched by
-an equal number of adjacent closing brackets. Use of two or more
-brackets disables bracket counting within the quoted text and merely
-scans for the closing set of brackets. Hence this comment legally
-contains unmatched brackets and even an unmatched C{{:
-
-#{{
- Comment contains unmatched { and { { { { and {{ and } and } } but not:
-}}
+adjacent, identical opening brackets must always be matched by an
+equal number of adjacent closing brackets. Bracket counting naturally
+applies only to sets of brackets of the same length:
+
+say #{{
+ Comment contains unmatched } and { { { { plus a counted {{ ... }} pair.
+}} q woot# says woot
Note however that bare circumfix or postcircumfix C ... is
not a user-selected bracket, but the ASCII variant of the C «...»
