Austin Hastings writes:
> Luke Palmer wrote:
>
> >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... :(
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 [EMAIL PROTECTED] ~~ 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
