Re: Second try: Builtins
Aaron Sherman wrote:
> On Sat, 2002-09-07 at 14:22, Smylers wrote:
>
> > Should that C<+> be there? I would expect chomp only to remove a
> > single line-break.
>
> Note that this is in paragraph (e.g. C<$/=''>) mode
Ah, yes. I quoted the wrong case above. The final branch deals with
the case when C<$/> (or equivalent) is set:
} else {
$string =~ s/<{"<[$irs]>"}>+$//;
return $0;
}
If C<$irs = "\n"> then I'd only expect a single trailing newline to be
removed but that substitution still looks as though it'll get rid of as
many as are there.
> > In a scalar context does C still a string with characters
> > reversed?
>
> Yes, but that would be:
>
> sub reverse($string) {
> return join '', reverse([split //, $string]);
> }
Perl 5's C is sensitive to the context in which it is called
rather than the number of arguments. This is an 'element' reversal with
only one element:
$ perl -wle 'print reverse qw'
This is a 'character' reversal even though several strings have been
passed:
$ perl -wle 'print scalar reverse qw'
So a C with a single array parameter could be either type.
Smylers
Blocks and semicolons
So, the new rule for blocks and when the need semicolons seems to be
"You don't need a semicolon if the block is the last argument of a
subroutine which expects a block as its last argument", which is all
very well and all, but where does that leave:
sub foo ( &block ) {...}
...
$wibble = foo { ... } + 10;
The problem here is that this change makes the meaning of every brace
dependent on everything that's gone before and we're back with a
language that's at least as hard as Perl 5 was to parse.
Now, my understanding was that the rule for 'statement terminating
braces' was
1. brace matches rx/^^ \s* \} \s* $$/
Or, less strictly:
2. brace matches rx/ } \s* $$/
Which I could have *sworn* was something Damian had told me was the
right thing, but I've mislaid the original mail. The idea behind this
approach, judging by the Apocalypse, is that it means that instead of
blocks needing or not needing a semicolon based on special cases, all
blocks have a simple rule.
Here's what Apocalypse 4 says on the subject:
If there is any space before the curly, we force it to start a
term, not an operator, which means that the curlies in question
must delimit either a hash composer or a block. And it's a hash
composer only if it contains a => pair constructor at the top level
(or an explicit hash keyword on the front.) Therefore it's possible
to unambiguously terminate an expression by following it with a
block
Which seems to imply that:
$wibble = foo {...} + 10;
would actually be parsed as:
$wibble = foo {...}; +10;
Ah... hang on, that's *expression* not statement, so that should parse
as C<< $wibble = foo( sub {...}) + 10; >> which is fine.
The rules for what the parser infers (semicolon, comma, nothing) after
a block are somewhat undefined though. How would
func $foo {...}
func $bar {...}
func $baz {...}
deparse? C<< func $foo {...}; func $bar {...}; func $baz {...}; >>?
C<< func $foo {...}, func $bar {...}, func $baz {...} >>?
Am I worrying unduly about nothing?
What was my question? Argh! I'm more confused now then when I started
this message...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Blocks and semicolons
Piers Cawley wrote:
> So, the new rule for blocks and when the need semicolons seems to be
> "You don't need a semicolon if the block is the last argument of a
> subroutine which expects a block as its last argument", which is all
> very well and all, but ... Ah... hang on, that's *expression* not
> statement, so that should parse ... fine.
>
> Am I worrying unduly about nothing?
>
> What was my question? Argh! I'm more confused now then when I started
> this message...
I'm wondering how implied semicolons will interact with statement
modifiers.[*0] This is Damian's example of calling a user-defined sub
without a trailing semicolon:
perhaps $x<$y, 0.25 { print "Happened to be less than\n"}
Presumably it's valid to put a statement modifier on such a line (with a
semicolon after it, obviously):
perhaps $x < $_, 0.4 { print "Smaller\n"} for @max;
Presumably it's also possible to have such a line (without a statement
modifier) with a for loop as the following statement, and for that loop
to use the new syntax for iterating through multiple lists in parallel:
perhaps $x < $_, 0.4 { print "Smaller\n"}
for @max; @min -> $top; $bottom
{
# etc
}
How are these two cases distinguished from each other?
Since whitespace is interchangeable, the second fragment could be
formatted like this to make it look even more like the first:
perhaps $x < $_, 0.4 { print "Smaller\n"} for @max;
@min -> $top; $bottom
{
# etc
}
I'm scared.
[*0] I actually tried to wonder this on this list last week. As I'm
not subscribed I thought that posting through the newsgroup interface
would be the best way of keep threading. I tried posting through Google
Groups. My article showed up there (see link below), but doesn't seem
to have filtered through to other places. Is it supposed to?
I'm posting this with a newsreader rather than a web-browser so
hopefully it'll get through. Apologies to anybody who got it twice.
http://groups.google.co.uk/groups?hl=en&ie=UTF-8&oe=UTF-8&threadm=d7c367d5.0209051022.9ba6bea%40posting.google.com&rnum=1
Smylers
Re: Blocks and semicolons
This is for everyone: < Piers Cawley wrote:
>
> > So, the new rule for blocks and when the need semicolons seems to be
> > "You don't need a semicolon if the block is the last argument of a
> > subroutine which expects a block as its last argument", which is all
> > very well and all, but ... Ah... hang on, that's *expression* not
> > statement, so that should parse ... fine.
> >
> > Am I worrying unduly about nothing?
> >
> > What was my question? Argh! I'm more confused now then when I started
> > this message...
>
> I'm wondering how implied semicolons will interact with statement
> modifiers.[*0] This is Damian's example of calling a user-defined sub
> without a trailing semicolon:
>
> perhaps $x<$y, 0.25 { print "Happened to be less than\n"}
>
> Presumably it's valid to put a statement modifier on such a line (with a
> semicolon after it, obviously):
>
> perhaps $x < $_, 0.4 { print "Smaller\n"} for @max;
>
> Presumably it's also possible to have such a line (without a statement
> modifier) with a for loop as the following statement, and for that loop
> to use the new syntax for iterating through multiple lists in parallel:
>
> perhaps $x < $_, 0.4 { print "Smaller\n"}
> for @max; @min -> $top; $bottom
> {
> # etc
> }
>
> How are these two cases distinguished from each other?
>
> Since whitespace is interchangeable, the second fragment could be
> formatted like this to make it look even more like the first:
>
> perhaps $x < $_, 0.4 { print "Smaller\n"} for @max;
> @min -> $top; $bottom
> {
> # etc
> }
>
> I'm scared.
>
> [*0] I actually tried to wonder this on this list last week. As I'm
> not subscribed I thought that posting through the newsgroup interface
> would be the best way of keep threading. I tried posting through Google
> Groups. My article showed up there (see link below), but doesn't seem
> to have filtered through to other places. Is it supposed to?
>
> I'm posting this with a newsreader rather than a web-browser so
> hopefully it'll get through. Apologies to anybody who got it twice.
>
>
>http://groups.google.co.uk/groups?hl=en&ie=UTF-8&oe=UTF-8&threadm=d7c367d5.0209051022.9ba6bea%40posting.google.com&rnum=1
>
> Smylers
>
Re: Blocks and semicolons
Luke Palmer wrote:
> This is for everyone: <
>... put a semicolon after do {} or eval {} when it looks like a
>complete statement?"
>
>Well, in Perl 6, you don't, if the final curly is on a line by
>itself.
>
> To me, this looks like it has answers to all these questions.
It would do, but 'A4' considerably predates that example I quoted from
Damian. It was only on August 28th this year that he said these are
fine without semicolons:
perhaps $x<$y, 0.25 { print "Happened to be less than\n"}
perhaps $x>$y, 0.50 { print "Happened to be greater than\n"}
Those braces definitely aren't on their own lines. This is the message
where he said it:
http://groups.google.co.uk/groups?&hl=en&ie=UTF-8&oe=UTF-8&threadm=3D6D4E7D.6070201%40conway.org&rnum=1&prev=/groups%3Fq%3Dg:thl477944572d%26dq%3D%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D3D6D4E7D.6070201%2540conway.org
He said something similar in the Perl 6 talk in London the following day
(and quite possibly other Perl 6 talks elsewhere at other times). So
the possibilities are:
1 Damian is wrong.
2 I've misunderstood what Damian said and wrote.
3 This bit of 'A4' has been superseded and the current thinking is
what Damian said above.
Option 1 strikes me as unlikely; Damian obviously has read 'A4'.
Option 3 is what scares me and is the reason why I'm after
clarification.
Given that, Option 2 would be a relief. (An embarrassment, but still a
relief.)
Smylers
Re: Blocks and semicolons
Luke Palmer <[EMAIL PROTECTED]> writes:
> This is for everyone: <
>In Perl, this problem comes up most often when people say "Why do I
>have to put a semicolon after do {} or eval {} when it looks like a
>complete statement?"
>
>Well, in Perl 6, you don't, if the final curly is on a line by itself.
>That is, if you use an expression block as if it were a statement
>block, it behaves as one. The win is that these rules are consistent
>across all expression blocks, whether user-defined or built-in. Any
>expression block construct can be treated as either a statement or a
>component of an expression. Here's a block that is being treated as a
>term in an expression:
> $x = do {
> ...
> } + 1;
>
>However, if you write
> $x = do {
> ...
> }
> + 1;
>then the + will be taken erroneously as the start of a new statement.
>(So don't do that.)
>
>Note that this special rule only applies to constructs that take a
>block (that is, a closure) as their last (or only) argument. Operators
>like sort and map are unaffected. However, certain constructs that
>used to be in the statement class may become expression constructs in
>Perl 6. For instance, if we change BEGIN to an expression construct we
>can now use a BEGIN block inside an expression to force compile-time
>evaluation of a non-static expression:
> $value = BEGIN { call_me_once() } + call_me_again();
>
>On the other hand, a one-line BEGIN would then have to have a
>semicolon.
>
> EOA4
>
> To me, this looks like it has answers to all these questions.
Up to a point. Look at the discussion of given/when in the same
Apocalypse. Here's some example code from A4:
given $! {
when Error::Overflow { ... }
when Error::Type { ... }
when Error::ENOTTY { ... }
when /divide by 0/ { ... }
...
}
Look, closing braces, ending statements, not on a line by
themselves. There's code like this all through the apocalypse and its
associated Exegesis, so it looks to me like C<< rx/\} \s* \n/ >> is
the regex for 'end of statement'. Either that or we're back with a
pile of special cases, which I thought the Apocalypse was supposed to
be eliminating.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Blocks and semicolons
> Luke Palmer wrote:
> > [quote from A4]
> > To me, this looks like it has answers to all these questions.
>
> Up to a point. Look at the discussion of given/when in the same
> Apocalypse. Here's some example code from A4:
>
>
> given $! {
> when Error::Overflow { ... }
> when Error::Type { ... }
> when Error::ENOTTY { ... }
> when /divide by 0/ { ... }
> ...
> }
>
> Look, closing braces, ending statements, not on a line by
> themselves. There's code like this all through the apocalypse and its
> associated Exegesis, so it looks to me like C<< rx/\} \s* \n/ >> is
> the regex for 'end of statement'. Either that or we're back with a
> pile of special cases, which I thought the Apocalypse was supposed to
> be eliminating.
That's because Cs are statements. Statements don't need to be
terminated. In C (or even Perl 5) you don't need to write:
if (a < b) { foo(); };
That's because the grammar says that conditionals (and loops) are
statements all by themselves, because this doesn't make sense:
1 + if (a < b) { foo(); } / 2;
But in Perl 6, things are moving around. Perl 6 needs the ability for
users to program such interfaces with subs, which I expressions. So,
according to Damian, if a sub's last argument is a closure, it can (but
not necessarily will) act like a statement rather than an expression.
>From what I understand of his message, this has nothing to do with
whitespace.
I don't know the exact semantics, if they are what I think they are, then
I disagree.
sub cond_if ($condition, &code) {...} # returns something
cond_if ($x < $y) { $y }
for @a; @b; @c; # ...
This requires infinite lookahead to parse. Nobody likes infinite
lookahead grammars.
Personally, I liked the A4 decision the best ('}' on a line by itself),
and I think otherwise there's too many ambiguities like this one.
However, if an elegant solution has been (or is going to be) found, I'm
all ears.
Luke
Re: Blocks and semicolons
Luke Palmer wrote:
[Piers wrote:]
> > Look, closing braces, ending statements, not on a line by
> > themselves. There's code like this all through the apocalypse and
> > its associated Exegesis, so it looks to me like C<< rx/\} \s* \n/ >>
> > is the regex for 'end of statement'. Either that or we're back with
> > a pile of special cases, which I thought the Apocalypse was supposed
> > to be eliminating.
>
> That's because Cs are statements. Statements don't need to be
> terminated. In C (or even Perl 5) you don't need to write:
>
> if (a < b) { foo(); };
>
> That's because the grammar says that conditionals (and loops) are
> statements all by themselves, because this doesn't make sense:
>
> 1 + if (a < b) { foo(); } / 2;
>
> But in Perl 6, things are moving around. Perl 6 needs the ability for
> users to program such interfaces with subs, which I expressions.
> So, according to Damian, if a sub's last argument is a closure, it can
> (but not necessarily will) act like a statement rather than an
> expression.
The way I remember hearing Damian explain it was the other way round --
that many things that have been statements will now be built-in
functions that take closures as arguments, and that they won't have any
special powers that user-defined functions can't.
I'm reasonably sure it was that way round, cos Damian saying it (in
London) provoked me into asking "Does that mean that C now needs a
semicolon after the block?" I'm reasonably sure the answer was that any
sub with a closure as a final argument can be invoked without a trailing
semicolon.
> From what I understand of his message, this has nothing to do with
> whitespace.
I think so too, which definitely disagrees with 'A4'.
> I don't know the exact semantics, if they are what I think they are,
then
> I disagree.
>
> sub cond_if ($condition, &code) {...} # returns something
>
> cond_if ($x < $y) { $y }
> for @a; @b; @c; # ...
>
> This requires infinite lookahead to parse.
Yup.
> Personally, I liked the A4 decision the best ('}' on a line by
> itself),
I'm not overly keen on that because it suddenly gives line-breaks a
special meaning. The rule in Perl at the moment that all whitespace is
interchangeable and you can arrange your code as you like is very
simple. Adding a special case (aka 'inconsistency') for a single
punctuation character sounds to be against the spirit of 'A5''s intro,
about making things simpler and more consistent.
I think I'd be happy enough with requiring semicolons at the end of all
statements, including C blocks, C definitions -- everything.
It'd at least be consistent (and the problem with C and anonymous
C blocks in Perl 5 is not the semicolon _per se_, just the
semicolon there compared to the lack of one elsewhere).
> and I think otherwise there's too many ambiguities like this one.
> However, if an elegant solution has been (or is going to be) found,
> I'm all ears.
Smylers
