Re: P6ML?
Robin Berjon wrote: But as someone that also had to parse other people's random formats before we had XML, I would like to stress strongly the fact that the current situation is *much* better than it was. True, but you're also missing the point that XML is a festering pile of steaming camel turds that has been over-designed and over-engineered by committee for 4 decades and still isn't any closer to being pleasant or easy to use. Convergence is good, unless you're converging in a bad place. Now all our markup is verbose, difficult to parse, memory hungry, tiresome to manipulate, and so on, (unless you're using YAML of course). XML is Yet Another Silver Bullet Bandwagon that we all jumped on because the XML software vendors told us to. Anyway, this isn't the time or place for an anti-XML rant. Suffice it to say that at least one of us is hoping that we can do markup better in Perl 6. A
Re: P6ML?
To what extent should the (presumably library-side) ability to parse a given markup language influence Perl 6's core language design? (which is what this list is nominally about.) I think this ought to approximate to none at all. -- I'd rather have ham in my sandwich than cheese, but complaining won't do any good.
Re: P6ML?
Austin Hastings wrote: --- Robin Berjon [EMAIL PROTECTED] wrote: If it is creating a /toolset/ to make recuperating data from a quasi-XML (aka tag soup) then it is an interesting area of research. I can think of two approaches: - have a parametrisable XML grammar. By default it would really parse XML, and barf with extreme prejudice on errors. However individual rules will be relaxable and modifiable to accept different, possibly slightly broken, input. This is imho the least desirable approach. Why is this the least desirable approach? To be clear, I don't think it would be a bad thing to have, as a tool. I think however that it is less optimal than the other solution as it would require people to parameterise it each time they want to address a new kind of bug, whereas the HTMLish approach should work out of the box. Having a grammar that can be finely controlled so that it isn't too hard to implement XML parser behaviours (and I mean proper XML) mixing push, pull, trees, and whatnot built on it then that's a grand idea. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: P6ML?
Christian Renz wrote: of crap known as XSL. An XML-based derivative that performs XML transformations, allowing/using embedded P6 regexs, closures, etc., and able to more easily translate XML == P6 data. I'm still quite XML-phobic, but I see the need for strong XML support in Perl 6. However, I'd like to work with XML in Perl 6 in a way that I don't even notice it's XML. Would it be possible to come up with an interface to XML that is at least as intuitive as tie is for hash-DBM file? And that can cope with megabyte-sized XML files? It depends what you mean by all that. In some sense it already exists, there's nothing keeping someone from providing you a tied interface to XML::Simple, or some such other module. If you want more there are all sorts of existing solutions. XML::Twig is one, and probably the only one that will fulfill all your requirements (ease of use of an in-memory structure resilient to large documents -- XML took deliberate design decisions that make that difficult if not impossible ). Barrie Slaymaker has also created tools such as XML::Essex that make XML processing much more perlish (or in fact, simply more adapted to programming in general). There are also budding cross-language projects such as XBind that use a simple definition of how to map a given vocabulary to programming structures. I'm betting those will go a long way making things easier. In fact, if we're talking about data storage only, it would be interesting to have such a tie that allows me to store my data in an XML file, YAML file, SQL database etc. That already exists or is very easily doable, so long as you don't care too much what the XML looks like. My point is: Perl 5 already makes XML processing significantly easier than in other languages, the only competitor I'm aware of being Python. I see *much* in Perl 6 already that will make it easier still, but a large part of the frustrations programmers experience have nothing or little to do with what programing language they use (do long as it's dynamic). They're problems that need to be solved through new interesting ways of processing XML. I agree with Simon that there is very likely nothing that Perl 6, at the language level, can do to provide a solution to these issues. If this list were to find a solution, it would have nothing that would be Perl 6 specific. There's a friendly perl-xml list to expose issues and solutions you may have. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: P6ML?
Andy Wardley wrote: Robin Berjon wrote: But as someone that also had to parse other people's random formats before we had XML, I would like to stress strongly the fact that the current situation is *much* better than it was. True, but you're also missing the point that XML is a festering pile of steaming camel turds that has been over-designed and over-engineered by committee for 4 decades and still isn't any closer to being pleasant or easy to use. This is a large overstatement, not to mention the fact that piling SGML onto it makes little sense (if more XMLers knew about SGML, they'd produce less cruft). There are people that use XML to produce camel turd, and there are people that use it to create very nice things. What this has to do with Perl 6 evades me. (unless you're using YAML of course). YAML is cool, I'd just shoot myself before using it for document authoring. Anyway, this isn't the time or place for an anti-XML rant. Suffice it to say that at least one of us is hoping that we can do markup better in Perl 6. Everyone is hoping that, I just have yet to see someone point at one place where Perl 5 hinders XML processing in such a way that Perl 6 could help. I'm all ears though. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: P6ML?
Michael Lazzaro wrote: My own musing was not something that would accept bad XML, but something more geared as a P6-based replacement for the steaming hunk of crap known as XSL. An XML-based derivative that performs XML transformations, allowing/using embedded P6 regexs, closures, etc., and able to more easily translate XML == P6 data. I personally like XSLT, it does its job well, the syntax is verbose but the design is clean. It's a real language though, so it's frustrating until one knows enough to be comfortable (but it does also make much room for baby talk). Mine even has regexen and the such through Perl extensions. Have you looked at the replacements such as XML::XPathScript or XML::STX? Or others implemented in other languages that could be ported? For XML = P6 translations, are you aware of projects like XBind? There are a lot of wheels out there, I think p6l can't reinvent all of them ;) While we're stuck with XML, I'm not willing to say we in Perl-land should be stuck with the currently craptacular XML transformation methods being adopted by other languages. :-P Those of us that like XSLT have very happily adopted it, and in fact we're better equiped to use it than say the Java folks. Those that didn't like it have created alternatives. *shrug* Perl as usual. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: This week's Summary
Apologies for nitpicking, but you misspelled my name as Mattijs 4 times in the summary. The right spelling is Matthijs :-) -- Matthijs van Duin -- May the Forth be with you!
Re: A6: argument initializations via //=, ||=, ::=
Michael Lazzaro writes: On Wednesday, March 19, 2003, at 08:30 AM, Larry Wall wrote: We don't have a word for START right now. It's somewhat equivalent to state $foo //= 0 unless $foo gets undefined, I suppose. Assuming we have a static-like scope called Cstate, one can definitely see the use of having an assignment variant for not yet initialized or doesn't yet exist, the proposed spelling of which was C::=. I'm unconvinced by the need for a cryptic way to distinguish undefined from uninitialized. Damian argued in favour of not being able to store Cundef in arrays that have some some other, explicit, default value. I think his argument was that Cundef is the value to indicate the lack of a meaningful value, and that we shouldn't be encouraging people to overload Cundef with other meanings by making it easy to distinguish it from a lack of their being a value. If that applies there, I think it should apply here too. Or, at least, if we want to make such a distinction here it should be because we come up with good examples where the distinction is useful, doing something that couldn't easily be achieved in some other way -- and that that usefulness is thought to outway the additional complexity of having another assignment operator in the language and having to distinguish it when teaching or learning Perl. Smylers
Re: P6ML?
Michael Lazzaro sent the following bits through the ether: My own musing was not something that would accept bad XML, but something more geared as a P6-based replacement for the steaming hunk of crap known as XSL ... For example, one of the Very First Things I'll be doing with Perl6 is, of course, creating a P6-specific companion to ASP/JSP/PHP While risking the chance of going very much off topic, might I suggest that you don't wait until Perl 6 to do all these. Sure, Perl 6 will be all-dancing with beautiful syntax but Perl 5 has the advantage of being here now and not really that different. You can play with prototypes and desired syntax now, and get something finished by the release of Perl 6.0.0 ;-) Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... Are you asking me out? That's so cute. What's your name again?
Re: P6ML?
Robin Berjon wrote: I just have yet to see someone point at one place where Perl 5 hinders XML processing in such a way that Perl 6 could help. If my understanding of the design of Perl 6 is correct, the lexer, parser and any other related components will be highly configurable and/or replaceable. The goal is to provide support for little languages by separating Perl the language from perl the interpreter. It will be possible to modify or replace Perl the grammar so that perl the program can parse other languages, including Python, Ruby and presumably, XML. So instead of writing Perl programs to parse and manipulate XML, it should be possible to modify Perl itself so that it parses the XML directly into some internal form suitable for programmatical manipulation. I presume that it should also be possible to extend the rules of a default non-validating XML parser grammar with additional rules to encode an XML schema. On top of that it should be possible to define further production rules that are invoked as the source document is parsed, i.e an XML schedule (schema/schedule ~= pattern/action). How exactly this will manifest itself, I cannot tell. Nor can I say if this is actually a sensible thing to do or not. But unless my understanding is warped, support for parsing XML and other markup languages could be moved down into the core of the parser internals for Perl 6. For example, it might be possible to do something like this: use Perl6::XML; thingy blahblah blah/blah /thingy use Perl6; print $thingy.blah; This is all speculation and hand-waving, of course. But the point is that Perl 6's extending parsing capabilities could well provide a much greater level of integration between Perl, XML and various other programming and markup languages. My rant against the XML machine was really an aside. Take everything I say with a pinch of salt. :-) A
Re: This week's Summary
Matthijs van Duin [EMAIL PROTECTED] writes: Apologies for nitpicking, but you misspelled my name as Mattijs 4 times in the summary. The right spelling is Matthijs :-) Argh! Kill me now. Please. Damn, damn and double damn. I say, Simon old chap, you couldn't fix that on the perl.com site could you? Expect an apology in the next summary to go with this one. I'm very, very sorry. -- Piers
Re: P6ML?
Andy Wardley wrote: If my understanding of the design of Perl 6 is correct, the lexer, parser and any other related components will be highly configurable and/or replaceable. The goal is to provide support for little languages by separating Perl the language from perl the interpreter. It will be possible to modify or replace Perl the grammar so that perl the program can parse other languages, including Python, Ruby and presumably, XML. I think that you're a bit mistaken : the goal is to have (a) parrot execute other languages (once compiled to parrot bytecode) and (b) perl's parser able to modify itself at runtime. The fact that Perl's grammar can evolve doesn't mean that the basic entities it operates on will also evolve, and, as a Python string can't be seamlessly mapped to a Perl string, one can't have perl behave as a Python interpreter only by modifying its parser. So instead of writing Perl programs to parse and manipulate XML, it should be possible to modify Perl itself so that it parses the XML directly into some internal form suitable for programmatical manipulation. And moreover XML by itself is not a programming language, so I don't see how it's possible to build a generic interpreter for it. How exactly this will manifest itself, I cannot tell. If you wave hands very fast, bushes might start burning ;-) Nor can I say if this is actually a sensible thing to do or not. But unless my understanding is warped, support for parsing XML and other markup languages could be moved down into the core of the parser internals for Perl 6. I think you're overriding too much the meaning of 'parser' here. Basically I think that perl6's internal parser, even after heavy reconfiguration, will remain an engine to parse context-free languages, with a few improvements. That's very different from a parser for markup languages. (Of course, with a mechanism comparable to perl 5's source filters, one can plug everything. So, as Leon was saying, you can begin to implement a Perl5::XML source filter module right now.)
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? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: P6ML? List of essential libs, please?
--- Robin Berjon [EMAIL PROTECTED] wrote: Have you looked at the replacements such as XML::XPathScript or XML::STX? Or others implemented in other languages that could be ported? For XML = P6 translations, are you aware of projects like XBind? There are a lot of wheels out there, I think p6l can't reinvent all of them ;) To answer a question you asked on an earlier thread, this is one of the ways that Perl makes doing XML difficult. Q: What's the right CPAN lib to pull for parsing/rewriting XML? A: Look, we've got a plethora of XML libs, all indistinguishable at first glance. You'll need to do a week-long research project to figure out what's what! OK? While P6ML may be off-topic for the language, maybe this issue isn't: Is there a plan for the core libs? In other words, since we're moving scads of things out of core, we're implying a set of standard libs. In P5 this was a very minimalist set, since must of what was essential was in core. Now I'm proposing that some technologies, like DBI, mod_perl, etc. have proven themselves so popular that they (1) will instantly get moved over; and (2) should probably be moved over exactly ONCE. Rather than having a maze of twisty database interfaces, all alike, we want DBI. Well, rather than having a slew of subtly incompatible XML interfaces, ... So I guess, at the language level I'm asking if there's a process in place to identify these essential libs and to move forward on them? =Austin
Re: P6ML?
--- Andy Wardley [EMAIL PROTECTED] wrote: For example, it might be possible to do something like this: use Perl6::XML; thingy blahblah blah/blah /thingy use Perl6; print $thingy.blah; Every once in a while, I look at what I'm sending to the list, and I think Am I too far out, here? And then I see messages like this, and I think I'm not visionary enough for this list. Thanks, Andy. =Austin
Re: Perl and *ML
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 ;). 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 [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: P6ML? List of essential libs, please?
Austin Hastings wrote: --- Robin Berjon [EMAIL PROTECTED] wrote: To answer a question you asked on an earlier thread, this is one of the ways that Perl makes doing XML difficult. Q: What's the right CPAN lib to pull for parsing/rewriting XML? A: Look, we've got a plethora of XML libs, all indistinguishable at first glance. You'll need to do a week-long research project to figure out what's what! OK? I understand this issue very clearly, but I don't think it's Perl's fault. There have been talks on and off about a Perl-XML SDK for at least two or three years, and it's not easy. We have standardised interop between modules on PerlSAX. If there is sufficient community pressure, we have all the drafts ready to do the same thing with PerlDOM in a shortish timeframe (it just seems that people are happy with XML::LibXML). We're standardising the selection of transforming modules right now. However that will only help so much. If you want to jump into XML processing and you don't know about SAX or DOM (related or not Perl) you have some homework to do. You don't need to master them, but you need to have an idea of the ways in which they work. Also, it is by and large recognised outside the bounds of our community that Perl's wealth in XML processing is that while most other languages have just DOM and SAX, we have all sorts of alternatives like XML::Twig, XML::Essex, XML::Simple and so forth that make things much easier when you have specific requirements. We're possibly the only language with three or four different transformation packages... Which of those would go in a core lib or SDK? The ones that correspond to XML standards are used a lot and standard so they'd probably be in (with C libs dependencies issues), others are non-standard but also used much, others aren't used a lot but are so good they really should be... Then you get to the modules that interface to specific languages such as RDF or SVG, and it's a mess to deal with. All things considered, less energy might be spent by people spending a week researching Perl XML modules all together than on the creation of an SDK ;) It's a complex set of issues, and if we're to work on it that work can be done with Perl 5 modules, on the perl-xml list, right now, independently from p6l issues. Otherwise p6l will probably get to know *much* more about XML than it wants to, and the perl-xml community will be excluded from choices on stuff that concerns it very directly. Well, rather than having a slew of subtly incompatible XML interfaces, ... All the major ones should support SAX 2 for interop by now. If there are incompatibilities you can certainly file a bug report. So I guess, at the language level I'm asking if there's a process in place to identify these essential libs and to move forward on them? Ask the people that use them? -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: Perl and *ML
On Mar 26, Robin Berjon wrote: 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
Re: P6ML? List of essential libs, please?
On Wed, Mar 26, 2003 at 05:02:00PM +0100, Robin Berjon wrote: So I guess, at the language level I'm asking if there's a process in place to identify these essential libs and to move forward on them? Ask the people that use them? Didn't there used to be a stdlib mailing list for discussing this stuff? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl and *ML
At 4:47 PM +0100 3/26/03, Robin Berjon wrote: 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) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: P6ML? List of essential libs, please?
Jonathan Scott Duff wrote: On Wed, Mar 26, 2003 at 05:02:00PM +0100, Robin Berjon wrote: Ask the people that use them? Didn't there used to be a stdlib mailing list for discussing this stuff? Yes, and it had even started well by trimming a long list of suggestions one by one (I think Nat was in charge, but I could be misremembering) but it went the way of the dodo. IIRC it was perl-sdk or something like that. A subsequent idea was to have Perl sub-communities define their own SDKs, but that apparently didn't work out either. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: Perl and *ML
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) 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 :) -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: list manners question
On Wed, Mar 26, 2003 at 08:32:39AM -0800, Paul wrote: 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 [EMAIL PROTECTED]
Re: list manners question
Paul [EMAIL PROTECTED] writes: 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
Re: P6ML?
Andy Wardley wrote: Robin Berjon wrote: I just have yet to see someone point at one place where Perl 5 hinders XML processing in such a way that Perl 6 could help. (...) So instead of writing Perl programs to parse and manipulate XML, it should be possible to modify Perl itself so that it parses the XML directly into some internal form suitable for programmatical manipulation. (...) How exactly this will manifest itself, I cannot tell. Nor can I say if this is actually a sensible thing to do or not. But unless my understanding is warped, support for parsing XML and other markup languages could be moved down into the core of the parser internals for Perl 6. For example, it might be possible to do something like this: use Perl6::XML; thingy blahblah blah/blah /thingy use Perl6; print $thingy.blah; What you point to in terms both of difficulties with the existing approaches and in terms of solutions makes a *lot* of sense. I'm afraid however that some form of cold is preventing you from smelling the sulfurous fumes emanating from dragons hiding right around the corner :) I'll leave aside the excellent idea of allowing one to embed XML data into Perl source as you describe it (a nice replacement for __DATA__ for sure) to focus on the rest because if we can do that with external XML documents, the part about inlining XML becomes trivial. The basic problem is that to produce a data structure you can either know something of the kind of XML you're to be using or you can do it in a generic manner. The generic manner is simple, in fact it's called XML::Simple. It's great at what it does, but you get a data structure which you need to discover and in many case you probably want something where you have to pay less attention to whether something is a string or a hashref. Ask Nat[0] ;) The vocabulary specific manner is more complex, because you need something external to the XML to describe how the mapping operates. In your example if I were to add a blah element, all of a sudden $thingy.blah might be an array with the two contents. Things get hairy fast without even using anything crufty, especially when you add attribute parsing, namespaces, in-document links... The data binding folks have tried to address the problem using XML Schema, and the result is, hmmm, unpleasant to use something polite. The SOAP and WSDL people have been at it, and I won't even describe the result because I couldn't possibly be polite about it. Imho a grammar-based approach would likely be too low-level. I'm currently betting on something that would mix XBind[1] and Regular Fragmentations[2]. The first one defines simple mappings as described above, the second tells you how to parse data in XML documents that has structure not expressed in XML (eg date2003-03-26/date) so that it is seen in a structured way, without the need for typing. These approaches are elegant, and have the advantage of being truly cross-language so that we can let the Python people write the descriptions and use them directly :) One very cool thing that could be done in Perl 6 would be to take an XBind+RegFrag document and generate a grammar derived from the P6 XML grammar that would 1) be specific to the vocabulary (and thus hopefully faster than a generic XML grammar, though I don't have /too/ much hope) and 2) directly produce the object representation you want and return it in the parse object. This is all speculation and hand-waving, of course. But the point is that Perl 6's extending parsing capabilities could well provide a much greater level of integration between Perl, XML and various other programming and markup languages. Yes certainly, but again we could already go much farther than we are today using Perl 5 (and a lot of tuits). My rant against the XML machine was really an aside. Take everything I say with a pinch of salt. :-) I might have overreacted slightly because I'm tired of the xmlHorribleKludges obscuring the coolness that nice and helpful people work on hard. I can't blame anyone for not seeing through the blazing storm of hypish PR... [0]http://use.perl.org/~gnat/journal/11081 [1]http://www.prescod.net/xml/xbind/ [2]http://www.simonstl.com/projects/fragment/ -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: Perl and *ML
On Wed, Mar 26, 2003 at 05:40:56PM +0100, Robin Berjon wrote: 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 goalDevelop Strategic Plan/goal team_member person=ss078-05-1120/ team_member person=ss987-65-4320/ /project project project_id=p2 goalDeploy Linux/goal team_member person=ss078-05-1120/ team_member person=ss9876-12-3456/ /project employee social_security_label=ss078-05-1120 nameFred Smith/name assignment project_id=p1/ assignment project_id=p2/ /employee employee social_security_label=ss987-65-4320 nameJill Jones/name assignment project_id=p1/ /employee employee social_security_label=ss9876-12-3456 nameSydney 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 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 :) -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: Perl and *ML
Stéphane Payrard wrote: 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. By loop you mean attributes declared by DTD as IDREFs and pointing to element having the same value for the attribut ID? 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. 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 [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: Perl and *ML
Kurt Starsinic wrote: On Mar 26, Robin Berjon wrote: 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? 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. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: list manners question
At 8:32 AM -0800 3/26/03, Paul wrote: 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. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: P6ML?
Robin Berjon wrote: one metric ton of useful stuff, in various messages, all of which I agree with Including... The data binding folks have tried to address the problem using XML Schema, and the result is, hmmm, unpleasant to use something polite. The SOAP and WSDL people have been at it, and I won't even describe the result because I couldn't possibly be polite about it. Imho a grammar-based approach would likely be too low-level. I'm currently betting on something that would mix XBind[1] and Regular Fragmentations[2]. The first one defines simple mappings as described above, the second tells you how to parse data in XML documents that has structure not expressed in XML (eg date2003-03-26/date) so that it is seen in a structured way, without the need for typing. snip One very cool thing that could be done in Perl 6 would be to take an XBind+RegFrag document and generate a grammar derived from the P6 XML grammar that would 1) be specific to the vocabulary (and thus hopefully faster than a generic XML grammar, though I don't have /too/ much hope) and 2) directly produce the object representation you want and return it in the parse object. Indeed. This is the primary problem space. Nobody has done this well. If we could provide a toolset for doing this, we would Really Have Something. My initial query about the ambiguously-named P6ML was not based so much on a notion that such an effort couldn't be done in Perl5, and more on the notion that it may be far _more_ possible to do this, quickly credibly, using P6 typing/OO and the new regex engine. As I said, I've done quite a bit of prototyping, and the P5 solutions can be very, very tedious. (P5 and P6 may be mostly alike, but it's the parts that aren't mostly that have driven the very need for P6 -- and just so happen to be the very parts that make this problem so awkward in P5.) And in case I haven't mentioned it this week, you Parrot folks are my heros. [0]http://use.perl.org/~gnat/journal/11081 [1]http://www.prescod.net/xml/xbind/ [2]http://www.simonstl.com/projects/fragment/ Thanks for those... I was aware of the first two links, but I had completely missed the Frag one -- I plead ignorance on that. You are correct, it looks quite promising. MikeL
Re: A6: argument initializations via //=, ||=, ::=
On Tuesday, March 25, 2003, at 06:17 PM, Damian Conway wrote:
Likewise, I read
sub foo($x //= 1) {...}
as saying the value stored in $x is a constant, but if the caller
passed an undefined value (or didn't pass anything at all), we're
going to instead pretend they passed us a (still-constant) 1. I'm
not sure why that violates any rules.(?)
//= means assign to lvalue unless lvalue is defined. So I read that
as:
$x is a constant variable. Bind the corresponding argument to $x and
then assign 1 to it if its value is undef. But the container bound to
$x is bound as a constant, so it *can't* be assigned to.
OK, I buy that, I think. But does that mean that fixing edge cases in
your arguments doesn't work at all, i.e. you can't even do this?
sub foo(?$x) {
$x //= 1; # if they passed an undef, init it to 1
...
}
or that you have to say it like this?
sub foo(?$x) {
my $x = $x // 1; # hide $x param using a non-const Cmy?
...
}
MikeL
Re: A6: argument initializations via //=, ||=, ::=
Michael Lazzaro wrote:
OK, I buy that, I think. But does that mean that fixing edge cases in
your arguments doesn't work at all, i.e. you can't even do this?
sub foo(?$x) {
$x //= 1; # if they passed an undef, init it to 1
...
}
That's right. It's an error. You need:
sub foo(?$x is copy) {
$x //= 1; # if they passed an undef, init it to 1
...
}
or that you have to say it like this?
sub foo(?$x) {
my $x = $x // 1; # hide $x param using a non-const Cmy?
...
}
That won't work either, since the name of the lexical variable C$x is
introduced immediately in Perl 6, so the C$x on the lhs is the lexical one
from the rhs, not the parameter.
Damian
Re: list manners question
On Wed, Mar 26, 2003 at 08:32:39AM -0800, Paul wrote: 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: [EMAIL PROTECTED] 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
Re: list manners question
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: [EMAIL PROTECTED] 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. 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] Paul __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: P6ML?
On Wed, Mar 26, 2003 at 09:19:36AM +, Simon Cozens wrote:
To what extent should the (presumably library-side) ability to parse a
given markup language influence Perl 6's core language design? (which
is what this list is nominally about.) I think this ought to
approximate to none at all.
Approximately none, except that Perl's self-selected problem domain is
text hacking, and XML is redefining the meaning of text hacking.
AFAICT, all of this is rather moot. The ability to create a presumably
fast parser using rule{}'s and such solves 80% of the problem. From
there, it's a SMOP to convert text-with-angle-brackets to sensible
native data structures or native processing techniques.
I believe Robin's interest in the area is in ensuring that there will be
a simple way to take a specific XML grammar and [auto]generate an
angle-bracket-friendly parser that produces appropriate domain-specific
data structures without the grovelling through horribly generic data
structure, events or whatnot.
Z.
Re: Funding the design team
David Storrs wrote: Folks, give us your address (or a PO box, or something), where we can send checks. The checks won't be tax deductible, but are we really doing this for the tax deduction? Sorry for the delay in replying. It isn't lack of appreciation; it's lack of tuits (I was a little busy getting Synopsis 6 written this week). The design team really *do* appreciate the support that this offer and others like it represent. It means a great deal to us that you believe in the work we are doing strongly enough to throw money. :-) We certainly *could* set up some alternate donation mechanism for the Perl 6 team, but we'd really rather work through TPF. That's what it's there for -- to remove the administrative load of handling donations, etc. The problem is that it doesn't seem to be doing its job just at the moment, either in terms of finding funding, or channeling it back to the appropriate people, or even listening to the community as to who the appropriate people are. But before we look at by-passing TPF, I'd like to take one more shot at bestirring them to action. If that fails to produce a useful result, then we will definitely look at finding another mechanism to funnel your generosity to those who can best make use of it to benefit Perl. Damian
