On Thu, 19 Feb 2009, Daniel Ruoso wrote:
Em Qui, 2009-02-19 às 22:57 +1100, Timothy S. Nelson escreveu:
Interesting. I'm happy to assume that $root is allowed to be
Undefined, I think. But let me ask a question; were you to represent an
unrooted tree in a computer, how would you do it
On Thu, 2009-02-19 at 22:57 +1100, Timothy S. Nelson wrote:
> On Thu, 19 Feb 2009, Carl Mäsak wrote:
> > A tree is a graph without cycles.
That's insufficient. In fact, there are a number of ways that the
general concept of an acyclic graph must be constrained before you get
something you can cal
Em Qui, 2009-02-19 às 22:57 +1100, Timothy S. Nelson escreveu:
> Interesting. I'm happy to assume that $root is allowed to be
> Undefined, I think. But let me ask a question; were you to represent an
> unrooted tree in a computer, how would you do it so that, if you had to look
> around
On Thu, 19 Feb 2009, Carl Mäsak wrote:
Timothy (>), Moritz (>>):
Speaking of Tree, let me quote from IRC:
09:23 < masak> it's a bit unfortunate that the identifier 'Tree' is now
squatted by an internal class in Perl 6, which is not
general
enough to reprenest an arbit
Timothy (>), Moritz (>>):
>> Speaking of Tree, let me quote from IRC:
>>
>> 09:23 < masak> it's a bit unfortunate that the identifier 'Tree' is now
>> squatted by an internal class in Perl 6, which is not
>> general
>> enough to reprenest an arbitrary tree data structure.
...and this was too.
On Wed, 18 Feb 2009, Moritz Lenz wrote:
Hi,
Timothy S. Nelson wrote:
I'm not suggesting here that we specify the interfaces to all the
modules listed in the Camel book, or anything like that. Instead, I'm
suggesting that the S32 space be used for documen
Sorry, this was supposed to go to the mailing list.
On Wed, 18 Feb 2009, Timothy S. Nelson wrote:
After looking through the Phlanx project (which lists 100 or so top
perl modules), and the list in the Camel book, I can only see one or two
other
things we might eventually need,
Hi,
Timothy S. Nelson wrote:
> I'm not suggesting here that we specify the interfaces to all the
> modules listed in the Camel book, or anything like that. Instead, I'm
> suggesting that the S32 space be used for documenting the objects that we
> don't seem to be able to get away from.
Hi all. I'd like to suggest a slight reorganisation within the specs.
The first thing I've observed is that, in defining the IO stuff, and
adding in the Tree and DateTime stuff, is that we're getting a lot of non-IO
stuff in there.
I'm aware that the numbering and ordering of the s