Oh, I thought I replied, but now that I look over the question I guess I
didn't. The question was:
Austin Hasting writes:
> How do I concisely code a loop that reads in lines of a file, then
> calls mysub() on each letter in each line?
> Or each xml tag on the line?
And I guess the answer is the same as in Perl 5. I don't understand
what the problem is with Perl 5's approach:
for <> {
mysub($_) for .split: /<null>/;
}
Or:
use Rule::XML;
for <> {
mysub($_) for m:g/(«Rule::XML::tag»)/;
}
Luke
LP> use Rule::XML;
LP> for <> {
LP> mysub($_) for m:g/(«Rule::XML::tag»)/;
LP> }
shouldn't that be in the Grammar namespace? not that we have finalized
namespaces but i was under the impression that Grammar was reserved for
full parsing grammars as in Grammar::Perl.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
The only problem I have is that the $_ topic is reused and may cause
confusion. I'd probably have written it like so:
for <> -> $l {
mysub($_) for $l.split: /<null>/;
}
Except that I think the colon after C<split> isn't needed .... sure
enough, from A12 in the section entitled "The dot notation":
[Update: There is no colon disambiguator any more. Use parens if
there are arguments. (However, you can pass an adverbial block
using :{} notation with a null key. That does not count as an
ordinary argument.)]
So, I guess I'd write it as
for <> -> $l {
mysub($_) for $l.split(/<null>/);
}
-Scott
--
Jonathan Scott Duff
du...@pobox.com
>Austin Hasting writes:
>
>
>>How do I concisely code a loop that reads in lines of a file, then
>>calls mysub() on each letter in each line?
>>Or each xml tag on the line?
>>
>>
>
>And I guess the answer is the same as in Perl 5. I don't understand
>what the problem is with Perl 5's approach:
>
> for <> {
> mysub($_) for .split: /<null>/;
> }
>
>Or:
>
> use Rule::XML;
> for <> {
> mysub($_) for m:g/(«Rule::XML::tag»)/;
> }
>
My problem with this is one of abstraction. P6 is, in a lot of places, a
giant step forward in terms of abstracting away 'well-understood'
operations. Grammar/Regex is one example, properties another.
I'd like to see a similar, simple notation for expressing composite
operations. Perhaps this is a macro thing, but macros are still a little
fuzzy to me (and I have these horrid memories from Lisp... :(
In general, though, this ties back to my long-ago wish for "separable
verb" syntax support: I'd like to see a relatively concise, expressive
notation for doing something like a double-loop or arbitrary traversal.
The outer product was a delightful example of this kind of thinking --
it's obviously code, but it's totally data-driven.
Iterators may provide some of this, of course. But they provide it in
scenarios where the data structure has been "comprehended" beforehand.
Dynamic comprehension, if such a phrase can exist, is the obvious next
step in DWIMmery.
Given a Tree, or a Trie, or a AvlTree, or a RBTree, it's easy to figure
out what $CLASS->getIterator() is going to do. But what's the right way
to traverse a C source file? In preprocessor mode it's one thing, in
lexer mode it's another.
Is it possible to talk about an iteration template? Say I've got a list
of numbers, but I want to iterate only the primes. Something like:
class PrimeNumberIterator
is Iterator
{
method _is_prime() {...}
method .next()
{
my $cand;
$cand = SUPER::next() while !_is_prime($cand);
return $cand;
}
}
How do I impose that iteration scheme?
for @list -> $x is PrimeNumberIterator { say $x ; }
Does that work?
Anyway, the point is that we as humans can say things like "look at all
the prime numbers in the list ...", so I would like to see a similar
level of expressivity in P6. I think P6l was heading that way some time
ago, but we got sidetracked by an Apocalypse. :)
Maybe Larry's concept of 'type' has a place here? (Remember that 'type'
was described as a restriction of 'class', such that 'odd number' is a
type that restricts 'number'.)
Would
for @list -> $x is Prime { say $x ; }
work? What about
for [@list ~~ Prime ] -> $x { say $x; }
(That last one is really hard to read -- it would wind up demanding a
layer of sugar...)
But if type is the only way to do filtering, then we'll wind up with a
metatype mechanism for defining types on the fly, so ...
=Austin
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.12 - Release Date: 1/14/2005
Maybe so. I wasn't under the impression that we had reserved anything
yet. Go ahead and define your subs wherever you want and don't worry
about name conflicts. Perl 6 knows what you mean. It's the computer
that messes up.
Luke
Usually micro things are the things that are fuzzy. I just hope
Junctions get along with your macro thing; macro is quite the opposite
of their natural habitat.
> In general, though, this ties back to my long-ago wish for "separable
> verb" syntax support: I'd like to see a relatively concise, expressive
> notation for doing something like a double-loop or arbitrary
> traversal. The outer product was a delightful example of this kind of
> thinking -- it's obviously code, but it's totally data-driven.
Yes, I'm all for abstractions that let you avoid writing your own little
virtual machine to traverse something. But the fact that your sentence
("... calls mysub() on each letter in each line") says "each" twice is a
hint that some kind of loop should be appearing twice lexically.
> Given a Tree, or a Trie, or a AvlTree, or a RBTree, it's easy to
> figure out what $CLASS->getIterator() is going to do.
It is? Does it do left-right pre-order, right-left in-order, up-down
spin-order? One of my algorithms needs a left-right preorder and a
right-left preorder of the same tree at the same time.
> But what's the right way to traverse a C source file? In preprocessor
> mode it's one thing, in lexer mode it's another.
My point is that there are a lot of ways to traverse a lot of things.
The appearance of coroutines (and hopefully Parrot's eventual allowance
to use them in vtable methods, ugh) is going to make traversals nice.
So my partial ordering algorithm looks something like:
my @lr := Iterator.new($mytree) :{
yield $_;
&?BLOCK($_) for .children;
};
my @rl := Iterator.new($mytree) :{
yield $_;
&?BLOCK($_) for reverse .children;
};
for @lr ¥ @rl ¥ 0...
-> $lnode, $rnode, $count {
$lnode.lindex = $rnode.rindex = $count;
}
This is a full implementation; it counts only on a very trivial Node
class, which might as well be a hash. I think that's about as nice as
possible.
> Is it possible to talk about an iteration template? Say I've got a list
> of numbers, but I want to iterate only the primes. Something like:
>
> class PrimeNumberIterator
> is Iterator
> {
> method _is_prime() {...}
> method .next()
> {
> my $cand;
> $cand = SUPER::next() while !_is_prime($cand);
> return $cand;
> }
> }
I think iterators are just lists, albeit ones that aren't sure of their
own future.
> How do I impose that iteration scheme?
>
> for @list -> $x is PrimeNumberIterator { say $x ; }
>
> Does that work?
I have no idea why that would work. You could:
multi is_prime(Int $int) {...}
say for grep { .is_prime } 0...;
Or if you're into making nice packaged up little iterators, you could:
say for PrimeNumberIterator.new;
But this is all very up in the air. We've understood for a little while
that @ and % don't mean very much anymore, so we'd like to come up with
new meanings that don't change their usage very much. I'm thinking @
means @rdered or something.
> Maybe Larry's concept of 'type' has a place here? (Remember that 'type'
> was described as a restriction of 'class', such that 'odd number' is a
> type that restricts 'number'.)
>
> for [@list ~~ Prime ] -> $x { say $x; }
(That loop runs once, with $x set to your anonymous array)
Or even:
for @list.grep(Prime) { say }
(Assuming grep takes anything that a smart match does)
> (That last one is really hard to read -- it would end up demanding a
> layer of sugar...)
>
> But if type is the only way to do filtering, then we'll wind up with a
> metatype mechanism for defining types on the fly, so ...
Oh, I'm planning that anyway.
For the interested, I'm working on a module called Class::Abstract which
is going to implement something very similar to Perl 6's object
semantics. Where it differs, well, that's the point of the module: I
hope Perl 6 will come to me :-).
That essentially means that I'm very interested in this notion of "type"
these days. If people have ideas about it, like this filtering stuff, I
encourage them to talk about it.
I think in the local context "grep" acts as a pretty solid universal
filter. However, you can define subtypes that talk about particular
values and then use them in multimethods.
Luke