Re: Iterating over complex structures
On 12/22/05, Michele Dondi [EMAIL PROTECTED] wrote: Suppose I want to navigate a tree and print out info contained in each of its leaves along with info gathered from the position in the tree of the list itself? Can I do it in a universal manner as hinted above that would work for other situations as well? In Ruby, each collection class that wishes to be iterated over mixes in the Enumerable class. In a crude way, you can almost use that as the definition of what makes an class a collection. All the class has to provide is each(), which is a method that, according to the Ruby book, yields successive members of the collection. If the class wishes to use the sorting items, then it has to provide a meaningful spaceship operator. each() (and a number of other methods) then takes a block that it executes at every node. As everything in Perl6 will be an object, I think we should be looking at Ruby for possible solutions to this kind of problem. The Ruby way, imho, would be to provide a set of each() methods that you can choose to use, depending on how you wanted to iterate over the object. The each() method you choose could maintain some kind of state about where the element is in the collection. Or, and this would be my preference, the elements should have the ability to return that state when queried. This implication here is that there should be an Enumerable role (or set of roles) in Perl6 that provides this kind of capability. In addition, there should probably be a useful set of base classes to do things like Set, Bag, Tree, etc. Then, if I wanted to create a 3-2 tree which only takes values that is-a Floober and default to iterating over it in level-order, I can do that in less than 20 lines of code within a class. Then, I use that class when I want to use my arbitrary data structure. The further implication of this is that I don't think we will be using AoHoAoHo... in applications anymore. In 1-off scripts, sure! But, we'll have the infrastructure to create usable classes that abstract away 90% of the complexity of our data structures, allowing us to focus on the similarities in our code vs. the differences. Ruby takes duck-typing to a religious mantra, which can be annoying, but it's definitely very productive. Perl6 could do worse than copying that to a large degree. Of course, this doesn't work for arbitrary complex structures, but I don't think anything would work for those. Rob
Re: Iterating over complex structures
But in Perl 5 to navigate complex structures one needs ad-hoc
solutions. I wonder if something is planned in Perl 6 as a means to do
that through a syntactically convenient construct with ad-hoc-isms
pluggable in in the form of suitable hooks (e.g. .on_node( { code; ... }
), etc.) that would work in most cases.
I've got some Perl 5 code that tries to do this:
http://search.cpan.org/~bowmanbs/Data-Rmap-0.61/lib/Data/Rmap.pm
Simple things are fine but path or relationship based transformations
turn into a mess.
Brad
--
There are times when a person gets carried away and talks on without
thinking too much. But this can be seen by observers when one's mind is
flippant and lacking truth. -- Hagakure http://bereft.net/hagakure/
Re: Iterating over complex structures
Well, @Larry has been researching attribute grammars for a month or two now, which are an efficient (programmer-wise, not necessarily processor-wise) method for specifying computations over trees. The only syntax we've seen is that of Language::AttributeGrammar and TGE, whose roots come from UUAG. But I'd love to come up with a syntax that feels more integrated into the language. There's a formal treatment of someone's effort to generalize regular expressions to trees here (PhD included): http://cnds.ucd.ie/~cetus/home/publications.html I don't know how this approach relates to attribute grammars. Hope the link might be useful, Brad -- ... But even a person who is good for nothing and exceedingly clumsy will be a reliable retainer if only he has the determination to think earnestly of his master. Having only wisdom and talent is the lowest tier of usefulness. -- Hagakure http://bereft.net/hagakure/
Iterating over complex structures
In Perl 5 Cfor is quite natural for iterating over lists and arrays.
Cwhile is preferred for filehandles. With lazy evaluation this
difference has been eliminated in Perl 6 so that while still TMTOWTDI
(TAEMWTDI!) this kind of iterations will be more consistent.
But in Perl 5 to navigate complex structures one needs ad-hoc solutions.
I wonder if something is planned in Perl 6 as a means to do that through a
syntactically convenient construct with ad-hoc-isms pluggable in in the
form of suitable hooks (e.g. .on_node( { code; ... } ), etc.) that would
work in most cases.
Please do not ask me what I have in mind, for I'm not really sure. I know
in advance that suitable modules may be written instead but I would like a
single builtin keyword. And I'd like to hear the opinion of the
Knowledgeable Ones(TM) here.
Suppose I want to navigate a tree and print out info contained in each of
its leaves along with info gathered from the position in the tree of the
list itself? Can I do it in a universal manner as hinted above that
would work for other situations as well?
PS: By complex structure here I mean a [AH]o[AH]o[AH]... or somesuch
with arbitrary nesting levels. Objects would do if they had sufficient
navigational info (e.g. parent(), next(), havechild(), etc.) i.e. if they
conformed to some probably not yet established interface.
Michele
--
I wish Sun would sort their versioning out
and have their marketing department shot.
- tomazos in PerlMonks.
Re: Iterating over complex structures
On 12/22/05, Michele Dondi Please do not ask me what I have in mind, for I'm not really sure. Well, @Larry has been researching attribute grammars for a month or two now, which are an efficient (programmer-wise, not necessarily processor-wise) method for specifying computations over trees. The only syntax we've seen is that of Language::AttributeGrammar and TGE, whose roots come from UUAG. But I'd love to come up with a syntax that feels more integrated into the language. However, the problem with integrating attribute grammars into the language is that you might not know when to clean up attributes, which is extremely important. However it is integrated, it must use proper scoping and no dynamic access so that we can clean things up before the computation is done. The other problem comes from what you were talking about. You don't print things with attribute grammars, because the optimal evaluation order is quite unpredictable. You'd have to build up a string (or, say, an IO monad ;-) and print it after the computation completes. I do wonder if there is a monadey thing that we can do to make it feel like the evaluation order was predictable. Luke
