Re: Does this mean we get Ruby/CLU-style iterators?
On Fri, Jan 18, 2002 at 08:03:41PM -0800, Larry Wall wrote:
: allow this:
:
: File.foreach('/usr/dict/words') { print }
File.foreach('/usr/dict/words', { print })
or even (presuming the prototype is available for parsing):
File.foreach '/usr/dict/words' { print }
Now I'm a little confused. The apoc talked about writing your own
while loop. A while loop looks like:
while($something) { do_this }
and a custom while loop would have to be
mywhile($something) { do_this }
and it doesn't seem much of a stretch for
Class.method($something) { do_this }
or is that what you ment by ignoring parser issues?
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Death was thought to be fatal.
-- Craig A. Berry in a05101002b8165afc6b62@[172.16.52.1]
Apoc4 - A little wish
Hi all,
I have just one syntatic wish for Apoc4 (which in all other points I
find utterly fantastic).
Could we have:
foreach $item in @arr {...}
Instead of
foreach @arr - $item {...}
I find the first one:
- Much more pleasent to the eyes and less noisy on a long program.
- Easier for the newcomer to get the meaning.
- More similar to perl5's foreach $item (@arr), since at least we
preserve the order.
The multi-array foreaching could become:
foreach $item; $other in @arr; @otherarr {...} # as in Apoc4
Or maybe
foreach $item in @arr; $other in @otherarr {...}
On a totally different level of foreaching:
¿are we going to have a iterator protocol? I am talking of python's
iterators, not ruby ones (which are being discussed in a different
post). The iterator protocol allows any object that implements a .next
method to be used in a foreach loop. This is very handy for things like
filehandles, recordsets, generators, coroutines and nearly any data
structure you can imagine.
For example, filehandles can implent the iterator protocol out of the
box, so you can write:
foreach $line in $fh {print $line}
Or maybe:
foreach $line in $fh.lines {print $line}
Where $fh.lines is an object that implements the iterator protocol, not
an array of the lines (and thus much more efficient).
There was something about this in Apoc2, but I didn't get a clear
concolusion of it. The are a lot of useful applications of python-like
iterators, and perl6 is doing a great job of taking the coolest things
of other languages and integrating them into a choerent design, so i do
have a hope. [:)]
This is of course related to Ruby's iterators, that take a somehow
opposite solution to solve a similar problem.
-
Angel Faus
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Re: Apoc4 - A little wish
Sorry for the 4 times posts, i was testing a new mail program and it didn't prove too good. Now i feel so ashamed :-[ -angel
Re: Apoc4 - A little wish
Angel == Angel Faus [EMAIL PROTECTED] writes:
Angel Hi all,
Angel I have just one syntatic wish for Apoc4 (which in all other points I
Angel find utterly fantastic).
Angel Could we have:
Angel foreach $item in @arr {...}
Angel Instead of
Angel foreach @arr - $item {...}
Larry considered that, and declined. Not sure of the reasons.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Apoc4: When do I put a semicolon after a curly?
The two current examples of an evil expression block are do {} and eval {},
which require a semicolon terminator. However, with eval {} leaving, that
leaves just do {}, which does (or should) fall more in line of thinking of
grep {}, map {}, and sort {}: the other expression blocks. For do {}, the
block just happens to be the only (and therefore, trailing) argument. (In
other words, from an language perspective, do {} really should be presented
more as 'do' and less as '{}'. Much of the block confusion came from the
specialization of do-while and do-until. But both of these are illegal in
Perl 6, so there's no longer a reason to propagate that misconception.)
With try {} appearing to be a proper block, that would leave do {} the only
beneficiary of the Lone Bracket hack. (For now. I continue this below.)
So, in essence, you are trading you need to remember that do {} is just an
expression, treat is as such to do {} is an expression. You can write it
as a block (as long as the close bracket is on a line by itself), and we'll
tack on the semicolon for you, but don't write it as a block when you want
an expression, unless you put the rest of the expression on the same line as
the bracket. Although each individual rule is simple, the overall
semantics have become quite complex for such a small subsection of the
language. And attempting to leverage that against a lone bracket, I feel is
a mistake. From a linguistical perspective, that seems to be more
presentationally based, rather than contextual.
Most everything in Perl is done in context, so why not leverage that
instead? After all, the semi-colon will be needed to terminate an anonymous
hash assignment, yes?
my $ahash = {
foo = bar
};
It seems to me that when people use a block as a code block, they simply
don't make it do expressionish things. Like capture the return
value. Blocks are almost always - there are always Damians in the world -
used in a void context.
my $a = do {
}
No, it's not a block, it's an expression. It shouldn't even be presented as
a potential block. You've a do {} in the midst of a long string of things,
it shouldn't terminate simply because I'm formatting for clarity.
do {
...
}
could be a block. Particularly now that base blocks are forbidden, this
will be a block. The question is whether the expression continues
afterwords:
+ 1 for @x;
The parser should be able to determine whether the expression continues
on the next line. You either get an operator or a statement modifier, or
the block is terminated. But for the user who has to remember all the rules,
there's nothing to do. He just writes it. Contextual. Not presentational.
The Apo surmises that some other blocks may become expression blocks,
such as BEGIN {}. I assume CHECK {} and INIT {}, as well? END {} doesn't
make sense. How about any of the new blocks?
Now, you've added even more special cases to the semi-colon rule.:
BEGIN { foo() };
END { foo() }
Some will take them - sometimes - and others won't, at all. Sure, you could
always put a semicolon there, and create a null statement, but you don't do
that now, so why should you start?
Once again, I think the void contextual clues should be differentiating
between block and expression usage. Perl already exprects you to understand
differing behavior in void, scalar, and list context, and Perl 6 is expected
to add more. Why not continue in that direction here, instead of veering
off in some strange direction.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Apoc4: Parentheses
QUOTE
Interestingly, this one tweak to the whitespace rule also means that we'll
be able to simplify the parentheses out of other similar built-in constructs:
if $foo { ... }
elsif $bar { ... }
else { ... }
while $more { ... }
for 1..10 { ... }
I think throwing out two required punctuation characters for one required
whitespace is an excellent trade in terms of readability, particularly when
it already matches common practice. (You can still put in the parens if you
want them, of course, just for old times' sake.)
/QUOTE
Since the parentheses are no longer required, will the expressions lose or
retain their own scope level? (I'm assuming that whatever rule applies, it
will hold true if you do elect to use parantheses anyway.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Apoc4: The loop keyword
No examples are given, but are we to assume that this:
for ($x = 0; $x 100; $x++) {
...
}
becomes this:
loop $x=0; $x 100; $x++ {
...
}
How would you use an $x lexically scoped to the loop block?
Most of the other constructs seem to be using a '- $x' construct.
loop my $x=0; $x 100; $x++ {
...
}
?
--
Bryan C. Warnock
[EMAIL PROTECTED]
Apoc4: 'when' blocks versus statements
Why the double semantics of 'when'?
It implicitly breaks when used as a 'when' block, but does not as a 'when'
statement. It seems that a when should be a when should be a when, and a
when being a when would be a win.
The example given:
given $x {
warn(Odd value)when !/xxx/;
warn(No value), break when undef;
when /aaa/ { break when 1; ... }
when /bbb/ { break when 2; ... }
when /ccc/ { break when 3; ... }
}
could be written as:
given $x {
warn(Odd value), skip when !/xxx/;
warn(No value) when undef;
when /aaa/ { break when 1; ... }# No reason you can't
when /bbb/ { break when 2; ... }# explicitly break even when
when /ccc/ { break when 3; ... }# you'd implicitly
}
or even:
given $x {
warn(Odd value) if !/xxx/; # Since $_ is the localizer
warn(No value) when undef;
when /aaa/ { break if 1; ... }
when /bbb/ { break if 2; ... }
when /ccc/ { break if 3; ... }
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Apoc 4?
On Fri, 18 Jan 2002 12:33:48 -0500, Will Coleda wrote: http://www.perl.com/pub/a/2002/01/15/apo4.html David Whipp wrote: Michael G Schwern wrote: Reading this in Apoc 4 ... I looked on http://dev.perl.org/perl6/apocalypse/: no sign of Apoc4. Where do I find this latest installment? I thought I had just missed it... but there's no trace of it in the archives of [EMAIL PROTECTED]. Or any other perl6 list. Don't tell me that is normal. -- Bart.
Re: Apoc4: When do I put a semicolon after a curly?
You're treating do, if, foreach as if they were keywords. I'm not entirely sure that that's still the case. And you're also forgetting the possibility of user implemented control type operators/methods. Unless I'm very much mistaken you're suggesting that we special case the parser for 'do' and any user defined functions that take a block can go hang. Which I'm really not keen on. -- 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: Apoc4: When do I put a semicolon after a curly?
On Saturday 19 January 2002 12:24, Piers Cawley wrote:
You're treating do, if, foreach as if they were keywords. I'm not
entirely sure that that's still the case.
'do' perhaps. But not really. And it's irrelevant to my argument.
And you're also forgetting
the possibility of user implemented control type operators/methods.
No, I'm not. As a matter of fact, I had even wrote a section on
user-defined constructs, only to find that my arguments were exactly the
same, so I removed it as superfluous.
Unless I'm very much mistaken you're suggesting that we special case
the parser for 'do' and any user defined functions that take a block
can go hang. Which I'm really not keen on.
Then you're very much mistaken. :-)
I'm saying that if you're going to DWIM an expression as a block, do it
based on the expression being used in the standard context of a block,
rather than the fact that the trailing '}' appears on a line by itself. In
other words, I'm very much for Larry's idea. Just put the burden on the
parser, rather than on the parser and the person.
That applies to *any* expressionish block - do, BEGIN, INIT, sub (sort of),
the old eval which is now gone, or a user-defined one. I simply picked on
do {} and BEGIN {} because they were the examples given in the Apocalypse.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Apoc 4?
* Bart Lateur ([EMAIL PROTECTED]) [20 Jan 2002 03:56]: On Fri, 18 Jan 2002 12:33:48 -0500, Will Coleda wrote: http://www.perl.com/pub/a/2002/01/15/apo4.html [...] I thought I had just missed it... but there's no trace of it in the archives of [EMAIL PROTECTED]. Or any other perl6 list. Don't tell me that is normal. It's a worry. Also odd is that Slashdot hasn't picked it up yet. I don't know about most people, but I saw the announcement on http://use.perl.org/ cheers, -- iain. http://eh.org/~koschei/
Re: Apoc 4?
On Saturday 19 January 2002 12:20, iain truskett wrote: * Bart Lateur ([EMAIL PROTECTED]) [20 Jan 2002 03:56]: On Fri, 18 Jan 2002 12:33:48 -0500, Will Coleda wrote: http://www.perl.com/pub/a/2002/01/15/apo4.html [...] I thought I had just missed it... but there's no trace of it in the archives of [EMAIL PROTECTED]. Or any other perl6 list. Don't tell me that is normal. It's a worry. Also odd is that Slashdot hasn't picked it up yet. Developers' section. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Apoc 4?
At 1:14 PM -0500 1/19/02, Bryan C. Warnock wrote: On Saturday 19 January 2002 12:20, iain truskett wrote: * Bart Lateur ([EMAIL PROTECTED]) [20 Jan 2002 03:56]: On Fri, 18 Jan 2002 12:33:48 -0500, Will Coleda wrote: http://www.perl.com/pub/a/2002/01/15/apo4.html [...] I thought I had just missed it... but there's no trace of it in the archives of [EMAIL PROTECTED]. Or any other perl6 list. Don't tell me that is normal. It's a worry. Also odd is that Slashdot hasn't picked it up yet. Developers' section. No wonder nobody noticed. There seems to be an awful lot of actually interesting stuff over there. How atypically slashdot... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Perl 6, now with 50% more NATO!
This just popped up from my sig file:
Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in Ada
the typical infinite loop would be normally be terminated by detonation.
-- Larry Wall in [EMAIL PROTECTED]
which, of course, we'll have in Perl 6:
loop {
.search .DESTROY;
}
Larry Wall: puppet of the military-industrial complex? Next on The
Conspiracy Zone. ;)
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
MERV GRIFFIN!
[A-Z]+\s*\{
Is this list of special blocks complete and correct? BEGIN Executes at the beginning of compilation CHECK Executes at the end of compilation INITExecutes at the beginning of run END Executes at the end of run PRE Executes at beginning of block entry POSTExecutes at end of block entry NEXTExecutes on call to next() within current block CATCH Executes on exception within current block KEEPExecutes on normal exit of the current block UNDOExecutes on un-normal exit of the current block --Brent Dax [EMAIL PROTECTED] Parrot Configure pumpking and regex hacker obra . hawt sysadmin chx0rs lathos This is sad. I know of *a* hawt sysamin chx0r. obra I know more than a few. lathos obra: There are two? Are you sure it's not the same one?
Re: [A-Z]+\s*\{
On Saturday 19 January 2002 22:05, Brent Dax wrote: Is this list of special blocks complete and correct? BEGIN Executes at the beginning of compilation CHECK Executes at the end of compilation INITExecutes at the beginning of run END Executes at the end of run PRE Executes at beginning of block entry POSTExecutes at end of block entry NEXTExecutes on call to next() within current block CATCH Executes on exception within current block KEEPExecutes on normal exit of the current block UNDOExecutes on un-normal exit of the current block That matches my list. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: [A-Z]+\s*\{
On Saturday 19 January 2002 22:05, Brent Dax wrote: Is this list of special blocks complete and correct? BEGIN Executes at the beginning of compilation CHECK Executes at the end of compilation INIT Executes at the beginning of run END Executes at the end of run PRE Executes at beginning of block entry POST Executes at end of block entry NEXT Executes on call to next() within current block CATCH Executes on exception within current block KEEP Executes on normal exit of the current block UNDO Executes on un-normal exit of the current block - LAST (Per Damian's last (LAST/POST) post.) - FIRST? (Symmetry.) - ALWAYS? (Another plausible addition. Rounds out PRE and POST with invariant assertions that get checked twice, once at the time PRE does, once at the time POST does. Personally I'd leave this out until it became clear, well past p6.0, whether it was really worth it, but it seems worth mentioning.). --me
