Re: What does this do?
Larry Wall <[EMAIL PROTECTED]> writes:
> Piers Cawley writes:
> : Consider the following.
> :
> :sub foo {...}
> :
> :foo *@ary;
> :foo * @ary;
> :
> : Is this another place where whitespace will have meaning? Or should I
> : add parentheses to disambiguate? Enquiring minds want to know.
>
> I see no ambiguity. It's a unary * in either case. You'd have to
> declare it
>
> sub foo () {...}
>
> to get a multiply out of it.
Good oh.
--
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?
perl6-language@perl.org
On Mon, 2002-05-06 at 16:26, Dan Sugalski wrote: > I forgot to announce the call for questions here (sorry), but the > answers 9and the questions) to the first round of Ask The Parrot have > been posted over on use.perl. > http://use.perl.org/article.pl?sid=02/05/06/179233 for the interested. Some interesting items there. I'd like to ask a few follow-ups, but not sure who the right audience is. For now, let's assume it's this list, and not use.perl.org On language features: How is it that Parrot is language-neutral, and yet as a specific set of guarantees for destructors? Wouldn't those assumptions be wrong for, say, Scheme or Python? Also on that point, what of closures? Can those be managed in an efficient, and yet language-neutral fashion? On the Perl5 handling: why do you need step 3? Specifically, why not just continue to use the Perl5 parser as the Perl5 front-end for Perl6? That should guarantee compatibility. Very nice Q&A. Thank you very much for the info!
RE: Loop controls
On Mon, 2002-05-06 at 14:21, David Whipp wrote: > Miko O'Sullivan [mailto:[EMAIL PROTECTED]] wrote: > > Sorry, I thought I'd expressed agreement at some point. I like the > > "else\s+(if|while|for|loop)" construct very much, and I think the > > programmers of the world would like it too. I know a some people have > > issues with "where's the if" but it's no worse than "where's > > the semicolon" or "where's the filehandle closed". > > Is this the same as saying that C can be followed by > *any* statement? If not, then we would need user-defined > control statements (a property on a sub?) that can be used > in the "else" context. No. That would introduce a problem that Larry has said (back when I started learning perl 3.x) that he wanted to avoid from C: the mystery of bare-blocks. What I was proposing was that else could be followed by a block (as normal) or by a whole control structure, which could be a loop or conditional and might itself contain an else. There's no ambiguity because all blocks still require braces.
Re: What does this do?
On Fri, 2002-05-03 at 12:37, Larry Wall wrote:
> Piers Cawley writes:
> : Consider the following.
> :
> :sub foo {...}
> :
> :foo *@ary;
> :foo * @ary;
> :
> : Is this another place where whitespace will have meaning? Or should I
> : add parentheses to disambiguate? Enquiring minds want to know.
>
> I see no ambiguity. It's a unary * in either case. You'd have to
> declare it
>
> sub foo () {...}
>
> to get a multiply out of it.
Ok, I'm not going to say you're wrong (I most likely am), but I would
like to try to understand why this would be true.
The tokenizer is going to hand back what? 'bareword:foo', '*', 'type:@',
'identifier:ary'?
In which case, it seems to me that you would be right, but there's a big
trap Does that mean that if foo has the following:
sub foo();
sub foo($x,$y);
Then you always get multiply, or you always get argument expansion? Is
that going to be counter-intuitive for the programmer who uses a library
that provides such a definition?
FIRST, BETWEEN, etc.. (was Re: Loop controls)
I have been following this thread, but I would just like to inject a summary
of the various related UPPERCASE blocks
PREExecutes on block entry.
Loop variables are in a known state
POST Executes on block exit.
Loop variables are in a known state
NEXT Executes on implicit block exit or call to next()
Loop variables are in a known state
LAST Executes on implicit loop exit or call to last()
Loop variables may be unknown
And I think this thread is proposing
FIRST A PRE block that is executed only on the first itteration
of the loop
BETWEEN A PRE block that does not execute for the first iteration
of the loop.
So FIRST and BETWEEN are just shorthand for
my $count;
loop {
PRE {
if ($count++) {
# BETWEEN code here
}
else {
# FIRST code here
}
}
}
Graham.
perl6-language@perl.org
At 9:26 AM -0400 5/7/02, Aaron Sherman wrote: >On Mon, 2002-05-06 at 16:26, Dan Sugalski wrote: >> I forgot to announce the call for questions here (sorry), but the >> answers 9and the questions) to the first round of Ask The Parrot have >> been posted over on use.perl. >> http://use.perl.org/article.pl?sid=02/05/06/179233 for the interested. > >Some interesting items there. I'd like to ask a few follow-ups, but not >sure who the right audience is. For now, let's assume it's this list, >and not use.perl.org Fair enough. If things start getting big we can go for another round on use.perl. >On language features: How is it that Parrot is language-neutral, and yet >as a specific set of guarantees for destructors? Wouldn't those >assumptions be wrong for, say, Scheme or Python? Nope. Which isn't to say that it won't be the wrong way for other languages. >Also on that point, what of closures? Can those be managed in an >efficient, and yet language-neutral fashion? Absolutely. Closures are relatively simple, and very language neutral if you have a language that supports them. If your language doesn't, there's no way to take them so you're fine there too. >On the Perl5 handling: why do you need step 3? Specifically, why not >just continue to use the Perl5 parser as the Perl5 front-end for Perl6? >That should guarantee compatibility. Because I don't want to maintain the perl 5 parser codebase--I'd rather have a proper set of rules for the parser. It'll also be a potentially pleasantly futile task for someone to undertake when they want to learn the ins and outs of the parser. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What does this do?
Aaron Sherman writes:
: On Fri, 2002-05-03 at 12:37, Larry Wall wrote:
: > Piers Cawley writes:
: > : Consider the following.
: > :
: > :sub foo {...}
: > :
: > :foo *@ary;
: > :foo * @ary;
: > :
: > : Is this another place where whitespace will have meaning? Or should I
: > : add parentheses to disambiguate? Enquiring minds want to know.
: >
: > I see no ambiguity. It's a unary * in either case. You'd have to
: > declare it
: >
: > sub foo () {...}
: >
: > to get a multiply out of it.
:
: Ok, I'm not going to say you're wrong (I most likely am), but I would
: like to try to understand why this would be true.
:
: The tokenizer is going to hand back what? 'bareword:foo', '*', 'type:@',
: 'identifier:ary'?
It's not yet clear whether Perl 6 will actually have a tokenizer
separate from the parser.
: In which case, it seems to me that you would be right, but there's a big
: trap Does that mean that if foo has the following:
:
: sub foo();
: sub foo($x,$y);
:
: Then you always get multiply, or you always get argument expansion? Is
: that going to be counter-intuitive for the programmer who uses a library
: that provides such a definition?
Frankly, I don't know what that does yet, though obviously the
argumentless declaration cannot be allowed to disable the parsing of
other calls with arguments. Likely we'll just say that overloading a
name like that disables the argumentless bareword syntax, and you'd
have to explicitly pass zero arguments somehow. Some might argue that
we should just try to parse the long one and revert to the short one if
the long one fails to parse, but I'd like to avoid arbitrarily long
lookahead as much as possible.
Nevertheless, if, as planned, we use Perl 6 regexes to write the
parser, backtracking is a possibility. I just don't think this is a
good application for it. Some would argue there's never a good
application for it when it comes to computer languages, but I think
"computer" languages are misnamed. They're really human languages that
we translate to the real computer language of bits. And natural human
languages do make use of backtracking occasionally.
Larry
perl6-language@perl.org
At 10:11 PM -0700 5/6/02, Erik Steven Harrison wrote: >On Mon, 6 May 2002 16:26:16 > Dan Sugalski wrote: >>*Alot of good answers to questions* > >Appreciate the descent from the mountain to help clear things up down here. You're certainly welcome for the answers. (And while the internals list can be scary, or at least surreal, there aren't any mountains around to descend from. Honest) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Tue, May 07, 2002 at 03:15:48PM +0100, Graham Barr wrote:
>
> LAST Executes on implicit loop exit or call to last()
> Loop variables may be unknown
Not exactly "unknown". It's just that, in a few cases, their values may
have changed by the time the LAST block is executed.
> And I think this thread is proposing
>
> FIRST A PRE block that is executed only on the first itteration
>of the loop
>
> BETWEEN A PRE block that does not execute for the first iteration
>of the loop.
>
> So FIRST and BETWEEN are just shorthand for
>
> my $count;
> loop {
>PRE {
> if ($count++) {
># BETWEEN code here
> }
> else {
># FIRST code here
> }
>}
> }
Almost. What people are pushing for is more like:
BETWEEN A NEXT block that does not execute for the last iteration
of the loop.
my $count;
loop {
PRE {
unless ($count++) {
# FIRST code here
}
}
NEXT {
if () {
# BETWEEN code here
}
}
This may seem like a trivial difference at first glance, but it's a
matter of scope. The latter interpretation means that code such as:
for 1..3 -> $thing {
print $thing _ ", ";
BETWEEN {
print $thing _ "\n";
}
}
Will output:
1, 1
2, 2
3,
Not:
1, 2
2, 3
3,
Which seems intuitively right.
It's only with variables lexically scoped outside the loop and that
change values in the condition itself that we encounter Damian's
conundrum.
Allison
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Tue, May 07, 2002 at 12:27:08PM -0500, Allison Randal wrote:
> On Tue, May 07, 2002 at 03:15:48PM +0100, Graham Barr wrote:
> >
> > LAST Executes on implicit loop exit or call to last()
> > Loop variables may be unknown
>
> Not exactly "unknown". It's just that, in a few cases, their values may
> have changed by the time the LAST block is executed.
OK, unspecified.
>
> > And I think this thread is proposing
> >
> > FIRST A PRE block that is executed only on the first itteration
> > of the loop
> >
> > BETWEEN A PRE block that does not execute for the first iteration
> > of the loop.
> >
> > So FIRST and BETWEEN are just shorthand for
> >
> > my $count;
> > loop {
> >PRE {
> > if ($count++) {
> ># BETWEEN code here
> > }
> > else {
> ># FIRST code here
> > }
> >}
> > }
>
> Almost. What people are pushing for is more like:
>
> BETWEEN A NEXT block that does not execute for the last iteration
>of the loop.
IMO, it cannot. That is because you cannot always know if you are at
the end of a loop until you have executed the condition. Therefore BETWEEN
would have to be a PRE block.
> This may seem like a trivial difference at first glance, but it's a
> matter of scope. The latter interpretation means that code such as:
>
> for 1..3 -> $thing {
> print $thing _ ", ";
>
> BETWEEN {
> print $thing _ "\n";
> }
> }
>
> Will output:
> 1, 1
> 2, 2
> 3,
>
> Not:
> 1, 2
> 2, 3
> 3,
But consider when this is a while loop, how do you stop BETWEEN being
called before the last iteration.
> Which seems intuitively right.
Not to me :-)
Graham.
