Perl and *ML
Dan Sugalski
as it is good support for attributed DAGs, something which would be
of general good use for perl, since the ASTs the parser feeds to the
compiler will ultimately be DAGs of a sort.
So, rather than jumping on the "XML [insert verb here]!" bandwagon,
perhaps we'd be better served figuring out what would be useful
operations and support for/on DAGs and suchlike things?
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Robin Berjon
> I think that the issue here isn't so much good perl support for XML as
> it is good support for attributed DAGs, something which would be of
> general good use for perl, since the ASTs the parser feeds to the
> compiler will ultimately be DAGs of a sort.
>
> So, rather than jumping on the "XML [insert verb here]!" bandwagon,
> perhaps we'd be better served figuring out what would be useful
> operations and support for/on DAGs and suchlike things?
Fast and efficient graphs of all sorts would be very useful. A way to define a
complex graph of interlinked arbitrary objects while being reasonable on memory
and good with GC would be a definitive big win, especially if it can be lazy.
Especially with nice ways to write visitors and easy searches in the graph based
on object properties (but I could be asking for too much ;).
DAGs wouldn't enough though, most XML tree representations aren't really trees,
they're very cyclic. Some automata can treat a stream of events as a B-Tree
being visited, but those are rather rare currently.
--
Robin Berjon <robin....@expway.fr>
Research Engineer, Expway http://expway.fr/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Kurt Starsinic
> Dan Sugalski wrote:
> >I think that the issue here isn't so much good perl support for XML as
> >it is good support for attributed DAGs, something which would be of
> >general good use for perl, since the ASTs the parser feeds to the
> >compiler will ultimately be DAGs of a sort.
++good
> >So, rather than jumping on the "XML [insert verb here]!" bandwagon,
> >perhaps we'd be better served figuring out what would be useful
> >operations and support for/on DAGs and suchlike things?
>
> Fast and efficient graphs of all sorts would be very useful. A way to
> define a complex graph of interlinked arbitrary objects while being
> reasonable on memory and good with GC would be a definitive big win,
> especially if it can be lazy. Especially with nice ways to write visitors
> and easy searches in the graph based on object properties (but I could be
> asking for too much ;).
>
> DAGs wouldn't enough though, most XML tree representations aren't really
> trees, they're very cyclic.
Pardon me? Could you please provide an example?
- Kurt
Dan Sugalski
>Dan Sugalski wrote:
>>I think that the issue here isn't so much good perl support for XML
>>as it is good support for attributed DAGs, something which would be
>>of general good use for perl, since the ASTs the parser feeds to
>>the compiler will ultimately be DAGs of a sort.
>>
>>So, rather than jumping on the "XML [insert verb here]!" bandwagon,
>>perhaps we'd be better served figuring out what would be useful
>>operations and support for/on DAGs and suchlike things?
>
>Fast and efficient graphs of all sorts would be very useful. A way
>to define a complex graph of interlinked arbitrary objects while
>being reasonable on memory and good with GC would be a definitive
>big win, especially if it can be lazy. Especially with nice ways to
>write visitors and easy searches in the graph based on object
>properties (but I could be asking for too much ;).
Probably a bit much, yep. :) I'd be happy with simple graph
representation, annotation, and traversal. And for my purposes a DAG
is sufficient. Loops are terribly annoying to have to deal with.
>DAGs wouldn't enough though, most XML tree representations aren't
>really trees, they're very cyclic. Some automata can treat a stream
>of events as a B-Tree being visited, but those are rather rare
>currently.
I was under the impression XML was very much a tree, and didn't do
loops. Am I missing something here? (I don't, in general, do XML)
Paul
Hi all.
I note that quite often I find myself wanting to express agreement or
disagreement with some point made on the list, but without anything of
value to add other than a vote on the matter. When this happens I
usually ~try~ to bite my metaphorical tongue and just file the
information away while deleting the message, at least until I can
contribute meaningfully.
I wonder at times, however, if a simple vote of yea or nay might
actually count for something here. I know Larry and the design team are
lurking even when not interjecting, and I trust and admire their
collective judgement on these matters, and know that they will consider
all arguments, but that they will also consider opinions when there is
no overriding and conclusive reason to decide a matter one way or the
other. (Though I am damned *glad* that Larry is more interested in
what's good for me than in what I *think* is good for me, lol....)
I was just wondering if the occasional "me, too" was appropriate if I
feel strongly about something, but have nothing to actually *add* that
hasn't already been said. I really hate to spam a productive list.
Any input or comments welcome, though you may feel free to email me
off-list if it's more appropriate. ;o]
Paul
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Robin Berjon
> At 4:47 PM +0100 3/26/03, Robin Berjon wrote:
>> Fast and efficient graphs of all sorts would be very useful. A way to
>> define a complex graph of interlinked arbitrary objects while being
>> reasonable on memory and good with GC would be a definitive big win,
>> especially if it can be lazy. Especially with nice ways to write
>> visitors and easy searches in the graph based on object properties
>> (but I could be asking for too much ;).
>
> Probably a bit much, yep. :) I'd be happy with simple graph
> representation, annotation, and traversal. And for my purposes a DAG is
> sufficient. Loops are terribly annoying to have to deal with.
Efficient annotation and traversal would go a long way, but almost all useful
XML representations have loops unfortunately.
>> DAGs wouldn't enough though, most XML tree representations aren't
>> really trees, they're very cyclic. Some automata can treat a stream of
>> events as a B-Tree being visited, but those are rather rare currently.
>
> I was under the impression XML was very much a tree, and didn't do
> loops. Am I missing something here? (I don't, in general, do XML)
Your impression isn't wrong, it's just that in actual use one needs more
information. If you lose the cycles then you could as well just be working on
stream of parse events (which is typical in SAX), in which case an in-memory
representation is probably not useful. And that's just for basic stuff, if you
want to usefully represent ID/IDREFs, QName linking, internal XLinks, etc you're
basically pointing from random nodes to other random nodes.
Given what you describe plus loops we could take over and do Really Cool Stuff :)
Jonathan Scott Duff
> I was just wondering if the occasional "me, too" was appropriate if I
> feel strongly about something, but have nothing to actually *add* that
> hasn't already been said. I really hate to spam a productive list.
>
> Any input or comments welcome, though you may feel free to email me
> off-list if it's more appropriate. ;o]
I stay mostly silent because I don't think that "me too" posts have
any added value. However, if I agree or disagree with something and
have a different perspective on why, I'll post "me too and here's
why". (This doesn't happen often for me because by the time I've
read the messages, usually the idea space has been well explored)
-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu
Piers Cawley
> Hi all.
>
> I note that quite often I find myself wanting to express agreement or
> disagreement with some point made on the list, but without anything of
> value to add other than a vote on the matter. When this happens I
> usually ~try~ to bite my metaphorical tongue and just file the
> information away while deleting the message, at least until I can
> contribute meaningfully.
I think it's worth saying 'me too' to something if it's sat there with
no responses for a couple of days. If only to help the poster (and
summarizer, he said selfishly) of the horns of Warnock's Dilemma. If
there's ongoing debate then it's unnecessary.
--
Piers
Stéphane Payrard
> Dan Sugalski wrote:
> >At 4:47 PM +0100 3/26/03, Robin Berjon wrote:
> >>Fast and efficient graphs of all sorts would be very useful. A way to
> >>define a complex graph of interlinked arbitrary objects while being
> >>reasonable on memory and good with GC would be a definitive big win,
> >>especially if it can be lazy. Especially with nice ways to write
> >>visitors and easy searches in the graph based on object properties
> >>(but I could be asking for too much ;).
> >
> >Probably a bit much, yep. :) I'd be happy with simple graph
> >representation, annotation, and traversal. And for my purposes a DAG is
> >sufficient. Loops are terribly annoying to have to deal with.
>
> Efficient annotation and traversal would go a long way, but almost all
> useful XML representations have loops unfortunately.
>
> >>DAGs wouldn't enough though, most XML tree representations aren't
> >>really trees, they're very cyclic. Some automata can treat a stream of
> >>events as a B-Tree being visited, but those are rather rare currently.
> >
> >I was under the impression XML was very much a tree, and didn't do
> >loops. Am I missing something here? (I don't, in general, do XML)
By loop you mean attributes declared by DTD as IDREFs and pointing to
element having the same value for the attribut ID? Like in the example
pasted from "XML in a nutshell"?
<project project_id="p1">
<goal>Develop Strategic Plan</goal>
<team_member person="ss078-05-1120"/>
<team_member person="ss987-65-4320"/>
</project>
<project project_id="p2">
<goal>Deploy Linux</goal>
<team_member person="ss078-05-1120"/>
<team_member person="ss9876-12-3456"/>
</project>
<employee social_security_label="ss078-05-1120">
<name>Fred Smith</name>
<assignment project_id="p1"/>
<assignment project_id="p2"/>
</employee>
<employee social_security_label="ss987-65-4320">
<name>Jill Jones</name>
<assignment project_id="p1"/>
</employee>
<employee social_security_label="ss9876-12-3456">
<name>Sydney Lee</name>
<assignment project_id="p2"/>
</employee>
In a way IDREF are similar to symlinks? they cannot create "real loops"
because they are not followed by default by traversal tool juste like
find does not follow symlinks by default.
--
stef
Robin Berjon
> On Wed, Mar 26, 2003 at 05:40:56PM +0100, Robin Berjon wrote:
>>Efficient annotation and traversal would go a long way, but almost all
>>useful XML representations have loops unfortunately.
>
> element having the same value for the attribut ID?
>
> because they are not followed by default by traversal tool juste like
> find does not follow symlinks by default.
Part of the problem doesn't involve referencing. Practically all XML
representations will have at the very least children pointing back to their
parents, and probably more than just that.
Another part of the problem is that, indeed IDREFs, QName links, internal
XLinks, or other referencing approaches can be treated as symlinks and in fact
more or less currently are. However that's often suboptimal/inefficient to
implement because either you point to the target (in which case you have a
cycle) or you have to look for it. If we want to make things better than they
are currently, that kind of loop needs to be simple and efficient.
Robin Berjon
XML per se, using an impoverished Information Set (no IDs) can be considered to
be a tree, which would naturally make it a DAG.
However that's pretty much an abstract representation that is rarely of much use
in actual XML programming. In your typical DOM, children point to their parent,
siblings point to each other, everything points back to the root document,
attributes point to their owner element, etc. Even if you remove some of those
that are infrequently used, you can't remove all the cycles (or absences of
direction as you may wish to see it) and have something useful. It gets worse
with linking.
Dan Sugalski
>I wonder at times, however, if a simple vote of yea or nay might
>actually count for something here.
Plain yes or no? Not generally, no, unless someone's actually looking
for a count or vote.
Yes or no with explanation, especially when it's about things in the
apocalypses, can have a lot of impact, so if you have more than a yes
or no then there's a possibility.
Nicholas Clark
> Any input or comments welcome, though you may feel free to email me
> off-list if it's more appropriate. ;o]
Well, this is a comment, but it's slightly off topic. I would usually mail
off list (I don't mean to score points or irritate people), but it fits part
of my view of your subject line:
Subject: Re: list manners question
In your headers I see
In-Reply-To: <a05210604baa7839ab5c9@[63.120.19.221]>
Please could people be careful to really start a new message (cut and paste
the list address into a new message) rather than simply hitting reply,
then clearing the subject and body totally, as threading mail readers
(and list archivers on the web) spot the in-reply-to headers and think that
it's all part of the same thread.
Nicholas Clark
gre...@focusresearch.com
Dan++
(Dan -- this is going to look familiar to you from prior IRC conversions
IIRC, but
I thought it could stand repeating in public).
A good set of tree/graph primitives/utilities would be a wonderful
addition IMO.
And since XML is so common, I'd like to see it treated as a quotelike
construct
for producing trees (we already have qq for strings and qw for lists,
etc.):
my $foo = <bar splee='quux'>
Hi there! <foo/>
</bar>
would be one way to point $foo at one of these magical graph
representations.
If we had such a thing, plus an eval variant that only accepted plain old
data (safe
to use on untrusted sources because nothing active will be respected), we
could
pull info in from XML (and other) files easily, too.
The construct in the example above could be parsed at compile time. In
memory
you've got the tree. If you are compiling to bytecode, the constant
section could
contain the list of SAX events (or equivalent) required to reproduce it
(allowing
some lazy possibilities BTW).
Regards,
-- Gregor Purdy
Dan Sugalski <d...@sidhe.org>
03/26/2003 10:25 AM
To: perl6-l...@perl.org
cc:
Subject: Perl and *ML
I think that the issue here isn't so much good perl support for XML
as it is good support for attributed DAGs, something which would be
of general good use for perl, since the ASTs the parser feeds to the
compiler will ultimately be DAGs of a sort.
So, rather than jumping on the "XML [insert verb here]!" bandwagon,
perhaps we'd be better served figuring out what would be useful
operations and support for/on DAGs and suchlike things?
Paul
Good point!
Those of us who use simpler systems (I actually slog through the
web-based Yahoo! mail) often forget or don't even *realize* what kind
of silent skeletons ride in the closets of forwards and replies.
I'm sure we'll try to be more careful (I know I will), but please be
patient with folk like me when we get bogged down in such things. :)
And FWIW, I consider this to be a very appropriate response -- an
aside, perhaps, but hey, the reason I asked the question was because I
care what helps and hinders other folk working on the list! ;o]