[svn:perl6-synopsis] r12006 - doc/trunk/design/syn
Author: larry
Date: Fri Sep 15 08:38:58 2006
New Revision: 12006
Modified:
doc/trunk/design/syn/S04.pod
Log:
smartlinkable discussion of bindables on while and repeat while
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podFri Sep 15 08:38:58 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 19 Aug 2004
- Last Modified: 1 Sep 2006
+ Last Modified: 15 Sep 2006
Number: 4
- Version: 38
+ Version: 39
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -190,6 +190,20 @@
...
}
+You may optionally bind the result of the conditional expression to a
+parameter of the block:
+
+while something() - $thing {
+ ...
+}
+
+Nothing is ever bound implicitly, however, and many conditionals would
+simply bind True or False in an uninteresting fashion. This mechanism
+is really only good for objects that know how to return a boolean
+value and still remain themselves. In general, for most iterated
+solutions you should consider using a Cfor loop instead (see below).
+In particular, we now generally use Cfor to iterate filehandles.
+
=head2 The Crepeat statement
Unlike in Perl 5, applying a statement modifier to a Cdo block is
@@ -242,6 +256,22 @@
...
}
+As with an ordinary Cwhile, you may optionally bind the result of
+the conditional expression to a parameter of the block:
+
+repeat - $thing {
+ ...
+} while something();
+
+or
+
+repeat while something() - $thing {
+ ...
+}
+
+Since the loop executes once before evaluating the condition, the
+bound parameter will be undefined that first time through the loop,
+
=head2 The general loop statement
The Cloop statement is the C-style Cfor loop in disguise:
Re: META vs meta
David Brunton wrote: Aaron Sherman wrote: replies snipped / IMHO, the golden rule of programming languages should be: if you need a namespace, create one. Is there any reason these meta methods could not be part of some default function package like Math::Basic and Math::Trig? The package could be called Class::InterrogativePronouns, or Object::MetaModel, or ProgrammingLanguage::Pollution. And it could be loaded by default. Or not. That decision is far above my paygrade. [...] Does anyone else have thoughts on this they'd be willing to share? Let me see if I understand. You are essentially asking, why are these metaish things special? Why aren't they just coming from a namespace like everything else? The reason is two-fold (and they're good reasons): 1. The object system is built using these tools, so you cannot build them using the object system without doing some very ugly kludging and bootstrapping which we already have enough of to do. 2. As Larry points out in his documentation that you may or many not have noticed he updated yesterday, these will be macros, and thus cannot be dispatched at runtime. Thus they MUST bypass the dispatch that the user might be expecting to happen. The choices are thus: * Let that override part of the user namespace (with workarounds that Larry has suggested) or, * Create some unique way to say we're doing the metaish thing here, not dispatch. That was the idea of $obj\.meta or $obj.*meta or whatever. Larry seems to have made up his mind, and while I don't agree that his is the best choice, sometimes making a choice is more important than agreeing that it was the best one. Consensus is screwy that way ;) Someone who is Larry should probably speak up if that doesn't make any sense.
-X file test operators
I didn't see this going back, sorry if I missed someone sending the mail.
There was a discussion on IRC on Sept 9th about the -X filetest
operators between at least audreyt, Juerd, myself and markstos. The
problem with these operators was that they conflicted in some cases with
the parsing of unary -, such as:
foo(-π * 2 * $r);
or just:
sub x($n) { $n*2 }
foo(-x $number);
To make this easier, it was proposed that:
1. All file tests have long names as methods which P6 prefers:
$file.file_exists;
$file.is_directory;
$file.file_bytes;
2. That these methods be provided on Str, any IO that knows how to find
its filesystem represenation, File* where applicable.
3. Test-like name be provided with leading _ instead of -:
while _e $file {...}
while $file._e {...}
4. They *might* be deprecated or have a strict mode associated.
5. There may or may not be value in providing method-like - names:
$file.-e
6. (my note) the long methods should be provided as an option export
from a File::... module.
That was what we had so far.
Re: -X file test operators
Aaron Sherman skribis 2006-09-15 15:28 (-0400):
I didn't see this going back, sorry if I missed someone sending the mail.
Sorry. I promised to do it, but have so far lacked tuits and more or
less forgot all about it. Thanks for bringing it up!
There was a discussion on IRC on Sept 9th about the -X filetest
operators between at least audreyt, Juerd, myself and markstos. The
problem with these operators was that they conflicted in some cases with
the parsing of unary -, such as:
foo(-?? * 2 * $r);
or just:
sub x($n) { $n*2 }
foo(-x $number);
The problem was that -e was made a prefix operator. To make it work as a
method (i.e. for easy $_ operations), this implied that unknown postfix
ops would be mapped to prefix ones.
e.g.
-e $foo
$foo.-e
I think it's a bad idea to do this for all operators, because then we
take away future compatibility. If there's any area in which we still
have room to expand, it's postfix ops, and as they're nice and
methodish, we shouldn't grab the entire ASCIIbet already.
So, we discussed making -e a real method, which would imply that
identifiers can begin with -. That's nice, except that it forces
whitespace for prefix -, and that gets really annoying with things like
-Int. We also discussed -e for a while in the -2.71828183 sense, which
some believed should also be possible.
1. All file tests have long names as methods which P6 prefers:
$file.file_exists;
$file.is_directory;
$file.file_bytes;
2. That these methods be provided on Str, any IO that knows how to find
its filesystem represenation, File* where applicable.
And we discussed my bad feeling about polluting either the main or the
Str namespace with numerous file methods. I proposed .file, which
returns an unopened filehandle. This object can easily buffer stat info,
and could stringify to the filename (or, in case of STDOUT or a socket,
some other descriptive text) later, for easy verbose output.
e.g.
$filename.file.exists;
$filename.file.size; # perhaps bytes.
and
my $fh = $filename.file;
$fh.open or fail;
while ($fh.readline) { ... }
in addition to the existing
my $fh = open $filename or fail;
while (...) { ... }
I acknowledge that files can be anonymous, but they usually did have a
name when opening. Stringification to something useful is a good idea,
and it doesn't always have to match the current actual filename. We
could prepend \0 to special names like those for STD* and sockets. This
generally doesn't do anything special to terminals or web pages, but
does make string matching fail, as well as opening them as files, as no
system that I know of allows \0 in a filename.
Someone said it should probably be $filename.as(File) or something, but
I didn't like that because that takes away all the nice
bracketlessness and typability. Fortunately, Audrey mentioned that the
current trend is towards $filename.File anyway, for casting.
I think the concensus was that we don't really need -e and alikes to be
available by default, but we all wanted them for short scripts and
oneliners. A cheat mode pragma could easily solve this problem. I had
already been pondering the idea, in my head called use cheats;. It
would also provide useful short aliases like mv rm ls. Someone
mentioned that these functions, and -e alikes, are all shell-like
syntax, and pointed us to Perl 5's Shell.pm. It could also re-introduce
$$, in a kind of no English sense. Something like that would be great,
but a bit more thought out in a Perl 6 context. People agreed that such
a module or pragma should be enabled by default when the command line -e
was given (note: that's not file test -e.).
Our final conclusion was that we should probably parse postfixes like:
^\w+$
Try method call first, if it doesn't exist, try function call.
other
Always interpret as postfix operator. Because this could begin with
\w+, it takes precedence over pure ^\w+$.
and that we have four things we could do with -e:
1. Get rid of it entirely. Normal methods and/or use Shell fill the gap.
2. Install it as a prefix op, not as a postfix op. To get to $_, write
-e $_ explicitly.
3. Install these as prefix ops, and as postfix ops, but not as a general
rule for all prefix ops.
4. Rename the dash to underscore, use normal methods, and get used to _e
instead of -e.
I don't like 3 because it's duplication and special casing.
I don't like 4 because it would pollute namespace.
I like 1 because it encourages better programming, and because I really
like the idea of $name.file.exists.
I like 2 because I almost never default -e to $_ anyway, and -e $_ or
-e($_) isn't that bad.
My favourite is 1, followed by 2.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: -X file test operators
On Fri, Sep 15, 2006 at 10:47:45PM +0200, Juerd wrote: : 1. Get rid of it entirely. Normal methods and/or use Shell fill the gap. : 2. Install it as a prefix op, not as a postfix op. To get to $_, write :-e $_ explicitly. : 3. Install these as prefix ops, and as postfix ops, but not as a general :rule for all prefix ops. : 4. Rename the dash to underscore, use normal methods, and get used to _e :instead of -e. To which I already responded with 5: To write any prefix op as postfix, you should put it in quotes, which gives us .'-e' and .'@' and the like. (And also giving us a general way of isolating the method name from the .* variants, not to mention generating method names by interpolation without needing a temp variable.) Larry
Re: -X file test operators
Larry Wall skribis 2006-09-15 14:03 (-0700): To which I already responded with 5: To write any prefix op as postfix, you should put it in quotes, which gives us .'-e' and .'@' and the like. (And also giving us a general way of isolating the method name from the .* variants, not to mention generating method names by interpolation without needing a temp variable.) First impressions: Ugly, hard to type, not a solution for -e, weird syntax. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: -X file test operators
On Fri, Sep 15, 2006 at 11:28:18PM +0200, Juerd wrote: Larry Wall skribis 2006-09-15 14:03 (-0700): To which I already responded with 5: To write any prefix op as postfix, you should put it in quotes, which gives us .'-e' and .'@' and the like. (And also giving us a general way of isolating the method name from the .* variants, not to mention generating method names by interpolation without needing a temp variable.) First impressions: Ugly, hard to type, not a solution for -e, weird syntax. How is it not a solution for -e ? I thought it a perfectly good response to the problem. And, in fact, it solves a more general problem than just the -X ops. Also, presumably -e is shorthand for File.exists or some such, so that avenue still remains for the postfixification of the -X ops. TMTOWTDI after all :) Or maybe -e and friends are just macros and there are no postfix forms. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
dashed identifiers (was Re: -X file test operators)
On Fri, Sep 15, 2006 at 10:47:45PM +0200, Juerd wrote: So, we discussed making -e a real method, which would imply that identifiers can begin with -. As a bit of a tangent, occasionally I wish that we could use - in identifiers instead of _. I'd rather type $some-long-name than $some_long_name if only to not touch the shift key :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: dashed identifiers (was Re: -X file test operators)
At 4:55 PM -0500 9/15/06, Jonathan Scott Duff wrote: On Fri, Sep 15, 2006 at 10:47:45PM +0200, Juerd wrote: So, we discussed making -e a real method, which would imply that identifiers can begin with -. As a bit of a tangent, occasionally I wish that we could use - in identifiers instead of _. I'd rather type $some-long-name than $some_long_name if only to not touch the shift key :-) As I recall, we're allowed to put absolutely any characters we want in an identifier if it is a delimited identifier rather than a bareword identifier. That said, it isn't yet clear to me what the general rules for delimited identifiers are as contrasted with literal strings, and in particular, whether any leading sigil is supposed to go inside or outside of the delimiters. -- Darren Duncan
Re: -X file test operators
Jonathan Scott Duff skribis 2006-09-15 16:50 (-0500): To which I already responded with 5: To write any prefix op as postfix, you should put it in quotes, which gives us .'-e' and .'@' and the like. (And also giving us a general way of isolating the method name from the .* variants, not to mention generating method names by interpolation without needing a temp variable.) Ugly, hard to type, not a solution for -e, weird syntax. How is it not a solution for -e ? I thought it a perfectly good response to the problem. And, in fact, it solves a more general problem than just the -X ops. It's a solution for some of the -e problems, not all. It doesn't fix that unary minus needs whitespace to be used with certain identifiers for functions. Also, it doesn't fix the shorthand syntax for testing -e on $_ at all, because .'-e' is no better than -e($_). Well, okay, 1 character, but it costs a lot of grokability. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: dashed identifiers (was Re: -X file test operators)
On Fri, Sep 15, 2006 at 03:27:40PM -0700, Darren Duncan wrote:
: As I recall, we're allowed to put absolutely any characters we want
: in an identifier if it is a delimited identifier rather than a
: bareword identifier.
I have no clue what you mean by 'delimited identifier'. Are you referring
to the section of S02/Names that allows symbols like the following?
$::{'[EMAIL PROTECTED]@'}
::{'[EMAIL PROTECTED]@'}
: That said, it isn't yet clear to me what the general rules for
: delimited identifiers are as contrasted with literal strings, and in
: particular, whether any leading sigil is supposed to go inside or
: outside of the delimiters.
As the above illustrates, you can simply use literal strings as
the subscript, so there is no difference. And the sigil may go
either place. Which means it's not easy to have a package name
starting with a sigil. I don't consider this a big restriction.
Alternately we could recognize
::{'::[EMAIL PROTECTED]@'}
in which case it's difficult to have a package name starting with '::'.
That's probably a feature...
But in any case I would call these names or symbols, not identifiers.
Most people reserve identifier to mean a particular sort of symbol
that looks roughly alphanumeric to the lexer.
Larry
Re: dashed identifiers (was Re: -X file test operators)
At 4:26 PM -0700 9/15/06, Larry Wall wrote:
On Fri, Sep 15, 2006 at 03:27:40PM -0700, Darren Duncan wrote:
: As I recall, we're allowed to put absolutely any characters we want
: in an identifier if it is a delimited identifier rather than a
: bareword identifier.
I have no clue what you mean by 'delimited identifier'. Are you referring
to the section of S02/Names that allows symbols like the following?
$::{'[EMAIL PROTECTED]@'}
::{'[EMAIL PROTECTED]@'}
snip
But in any case I would call these names or symbols, not identifiers.
Most people reserve identifier to mean a particular sort of symbol
that looks roughly alphanumeric to the lexer.
Yes, a 'symbol' is what I was referring to when I said 'identifier',
and I typically include the sigil as part of that definition of an
identifier (blame the terminology used by the SQL standard plus some
other languages, which I am accustomed to); the single-quotes were
delimiters in this case, so what is between them was a delimited
identifier.
I will endeavour to call such things symbols rather than identifiers
in future discussion, so there isn't any confusion.
: That said, it isn't yet clear to me what the general rules for
: delimited identifiers are as contrasted with literal strings, and in
: particular, whether any leading sigil is supposed to go inside or
: outside of the delimiters.
As the above illustrates, you can simply use literal strings as
the subscript, so there is no difference. And the sigil may go
either place. Which means it's not easy to have a package name
starting with a sigil. I don't consider this a big restriction.
Alternately we could recognize
::{'::[EMAIL PROTECTED]@'}
in which case it's difficult to have a package name starting with '::'.
That's probably a feature...
Thank you for clarifying that. In particular that the sigil could go
either inside or outside of the string-delimiter-quotes.
-- Darren Duncan
[svn:perl6-synopsis] r12090 - doc/trunk/design/syn
Author: larry
Date: Fri Sep 15 18:48:48 2006
New Revision: 12090
Modified:
doc/trunk/design/syn/S05.pod
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S12.pod
Log:
repairing some splat damage
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podFri Sep 15 18:48:48 2006
@@ -1534,7 +1534,7 @@
Note that, as a scalar variable, C$/ doesn't automatically flatten
in list context. Use C@() as a shorthand for C@($/) to flatten
the positional captures under list context. Note that a CMatch object
-is allowed to evaluate its match lazily in list context. Use C**@()
+is allowed to evaluate its match lazily in list context. Use Ceager @()
to force an eager match.
=item *
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podFri Sep 15 18:48:48 2006
@@ -2124,7 +2124,7 @@
CCode object by passing the CCapture to its Ccall method:
# Transparently redirect all calls to thermo to other_thermo
-thermo.wrap( - \$args { other_thermo.call(*$args) } );
+thermo.wrap( - \$args { other_thermo.call([,] =$args) } );
Outside a wrapper, Ccall implicitly calls the next-most-likely method
or multi-sub; see S12 for details.
@@ -2132,9 +2132,9 @@
As with any return value, you may capture the returned CCapture of Ccall
by binding:
-my \$retval := call(*$args);
+my \$retval := call([,] =$args);
... # postprocessing
-return *$retval;
+return [,] =$retval;
=head2 The C?ROUTINE object
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podFri Sep 15 18:48:48 2006
@@ -1165,7 +1165,7 @@
Since the method name (but nothing else) is known at class construction
time, the following C.wag method is autogenerated for you:
-method wag ([EMAIL PROTECTED] is context(Lazy)) { $!tail.wag([EMAIL
PROTECTED]) }
+method wag ([EMAIL PROTECTED] is context(Lazy)) { $!tail.wag([,] @args) }
You can specify multiple method names:
@@ -1175,7 +1175,7 @@
has been initialized to an object of a type supporting the method,
such as by:
-has Tail $.tail handles 'wag' = { .new(*%_) };
+has Tail $.tail handles 'wag' = { .new([,] %_) };
Note that putting a CTail type on the attribute does not necessarily
mean that the method is always delegated to the CTail class.
