Re: :)
David Storrs wrote: On Sat, Jul 17, 2004 at 06:23:50PM -0400, Austin Hastings wrote: On Saturday, 17 July, 2004 01:53 Sat, Jul 17, 2004, Juerd wrote: Do we have a :) operator yet? It's an adverbial modifier on the core expression type. Does nothing, but it acts as a line terminator when nothing but whitespace separates it from EOL. Please tell me you're serious. We could mimick XQuery where it is the comment terminator. http://www.w3.org/TR/xquery/#comments -- Robin Berjon
Re: This week's Summary
The Perl 6 Summarizer wrote: Mmm... Pie-thon Dan reminded everyone of the URL of the benchmark that's going to be run for the Pie-thon. If Parrot doesn't run it faster than the C implementation of Python, then Dan's going to get a pie in the face and he'll have to spring for a round of drinks for the Python Cabal (is there one? Could be a cheap round...). Of course, the plan is to have Parrot be faster than Python so Dan'll get to chuck a Pie at Guido. Either way, if you're at OSCON this year it should be fun. Right now, Parrot is some way from, well, running it. Unfortunately I will be missing this historic event, I'm sure there'll be videos after the fact but is there any chance of getting a live video feed of it? The suspense is killing me... -- Robin Berjon
Re: Funky «vector» operator
Matthew Walton wrote: For the record, on Mac OS X it's Option-\ for « and Option-Shift-\ for » (where Option-Shift-\ may also be seen as as Option-Shift-|). It is entirely possible that this is different on a normal Apple keyboard as opposed to the one in my Powerbook, but that strikes me as unlikely. Specifying the OS is not enough, you need at least the keyboard layout. It would be impossible to have shortcuts involving | or \ on a French keyboard since they are respectively Alt-Shift-L and Alt-Shift-: OS X / iBook / fr-fr « Alt-è » Alt-Shit-è -- Robin Berjon
Re: Perl 6 timeline?
chromatic wrote: With Apocalypse 12 (soon!) I'm sorry but this just begs for the question: (vaguely) how soon? :) I get all excited whenever I hear Perl and six in the same sentence, and it's building up to be unbearable ;) -- Robin Berjon
Re: Traits: to renew OO inheritance in a hacker style discussion
Larry Wall wrote: I only see like() as counting the methods available through the public contract to determine its percentage. Something you could do by hand with .can(). But there wouldn't be much point in putting it in if people won't use it. On the other hand, if people want it and it's not there, they'll reinvent it, poorly. I'd use it for marshalling objects composed of many things to something that makes sense to someone else's idea of what they should be, eg an XML Schema. Pick what it's most alike to and marshall as that. -- Robin Berjon
Re: Semantics of vector operations
Damian Conway wrote: Frankly, I'd *much* rather see: @sum = @a Eraquo+Elaquo @b; my Vector $outer = $vec1 Etimes $vec2; which at least has the benefit of being consistent with POD notation. I very much second that. Entities have been one of the worst features of XML (and, in the end, a fairly useless one), I don't think XML geeks would be happy seeing them too often in their Perl code :) (Note that, if we *do* decide to support some kind of ASCII-based entity notation, we really must make sure it's the same in both Perl code and POD mark-up.) Picking the HTML entity names is better than the Unicode ones as the latter are way too long. They may not cover all the characters we need, but we can make up missing ones in a consistent fashion. -- Robin Berjon
Re: Semantics of vector operations
Damian Conway wrote: Robin Berjon wrote: Picking the HTML entity names is better than the Unicode ones as the latter are way too long. They may not cover all the characters we need, but we can make up missing ones in a consistent fashion. I fear there are too many missing ones for that. Any reason we couldn't accept both HTML and Unicode names? I wasn't proposing to come up with short names for all the Unicode repertoire, just for the characters that are used as operators :) That shouldn't be too long, should it? I have nothing against using the Unicode names for other entities for instance in POD. The reason I have some reserve on using those for entitised operators is that ELEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR RIGHTWARDS, COMBINING isn't very readable. Or rather, it's readable like a totally different plot with its own well-carved out characters, intrigues, and subplots in the middle of a book. -- Robin Berjon
Re: Next Apocalypse
My, is this a conspiracy to drag -internals onto -language to make it look alive? :) You guys almost made me drop my coffee mug... -- Robin Berjon [EMAIL PROTECTED] Research Scientist, Expway http://expway.com/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: The Perl 6 Summary
Uri Guttman wrote: MS == Melvin Smith [EMAIL PROTECTED] writes: MS This has been a major stumbling block for me in getting back the MS motivation to help with Parrot again. so if that helps salve your wound, i am sure you contributions (past and future) to parrot are welcomed and appreciated by the parrot community (pretty much those on these lists) I second that. The imperatives of book production are mercantile, and have nothing to do with one's excellent participation in an Open Source effort, irrespective of the quality that a given editor may normally have. I'm certain that when a more definitive book is started, there will be much more time to ask all the interesting people for input. Please don't lose your motivation :) -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
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: 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: 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: 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
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: P6ML?
Michael Lazzaro wrote: So, is anyone working on a P6ML, and/or is there any discussion/agreement of what it would entail? Imho P6ML is a bad idea, if it means what I think it means (creating a parser for quasi-MLs). People will laugh at our folly, and rightly so for trying to be able to parse all the horrors of the world in a sensical manner will lead to the same madness that happened with HTML. People will also hate us, and rightly so, for increasing tolerance for that kind of behaviour goes against the work accomplished over the past five years. There are a number of pockets of bugosity that still produce broken XML, but they are being quenched one by one. Being too kind to them will only encourage them. As someone that works with XML every single second of my work time (and much of my fun time), I can only too well understand the frustration of developers faced with other people's buggy output and do want to help. 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. Encouraging people to produce broken data by making efforts in that area at more or less language level visibilities is a step backwards (Oh, it's broken but they use Perl so it doesn't matter). 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. - base a quasi-parser on something that does quasi-parsing well, namely an HTML parser, which would be wrapped to look like an XML parser but would be able to correct most typical problems (poorly defined entities, missing end tags, encoding errors, etc). Advantages are: a) it addresses 98% of existing problems, b) trying to solve the remaining issues in any non ad hoc manner is suicidal, c) can be pointed to to developers in trouble, and d) has very low general public visibility. Oh, and e) the perl-xml community is already on it, expect something in the month to come. Either way, I really think it shouldn't be called P6ML. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: XML is Too Hard for Programmers = Tim Bray
Rich Morin wrote: I have commented before on the face that Perl doesn't have Power Tools (read, idioms) that are well suited for handling XML. Turns out that Tim Bray agrees. http://www.tbray.org/ongoing/When/200x/2003/03/16/XML-Prog You may want to look at the perl-xml thread called Tim Bray says XML is too hard for programmers on this topic, as well as at the xml-dev thread on the same topic, especially http://lists.xml.org/archives/xml-dev/200303/msg00536.html. Perl can have idioms for XML, they just need to be developed. I don't at all believe however that that needs to happen at the p6l level. We can already make very cool stuff using p5, and the grammar stuff in p6 ought to make the sort of while loop Tim Bray describes quite certainly doable as well. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: XML is Too Hard for Programmers = Tim Bray
Simon Cozens wrote: [EMAIL PROTECTED] (Rich Morin) writes: I have commented before on the face that Perl doesn't have Power Tools (read, idioms) that are well suited for handling XML. Turns out that Tim Bray agrees. Tim Bray also says he gives up and uses regexes as a quick and dirty work around. So maybe these power tools you keep touting aren't necessary after all. To be fair he only does that on data he has 100% full control over and that is pre-munged to match his regexen. Otherwise, you really can't do that. But that doesn't change much to the (potential absence of) issue, see my other post. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: XML is Too Hard for Programmers = Tim Bray
Austin Hastings wrote: FWIW, I've had to try to rewrite Microsoft's VCPROJ and SLN format files(*), which look a whole lot like XML. Sadly, if you change the order of independent entities in the file, Microsoft's internal parser rejects the file. This despite the fact that MS already has an XML parser dll available for public consumption (More than one version, in fact). To me, this says that there's no real commitment to doing XML. What there is seems to be a recognition that XML format is regular and comprehensible to others, so writing XML-like files becomes popular. Just because MS has one broken tool (surprise!) doesn't mean there's no 'commitment to doing XML'. There is much commitment, including from MS, and people very rarely use XML-like formats. We are going OT *very* fast. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: any type
Tanton Gibbs wrote: Has there been any discussion about having an any type. I realize that this can be accomplished with an untyped variable, but there may be a reason not to do that. Namely, there most probably will be some sort of pragma like use strict 'type' which will ensure every variable is typed. I agree that it would be nice for uniformity. The way you conceive it, would all types derive from it? I would think that it would only hold objects, not things like int and string (although they could be promoted ot Int and String automatically). Few things in Java are more painful than the int/Integer, etc dichotomy and the fact that whatever accepts Object cannot take a primitive, and that what expects a primitive can't take its corresponding object. It would imho not be conceivable to not have auto-promotion here, lest we lose much dwimity. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expway 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 15:37 12/02/2001 -0500, Dan Sugalski wrote: It *is* rare in OO perl, though. How many of the variables you use are really, truly in need of finalization? .1 percent? .01 percent? Less? Don't forget that you need to count every scalar in every array or hash, and every iteration over a block with my declarations. Perl churns through a *lot* of SV pointers in its average run, and most of them aren't in need of finalization. Couldn't we simply (for non-implementer values of simply) provide a way for people to ask for finalization on an object ? Given that most of the time it isn't needed, it wouldn't be too much of a burden for programmers to have to write i_want_some_finalization($object, [finalization params]) ? That would avoid burdening Perl with more dwimity. Dwimity's cool but it usually has consequences and costs, and those ought to be balanced against what it costs not to have it. just my E0.02, -- robin b. There's too much blood in my caffeine system.
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 17:33 12/02/2001 -0500, Dan Sugalski wrote: At 11:28 PM 2/12/2001 +0100, Robin Berjon wrote: Couldn't we simply (for non-implementer values of simply) provide a way for people to ask for finalization on an object ? Given that most of the time it isn't needed, it wouldn't be too much of a burden for programmers to have to write i_want_some_finalization($object, [finalization params]) ? Sure. Y'know, maybe we could even have a sub with a special name! Maybe... DESTROY? :) Yes, I'm vaguely aware of that possibility :) I believe I misexpressed myself. What I meant was re non-refcount GC and predictability of destruction. If the author wanted refcount triggered destruction for a given object he'd say so explicitly. That would make it easy to separate the objects that require deterministic destruction from those that can be left to the more sophisticated GC. Adding something like: package foo; use attrs qw(cleanup_sub); would be nice, but I don't know that he'll go for it. (Though it's the only way I can think of to avoid AUTOLOAD being considered a potential destructor) Yes that would be nice indeed. -- robin b. You can tune a piano, but you can't tuna fish.
Re: JWZ on s/Java/Perl/
At 16:16 09/02/2001 -0500, Ken Fox wrote:
The general rule is the more space you "waste" the faster the collector
is. If you have memory to spare, then don't run the garbage collector as
often and your program will spend less total time garbage collecting.
In other words, the collection cost per object approaches zero.
If you "need" to go faster, then waste more memory.
If you "need" to use less memory, then go slower and collect more
frequently.
Which (to me) seems to just beg for the question: Is this something that
the oft discussed use {less,more} {memory,speed} pragma could hook into ?
-- robin b.
Heisenberg might have been here.
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
At 08:36 04/10/2000 -0700, Nathan Wiger wrote: This RFC should either be retracted, or revised into: POD to XML translation should be easier On this subject, I have notes about a Pod::SAX module that would make pod2xml much easier. If I have time to implement it I'll do it, but I can't tell when that will be. If anyone wants the meagre notes that I have to start working on this, I'll be glad to provide them. -- robin b. Heisenberg might have been here.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
At 10:59 03/10/2000 -0400, John Porter wrote: Complex things should not be done in POD. Indeed. This debate has been done to death. Have any of the would-be pod-killers read the thread at http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-08/thrd11.html#0 1078 ? The thread eventually died out, and for good reason imho. -- robin b. Don't panic.
Re: Stackable ties
At 16:24 03/08/2000 -0700, Peter Scott wrote: Is it at all possible to define interfaces for tie-ing that would facilitate stacking? Do we care? I think we should care, notably for tied handles. It would be very useful to be able to pipe ties easily. -- robin b. Always remember you're unique just like everyone else.
