Re: Standards bearers (was Re: xml and perl 6)
duh. I'll learn to finish reading all the posts before adding my own *someday*. --- Darren Duncan [EMAIL PROTECTED] wrote: At 10:23 AM +0300 12/11/07, Richard Hainsworth wrote: Darren Duncan wrote: At 9:04 AM +0300 12/10/07, Richard Hainsworth wrote: Equally, Something to replace CGI or DBI will be essential to the uptake of P6. I would far prefer to have a skilled and resourceful professional, such as yourself or Damian Conway write these modules than leave it to enthusiastic amateurs such as myself. I for one can assert that both of these are being produced right now. Also that neither is part of the Perl 6 kernal, though the kernal may enhanced over time to better support them. -- Darren Duncan A great relief. Fantastic. Where should I be looking to see what is happening. Is there some form of coordination of this module writing activity? Look in the ext/ subdirectory of Pugs version control to start with, as it contains a bunch of Perl 6 modules in various stages of completion, some doing http or web stuff, and some doing database stuff. One place to look for some coordination is on the perl6-users list. They were discussing a CGI replacement awhile ago, and Juerd made a proposal plus some example code, which became HTTP/ and Web/ under ext/. On various DBI lists there was some talk about DBI-2, which it ended up will have a foundation written for Parrot with bindings for Perl and other languages. There is also a mod_parrot project. There is also my Muldis DB project, a version of which is written in Perl 6, and which is being built rigorously. These efforts are all separate from each other, as per CPAN module development in general, and there is no one coordination point of all of it. But the work is still getting done nonetheless. As for standards, well those tend to be defacto. Whichever of these projects get functional and used will likely set the pace for what comes next, which may include forming the basis for more formal standards. -- Darren Duncan Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: Standards bearers (was Re: xml and perl 6)
It also helps that you consistently make incisive observations and contributions to conversations, even if they are a little tart sometimes. :) But on this general note, is there any current organization or location where small problems are being parcelled out? I'd love to help, but my time is as limited as everyone's If I could get small bites of work to do, maybe I could contribute something useful. Anyone requesting one black-box module or function at a time? Or am I pipe dreaming? --- chromatic [EMAIL PROTECTED] wrote: On Sunday 09 December 2007 22:04:30 Richard Hainsworth wrote: I download pugs and parrot from SVN repositories, written tests - one of which still hangs the compilation of pugs. Indeed the test I wrote for pugs concerned the ability of pugs to use existing CPAN modules. I have tried parrot with SDL and the tests fail. My aim was to write a P6 GUI module so that from the start it would be easy for P6 users to generate UI interfaces easily. If you send me or the Parrot list the Parrot test results, I will do my best to fix them. Unfortunately, despite my eagerness, I am not a professional programmer with the time or the skill to fix the problems. Where I can contribute is to express a view about how P6 might best be developed. Hey, I'm a trained musician and sometimes novelist who develops software on the side, and the primary reasons @Larry absorbed me are that: 1) I transcribe conversations faster than anyone else on the team 2) I had a working keycard to O'Reilly's Tarsier meeting room in Sebastopol and the reason I keep working on this stuff is: 3) I'm some combination of too stubborn or too stupid not to keep working on it All it takes to make a contribution is a fraction of my stupid or my stubborn plus some spare time. -- c Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: Standards bearers (was Re: xml and perl 6)
Paul Hodges wrote: But on this general note, is there any current organization or location where small problems are being parcelled out? I'd love to help, but my time is as limited as everyone's If I could get small bites of work to do, maybe I could contribute something useful. Anyone requesting one black-box module or function at a time? Or am I pipe dreaming? I've also been looking for something to do. Some organization ( or direction on where to go ) on this would be excellent. -- _ispy++ [EMAIL PROTECTED] :: use Perl;
Re: Standards bearers (was Re: xml and perl 6)
Why thank you Mr. Chromatic! In between all my other activities, I have been trolling along this list from its inception, and followed eagerly every Appocalpse, Exegisis and Synopsis as soon as they came on line. I download pugs and parrot from SVN repositories, written tests - one of which still hangs the compilation of pugs. Indeed the test I wrote for pugs concerned the ability of pugs to use existing CPAN modules. I have tried parrot with SDL and the tests fail. My aim was to write a P6 GUI module so that from the start it would be easy for P6 users to generate UI interfaces easily. Unfortunately, despite my eagerness, I am not a professional programmer with the time or the skill to fix the problems. Where I can contribute is to express a view about how P6 might best be developed. Moreover, I do think that sketching out the way modules should (at least initially) be written, and skteching out which modules should be written as soon as possible, are as much a part of the language design as deciding how best to use the colon. Moreover, consider the development of pugs. The first modules to be developed were Test and Test::Harness. Vital for the development of the language. Not a part of the core. Equally, Something to replace CGI or DBI will be essential to the uptake of P6. I would far prefer to have a skilled and resourceful professional, such as yourself or Damian Conway write these modules than leave it to enthusiastic amateurs such as myself. And as for singularities, I appreciate Larry's idea of language development as being akin to a strange attractor (expressed in answer to a question I posed on this list nearly a year ago about when P6 would be complete), but I also fear that the orbits that describe solutions to some strange attractors have a great deal of volatility and it is never possible to define at any time exactly what the orbit is - a bit like not being able to define all aspects of an electron due to Heisenberg's uncertainty principle. But if that is the case with P6 (and why should it not given the wholly new areas of programming that P6 is defining?) where does that leave people like me? Does it mean that we must abandon P6 to the professionals, just as strange attractors and quantum physics are the domain of professional scientists? Does it mean that I must, as it now seems to be the case, move my own programming and the main language of my firm's IT department to Python? I realise that @Larry have their own priorities, their own pressures, their own limited resources. I would like to help, yet there are limits to what I can do. And I am sure what is true for me is true for many others trolling on this list. You are doing a fine and wonderful job. Your efforts - I sincerely believe - should be applauded and appreciated. My impatience is due to a heightened expectation and desire to use P6 that in fact is a result of the fantastic achievements I have already seen. Richard chromatic wrote: On Saturday 08 December 2007 06:50:48 Richard Hainsworth wrote: Surely, some concentrated thought by the inventive and resouceful minds of who lead this project should go into language utilisation and popularisation. My goodness, @Larry's pretty darn busy trying to build the core kernel of Perl 6 in such a way that the rest of the world can build beautiful and useful things around that kernel much in the same way that the CPAN as a whole is the shining gem of Perl 5. You, Mr. Hainsworth, and every other person reading this message from December 2007 through the singularity (aka Perl 7) officially have my permission to think about this yourself and pitch in! (Fixing the mixed metaphor in my first paragraph is a good start. Reading S11 is step two.) No one ever needed permission, but if it makes anyone feel better, there it is. -- c
Re: Standards bearers (was Re: xml and perl 6)
At 9:04 AM +0300 12/10/07, Richard Hainsworth wrote: Equally, Something to replace CGI or DBI will be essential to the uptake of P6. I would far prefer to have a skilled and resourceful professional, such as yourself or Damian Conway write these modules than leave it to enthusiastic amateurs such as myself. I for one can assert that both of these are being produced right now. Also that neither is part of the Perl 6 kernal, though the kernal may enhanced over time to better support them. -- Darren Duncan
Re: Standards bearers (was Re: xml and perl 6)
On Sunday 09 December 2007 22:04:30 Richard Hainsworth wrote: I download pugs and parrot from SVN repositories, written tests - one of which still hangs the compilation of pugs. Indeed the test I wrote for pugs concerned the ability of pugs to use existing CPAN modules. I have tried parrot with SDL and the tests fail. My aim was to write a P6 GUI module so that from the start it would be easy for P6 users to generate UI interfaces easily. If you send me or the Parrot list the Parrot test results, I will do my best to fix them. Unfortunately, despite my eagerness, I am not a professional programmer with the time or the skill to fix the problems. Where I can contribute is to express a view about how P6 might best be developed. Hey, I'm a trained musician and sometimes novelist who develops software on the side, and the primary reasons @Larry absorbed me are that: 1) I transcribe conversations faster than anyone else on the team 2) I had a working keycard to O'Reilly's Tarsier meeting room in Sebastopol and the reason I keep working on this stuff is: 3) I'm some combination of too stubborn or too stupid not to keep working on it All it takes to make a contribution is a fraction of my stupid or my stubborn plus some spare time. -- c
Re: Standards bearers (was Re: xml and perl 6)
On Saturday 08 December 2007 06:50:48 Richard Hainsworth wrote: Surely, some concentrated thought by the inventive and resouceful minds of who lead this project should go into language utilisation and popularisation. My goodness, @Larry's pretty darn busy trying to build the core kernel of Perl 6 in such a way that the rest of the world can build beautiful and useful things around that kernel much in the same way that the CPAN as a whole is the shining gem of Perl 5. You, Mr. Hainsworth, and every other person reading this message from December 2007 through the singularity (aka Perl 7) officially have my permission to think about this yourself and pitch in! (Fixing the mixed metaphor in my first paragraph is a good start. Reading S11 is step two.) No one ever needed permission, but if it makes anyone feel better, there it is. -- c
Re: Standards bearers (was Re: xml and perl 6)
On Sun, Dec 02, 2007 at 07:43:25PM -0800, Peter Scott wrote: : I do feel strongly that we need some sort of solution to this so that Perl : 6 is not merely an outstanding framework that leaves all domain-specific : extensions to the end user. Perl 6 as a language doesn't address this (except to keep the library namespaces precise and accurate), but that doesn't mean it won't get addressed or that we don't want it addressed. We're aiming for an ecology more like Linux, where we distribute the kernel, and others build distributions around it, and those distributions are designed to make it easier for various classes of end users. In any case, I'm certain the community will also make sure that something CPANishly downloadable is there, since no distribution can possibly guess right all the time. But a single editorial board is not scalable over the long haul. We'll eventually need multiple such boards that compete among various perceived and real ecological niches. We can start with one distribution as long as it is explicitly realized that anyone can fork it at any time, for any reason. Then let Darwin take over, and see what the service economy does with it. Now, it might well be that a Perl standards body could specify a mininum suggested set of modules for any distribution to enhance interoperability, but we haven't got to that point yet, I don't think. Someone with an organizational bent could get a running start to come up with such a editorial center, but setting standards out ahead of practice is rarely the optimal approach. And right now, we would, at best, be guessing from Perl 5 best practice. Maybe that's good enough to start with, if we can get any two people to agree on what the Perl 5 best practices are. :) Anyway, that's the reasoning behind supplying as little as possible with the P6 kernel. We don't want anyone mistaking it for a distribution in the first place, nor do we want us language lawyers to evolve into any kind of official distribution board. Central planning doesn't scale over the long term. We should restrict our federal activities to those that help all the states get along with each other, at least well enough to avoid a civil war. Of course, as the U.S. proved at the beginning, when you fear a strong federal government it's possible to invent too weak a federal government. There's a balance in there somewhere that we're still trying to figure out... Larry
Re: Standards bearers (was Re: xml and perl 6)
Larry Wall wrote: Now, it might well be that a Perl standards body could specify a mininum suggested set of modules for any distribution to enhance interoperability, but we haven't got to that point yet, I don't think. This would be great though!! Even if it is afterward, it is still a lot better than nothing! perl6 offers a lot of new nice features in the grammar itself, but the lack of standards over than those of programming 'best practices' could be a problem. When I started to learn perl5, I have read (and am still reading because I am far to be a good programmer^^;!), a lot of books, online tutorials but none of them were doing it the same way! And I am still trying to get it! (What I liked though it is that I have learnt of lot more than other languages!) I guess perl6 is a solution to this problem thanks to the grammar itself. This is great, I think. But the above concerns regarding standards modules are a real issue too it should not be underestimated. Anyway, that's the reasoning behind supplying as little as possible with the P6 kernel. We don't want anyone mistaking it for a distribution in the first place, nor do we want us language lawyers to evolve into any kind of official distribution board. Central planning doesn't scale over the long term. We should restrict our federal activities to those that help all the states get along with each other, at least well enough to avoid a civil war. Of course, as the U.S. proved at the beginning, when you fear a strong federal government it's possible to invent too weak a federal government. There's a balance in there somewhere that we're still trying to figure out... Larry -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.jp
Re: Standards bearers (was Re: xml and perl 6)
On Fri, 30 Nov 2007 03:57:58 -0700, David Green wrote: Part of a solution is search.cpan.org -- if you can figure out which of the 870 XML modules will be useful to you. Another part is asking on newsgroups or lists -- if you can figure out which of the 870 opinions offered is knowledgeable. I think things like the CPAN ratings and reviews will become increasingly important. Of course, this is all a community issue (rather than a technical issue), and questions about handling reputation are certainly not limited to Perl or CPAN. Maybe some kind of Advisory Board would help, where people (who might be experts in various ways) can offer informed recommendations on what modules make a good fit for what circumstances. Ultimately, if this is something we want, somebody needs to volunteer to organise something. (Or volunteer to figure out exactly what it is that would need organising) I do feel strongly that we need some sort of solution to this so that Perl 6 is not merely an outstanding framework that leaves all domain-specific extensions to the end user. Please note that I am not arguing for inclusion in the core; presumably I *am* arguing for some sort of standard flavors of P6 that are named and supported. If we can't solve that any better than Luke's assessment I fear we will have sold Perl 6 short to a large community. Part of the major attraction of Perl 4/5 was knowing how much was core/standard; you could write programs that did everything from DNS calls to shared memory access to database access and know that anyone anywhere with Perl could run them. But nowadays you need a slew of modules to write good programs. It would be a shame if we perpetuated in P6 the syndrome of having to be in the echo chamber [1] before you knew what those modules were. We ought to be able to spread that knowledge around a bit better. I'd just hate to see the same situation of For good O-O, use Class::Accessor, No, use Class::Struct, That's ancient, use Class::Std, No, the new standard is Object::InsideOut, That's so 2006. All the best programmers are using Moose now. Okay, so we will have standard O-O in P6 so that scenario doesn't apply, but substitute CGI/DBI/XML/etc/etc and you have a picture that will. Does everyone who wants to know what to use to do those things properly in P6 have to be subscribed to TPR/perlmonks/clpm/perlbuzz/use.perl.org/arrgh? Can we find a way to make and maintain some recommendations in a way that people can find them easily from P6 itself? If I'm shopping for a car and I find a place that sells a fantastic drivetrain and says that they leave the choice of body, wheels, and seats to me I'm going to look somewhere else because I don't have the time to research auto component integration even though if I did I could end up with a car to die for. Maybe what we need is an editorial team. Developers tend more to want to include everything, like a Slashdot page where you have to wade through acres of dross to find something useful, because sitting in judgment on someone else's submission is distasteful. But editors are used to making judgments and dealing with the consequences. If we could find people who would do that job perhaps they could define a few standard bundles that end users and distro maintainers could choose if they don't want the core alone. Yes, it involves value judgments and we don't like to make those and people will argue about their decisions no matter what, but does that have to stop us? [1] http://groups.google.com/group/perl.perl5.porters/msg/74ecce32ff1ad845?dmode=source -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/
Re: Standards bearers (was Re: xml and perl 6)
Peter Scott writes: I do feel strongly that we need some sort of solution to this so that Perl 6 is not merely an outstanding framework that leaves all domain-specific extensions to the end user. OK. Can we find a way to make and maintain some recommendations in a way that people can find them easily from P6 itself ... Maybe what we need is an editorial team. Build it, and they will come! This isn't something which needs to influence language design -- in the sense that it doesn't need to be sorted before the design can be final and Perl 6 released. It isn't really anything that needs to be agreed by central diktat (remember that search.cpan.org isn't in any way official -- it's 'just' a Cpan mirror which happens to have a web interface that many people find convenient). Nor is it something that needs to be got right the first time, or we need to be confident will last as long as Perl 6. (For example, ActivePerl has been the _de facto_ standard Windows Perl distribution for some time; it's possible that Strawberry Perl in time will take over that, but if so it'll just be because it gets momentum behind it and the community as a whole chooses it, not because somebody named it as such.) Smylers
Re: Standards bearers (was Re: xml and perl 6)
On Nov 30, 2007 10:57 AM, David Green [EMAIL PROTECTED] wrote: Maybe some kind of Advisory Board would help, where people (who might be experts in various ways) can offer informed recommendations on what modules make a good fit for what circumstances. Ultimately, if this is something we want, somebody needs to volunteer to organise something. (Or volunteer to figure out exactly what it is that would need organising) Step 1: Form a committee to decide whether the formation of a Organization Committee for the Advisory Board would be advantageous. Step 2: Allow time for the committee to decide. Step 3: If the organization committee is formed, allow it time to organize the board. Step 4: By this time, Perl 7 will have been released, and the board is closed with a Job Well Done. Alternative Step 4: Determining whether this step will ever be reached is equivalent to the halting problem. Luke
Standards bearers (was Re: xml and perl 6)
On 11/29/07, James Fuller wrote: but by making some fundamental xml processing available by the core (like file access, regex, and a host of other fundamental bits n bobs), u do promote a common and systematic approach to working with XML in all perl modules. As everyone else and his dog has pointed out, the core thing is pretty much irrelevant, but I think this gets at the real point here: what's *standard* is the important thing. (In P5, many standards were determined by what was included in the core modules, hence the confusion.) Not being locked in to one way, or not being able to predict the future, etc., are all excellent points, but at the same time clear and easily recognisable standards are very important also. So what's the standard P6 module for XML (or anything else)? Perl6 will make some of this moot: one problem with official modules in P5 is maintenance; once a module enters the CORE(TM), it has to be maintained forever so that people can rely on its being available. I expect P6 will make availability transparent (or mostly so, if you have Internet access and haven't blocked CPAN or something). P6 doesn't need a core to make stuff available -- whatever is out there will be at your fingertips. In some ways, standard isn't any better or more meaningful a word than core, but it is important to be able to find a good module without being an expert. (Of course, it's for that very reason that it can't be an issue of the language itself, because Larry -- or even @Larry -- isn't an expert in everything. (Actually, I suspect Larry could do very well in deciding everything from the best XML module to the best knitting module (Purl6--coming soon to a CPAN mirror near you!)... but maybe he doesn't *want* to!)) Part of a solution is search.cpan.org -- if you can figure out which of the 870 XML modules will be useful to you. Another part is asking on newsgroups or lists -- if you can figure out which of the 870 opinions offered is knowledgeable. I think things like the CPAN ratings and reviews will become increasingly important. Of course, this is all a community issue (rather than a technical issue), and questions about handling reputation are certainly not limited to Perl or CPAN. Maybe some kind of Advisory Board would help, where people (who might be experts in various ways) can offer informed recommendations on what modules make a good fit for what circumstances. Ultimately, if this is something we want, somebody needs to volunteer to organise something. (Or volunteer to figure out exactly what it is that would need organising) The other side to this problem is coming up with good modules so there's something to recommend. But that is a technical issue and something for a separate post. -David
Re: xml and perl 6
On 11/29/07, James Fuller wrote: well, if my previous posts didn't attract flames this post certainly will ;) Nah, this is getting into the interesting language part! (Technically, it should be perl6+xml-language... but then the goal of perl6 is to be infinitely flexible, so I guess it is on topic!) but you did say 'from a users perspective' ... so I will play 'make believe' with some syntax I mentioned in my previous message that there is a technical side to the issue of standards. That involves questions about what makes for a good XML (etc.) module (which raises the question, Good for *what*? -- a practical answer is, what's good for a lot of the people a lot of the time. Maybe there's no single answer even to that question, so perhaps there are multiple standards in some cases; that's fine. And of course, there will always be de facto standards based on whatever most people happen to be using at any given time. That's fine too.) But one of the obvious things that makes a module technically good -- and the one that's most relevant here -- is what its dialect' is like, how its syntax works, how perlish it is; in other words, how well it fits in with design goals of perl6 as a language. We've all seen modules that worked but didn't feel very perly (and a good Python XML module might look very different from a good Perl one). So I think what a P6 XML module would look like (as opposed to how it works) is certainly worth discussing here. (Or indeed, any other module, as far as its linguistic aspects go.) The first thing that caught my eye about James's examples was the way he plunked XML (that looked like XML) in the middle of Perl (that looked like Perl). my $sales = sales vendor=John item type=peas price=4 quantity=6/ item type=carrot price=3 quantity=10/ item type=chips price=5 quantity=3/ /sales; no surrounding quotes seems about right. Having just been admiring Aurdrey's XML::Literal module the other day, I was wondering whether it could work in Perl6. P6 already works the angles pretty hard -- you couldn't make them quote a piece of XML without giving up their standard string-quoting function. But hey, maybe that's worth it if you're doing a lot of XML. Could P6 still recognise a hash-key quoted %likethis as a special non-XML case? (Should it? Would XML-keys be particularly useful?) Or is it better to pick some other characters as the XML-quoters and have the code almost look like XML? Having your XML look like XML carries definite advantages, and having things look like what they are is definitely part of Perl's philosophy. But on the other hand, XML is kind of bulky and awkward, so maybe the Perly thing to do would be to translate it into something that looks like how it works: XML documents are trees, so maybe they ought to look more like ordinary hashes. (E.g. on 11/29/07, Patrick R. Michaud wrote: my $doc = Document.new; $docsomecontent = 'here'; -- much better than a here-doc, which wouldn't provide you with syntax-checking, syntax-colouring, or syntax-anything-else.) [...]I like my 'scanability' to be in xpath form ala: my $select_li_elements = $html[/html/body/span/ul/li]; and then u have the expressive power of xpath inside of these brackets. Perl would more likely use something like $htmlhtml/body (or even $htmlhtmlbody), since square brackets mean ordinal indices (though you could make that work too). You could have $htmlhtml/body and $html.html.body both work. Perhaps more interesting is to consider something like: my $select_li_elements = /$html/body/span/ul/li; Hm... ( as an aside, is there any concept of the native types, Scalar, Array, Hash being in a different namespace then all the other symbols e.g. could I override Scalar type ?) I guess the idea would be to have unspecified scalars default to the XML type (instead of type Any)? Sure! (I don't know exactly how, I just know P6 lets you do anything you want.) Of course, if you have special quotes, there might be no need: if Perl knows that foo/ is XML data, then my $f=foo/ will do the right thing. This would replace text context node of div id=mydivid/ $html[/html/body/[EMAIL PROTECTED]'mydivid'] ] = new text value; $htmlhtmlbodydivp:idmydivid = new text value; ? I am unsure of what an append scenario would look like. push? ~=? .append()? Perhaps one would like to be able to decide if this xml must be checked for validaty against some schema technology (DTD and relaxNG as basic) are there any 'adjectives when declaring a type ... I guess I am suggesting a new sigil enforcing an XML context ;0 That wouldn't be a new sigil (despite Perl6 letting you do anything, I think this is one area where it would look the other way and pretend not to hear you unless you got really insistent); probably you'd say: my XML::Doc $foo is validated($dtd); should print out the value
Re: xml and perl 6
By the time this got written, I see James has bowed out of the
discussion with some words about 'architectural break points'. Even so,
my two-penniworth:
JF gave some examples of how he would like xml to be 'a part of core'.
For clarity, I use xml and I have designed a language to describe
financial scoring models as xml. To process the language _in perl_ I
looked at a variety of processing approaches before deciding on
XML-Twig. Note there were different approaches and they are
fundamentally different. I choose the one that suited me and the problem
space best.
Hence the design philosophy underlying perl6 encourages this
flexibility. So despite my own current preferrence for xml as a data
description methodology, I absolutely agree with the perl6 design.
Some more analysis:
snip
first a few assumptions;
we will probably never want to 'address' xml in perl ... e.g. perl
format will never become declarative markup and there is no reason to
start wanting to somehow mix code/data lisp style in perl
a) why is this true? The flexibility in perl6 with its ability to morph
its own input grammar makes it entirely possible to consider
interspersing output markup with processing commands. Consider is the
important word. Whether such an approach would be aesthetically pleasing
is entirely another question. I do find php to be quite ugly. However,
suppose someone comes up with a nice way of doing it, great ...
another thing to admit is that an XML type would probably just be an
XML document well formed and adhering to the rules of XML v1.0
going beyond that and stating it must be an XML Infoset is going
too far.
b) Why a document? and look at the snippits below, they are not
documents, unless my understanding of what a document is differs from
that being implied in this posting.
c) For me, xml means a way of encapsulating data in a clear cut way.
---
Here are some examples of psuedo syntax I would find useful (which I
have borrowed from things like XQuery, e4X, etc);
-
declaring some xml in one's perl program;
-
my $sales = sales vendor=John
item type=peas price=4 quantity=6/
item type=carrot price=3 quantity=10/
item type=chips price=5 quantity=3/
/sales;
d) My problem with this snippit is that there is no context in the sense
of a problem space that is being tackled. What is the whole script
trying to do? Why is it so important to loose the bracketing syntax of
quotation marks that would identify the right hand side as a normal user
defined object?
e) It would seem from the entire xml email thread that JF equates xml
fragments with integers and strings. But look at the xml fragment above.
4 is an integer, peas is a string. In other words, the xml fragment
is itself built up from more fundamental data types. Hence xml is not so
really fundamental or core, but rather as a common method of
aggregating data. Perl6 is designed to allow for the creation of objects
that aggregate data.
f) From what I understand about Perl6 is that the fragment given about
could easily be a part of a Perl6 script. However, a use
XML-Scripting; statement would need to be included that would introduce
the appropriate grammar rules so that i) the xml fragments are correctly
parsed and assigned, and ii) all the other parts of the script would
parse correctly and unambiguously.
g) Given the length of time it has taken to develop Perl6 (FAR TOO
LONG!!!, I would humbly suggest as a user who wants to see Perl6 in
real life), and the careful discussions that have gone into all aspects
of syntax and grammar, it is by far not obvious to me that creating a
module that handles xml as above would be trivial.
no surrounding quotes seems about right.
however this leads to some 'other thoughts, like how does perl and xml
play nice together
h) Perl6 and xml would play nicely together if some talented programmer
creates a nice playground, viz. an elegant and unified syntax that
excludes the other ambiguities of the real world.
what about;
my $html = htmlhead/body
span
h1{ $sometitlevar }/h1
i) If you like this type of scripting - and I really dont - I can see no
reason why you cant design a module to do this with perl6.
j) By the way, all of these snippets are html not xml, or rather there
are no xml examples here that are not html. JF, do you work with xml or
with html?
ul
{
loop ($counter = 1; $counter 20; $counter++) {
liTry to count electric sheep . . . /li;
}
}
/ul
/span
/body/html
I have eschewed with explicitly having a print statement, as a
syntactic shortcut.
k) But why? Create an 'XML-Scripting' module and I would imagine it to
be possible for perl6 to export any value that is of type xml directly
to an output stream.
when it comes to manipulating XML, there are a few axioms...
Re: xml and perl 6
On 11/29/07, James Fuller [EMAIL PROTECTED] wrote: I understand that there can be different distros customized to certain problem domains, but as explained I see XML as common to all those problem domains. I have a fulltime Perl programming job. I also spend a lot of my free time with Perl. Thankfully, reading or writing XML is a part of neither. Shawn
Re: xml and perl 6
--- James Fuller [EMAIL PROTECTED] wrote: From another point of view, there must be a reason why most languages have not decided as treating XML as a first class citizen. I've had several positions where we do moderately large-scale stuff and don't touch XML; I use strings, floats, and ints every day. You talk about how critical XML is to what you do, but it's been almost useless to me at several jobs. If I want useless things baked into a language, I want *my* useless things baked in :) As for supporting XML as a type: a class is a type definition. Objects are merely user-defined types. With Perl 6, they're even easier to work with, so there are your types and they should be pretty darned good. Other than the fact that you're forced to pick something which really suits your needs, why would you want to force *me* to have stuff which doesn't suit my needs? If you'll pardon the tautology, when complex types are involved, what any user needs is dependent on what that user needs. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: xml and perl 6
On Nov 29, 2007 6:40 AM, James Fuller [EMAIL PROTECTED] wrote: I would argue that XML is slightly evolved 'text' and I would like to see my fav programming language treat it as a first class citizen internally. I think you are falling into a classic builtin trap. The idea is that when you install perl, you install perl core + some modules packed with the install. We would like to discourage installing perl core without any modules. But that point has been made many times already. I think you're addressing something more of a feel issue. You're saying that XML types should have the same first-class status as strings or integers, and not some awkward blessed reference business or anything. Fortunately, Perl 6 is working pretty hard to make sure you can make data types feel builtin. In fact, this allows us to implement many core data types as modules until we add compiler support, with no kludges for the users. XML will be the same, a module. If we find that somebody writes a truly excellent XML module that becomes widely used and would benefit from having support in the compiler, it will be added to the compiler[1]. But basically the decision comes from a philosophy that core is nothing special; there need not be a difference between a core data type and one defined in a module. With a modular enough compiler, there need not even be a difference in terms of what code is generated. Please, you, everyone, forget about the word core. It is an implementation detail. Luke
Re: xml and perl 6
I guess what should be in the core or not is not something that should not be debated here. In fact, perl 6 is supposed to be the *community language* so instead of saying 'I' use this one but don't use this one, so I don't see why it should be implemented into perl, the *community* should decide and unless I made a mistake nobody here can pretend representing the entire community. Internet is here, a huge online poll amongst a minimum number of programmers is a better way to go. perl can handle different fields, so the polls should be divided in order to get the better in each fields... That's true that it's not possible to be sure of how will look like our programming style, concepts in 10 or even 3 or 4 years. OOP is being implemented all over the place, and if it was the worst solution ever but that we just do not know better ? Regex is being reimplemented, does it mean that the first implementation sucked ? By listening to you all, we shouldn't even think to implement file access... A programming language is made by humans and subject to the same evolutions and bugs and in the end is alive and will die. A programming language should evoluate, try to respond quickly to the actual environment in order to survive or expand. It is good to make assumptions of what migth the future be for hours and hours and years and years. It might be better just to try and live.
Re: xml and perl 6
On Nov 29, 2007 12:01 PM, Smylers [EMAIL PROTECTED] wrote: So, to make a claim for any 'domain-specific' functionality to be added there are plenty of core perl functions that you or I will use rarely (both in perl 5 and perl 6). my claim is that XML is significantly common place, that any new language that descends from the gods, could have some basic XML processing support in place. It's an opportunity to formalize xml processing idioms in all those external modules, as well as ensuring high performance. to the core, you would have to be better at making predictions than those who added modules to Perl 5. _Are_ you better at such predictions? What evidence have you got for that? the only evidence I have is anecdotal. When XHTML1 launched did you correctly predict that XHTML2 would turn into an ignored project that no web-browser vendors are interested in implementing, and that instead they would be implementing HTML5, a language based on HTML4 that encourages authors not to bother with XML? no, I didn't predict this ... but this is not really a valid analogy,I am not predicting XML usage I am using it all the time, as is most of the folks I know are . I am sure there is a silent majority of perl users who interact with XML on a regular basis but yes I agree it is impossible for me to prove ;) as already mentioned, I am sure that perl 6 will have XML processing my point is if we should have some bits in the core which I see as being an advantage over other languages; also will , the vocal majority here is saying 'no' . but doesn't every good idea meet resistance. It would be interesting to hear from someone who does use perl and XML if this is not the case on the perl 6 language list, then perhaps perl 6 is not the language for me ;) cheers, Jim Fuller
Re: xml and perl 6
James Fuller writes: my claim is that XML is significantly common place, Yes, but the question isn't whether it's common place _now_ -- but whether it still will be in a couple of decades time. We know from experience that adding some modules to Perl 5 a decade ago is now a maintenance burden, for modules that aren't now common place. We don't want to repeat that mistake. to the core, you would have to be better at making predictions than those who added modules to Perl 5. _Are_ you better at such predictions? What evidence have you got for that? the only evidence I have is anecdotal. OK then. But why do you _think_ you are better at making predictions? When XHTML1 launched did you correctly predict that XHTML2 would turn into an ignored project that no web-browser vendors are interested in implementing, and that instead they would be implementing HTML5, a language based on HTML4 that encourages authors not to bother with XML? no, I didn't predict this ... but this is not really a valid analogy, It wasn't supposed to be an analogy; it was supposed to be events which seem to directly contradict your prediction. I am not predicting XML usage In a previous message you said: I can only see more XML for all of us. That looks entirely like a prediction to me. . I am sure there is a silent majority of perl users who interact with XML on a regular basis Many of us aren't. Or aren't sure there will be in 2 decades. but yes I agree it is impossible for me to prove ;) Quite. It isn't that I'm predicting XML _won't_ be around in 2 decades; it's that none of us can be sure that it will be. So it's being left out. That doesn't mean that there won't be an XML parser in commonly encountered Perl distributions. Look at what Adam Kennedy is currently doing with Strawberry Perl, as an example. my point is if we should have some bits in the core which I see as being an advantage over other languages; Ah, well that's where you've seriously misunderstood the situation, I'm afraid. The deal here is that we have bits in the core which _Larry_ sees as being advantageous over other languages! (And the rest of us tag along because we like the decisions he makes.) Smylers
Re: xml and perl 6
Hi Jim, This has become quite the flame war. There seem to be two sides of the argument, you arguing one, everybody else arguing the other. So to bring some perspective back into this discussion, I'd like to ask you, what would it mean to you for there to be an XML type in core? That is, from a user's perspective, disregarding implementation of the language? What would you be able to do with it that you couldn't do if it were a module (arguments such as use it without putting 'use XML::Foo' at the top considered valid)? If you answer these questions, then everybody can start to address the technical answer to your issue, which might lead them to a different philosophical answer. Luke On Nov 29, 2007 11:23 AM, James Fuller [EMAIL PROTECTED] wrote: On Nov 29, 2007 12:01 PM, Smylers [EMAIL PROTECTED] wrote: So, to make a claim for any 'domain-specific' functionality to be added there are plenty of core perl functions that you or I will use rarely (both in perl 5 and perl 6). my claim is that XML is significantly common place, that any new language that descends from the gods, could have some basic XML processing support in place. It's an opportunity to formalize xml processing idioms in all those external modules, as well as ensuring high performance. to the core, you would have to be better at making predictions than those who added modules to Perl 5. _Are_ you better at such predictions? What evidence have you got for that? the only evidence I have is anecdotal. When XHTML1 launched did you correctly predict that XHTML2 would turn into an ignored project that no web-browser vendors are interested in implementing, and that instead they would be implementing HTML5, a language based on HTML4 that encourages authors not to bother with XML? no, I didn't predict this ... but this is not really a valid analogy,I am not predicting XML usage I am using it all the time, as is most of the folks I know are . I am sure there is a silent majority of perl users who interact with XML on a regular basis but yes I agree it is impossible for me to prove ;) as already mentioned, I am sure that perl 6 will have XML processing my point is if we should have some bits in the core which I see as being an advantage over other languages; also will , the vocal majority here is saying 'no' . but doesn't every good idea meet resistance. It would be interesting to hear from someone who does use perl and XML if this is not the case on the perl 6 language list, then perhaps perl 6 is not the language for me ;) cheers, Jim Fuller
Re: xml and perl 6
On Nov 29, 2007 1:15 PM, Luke Palmer [EMAIL PROTECTED] wrote:
This has become quite the flame war. There seem to be two sides of
the argument, you arguing one, everybody else arguing the other.
good to see there is passion underlying perl 6 development ;)
So to bring some perspective back into this discussion, I'd like to
ask you, what would it mean to you for there to be an XML type in
core? That is,
from a user's perspective, disregarding implementation of the
language? What would you be able to do with it that you couldn't do
if it were a module
(arguments such as use it without putting 'use XML::Foo' at the top
considered valid)?
well, if my previous posts didn't attract flames this post certainly will ;)
but you did say 'from a users perspective' ... so I will play 'make
believe' with some syntax
first a few assumptions;
we will probably never want to 'address' xml in perl ... e.g. perl
format will never become declarative markup and there is no reason to
start wanting to somehow mix code/data lisp style in perl
another thing to admit is that an XML type would probably just be an
XML document well formed and adhering to the rules of XML v1.0
going beyond that and stating it must be an XML Infoset is going
too far.
---
Here are some examples of psuedo syntax I would find useful (which I
have borrowed from things like XQuery, e4X, etc);
-
declaring some xml in one's perl program;
-
my $sales = sales vendor=John
item type=peas price=4 quantity=6/
item type=carrot price=3 quantity=10/
item type=chips price=5 quantity=3/
/sales;
no surrounding quotes seems about right.
however this leads to some 'other thoughts, like how does perl and xml
play nice together
what about;
my $html = htmlhead/body
span
h1{ $sometitlevar }/h1
ul
{
loop ($counter = 1; $counter 20; $counter++) {
liTry to count electric sheep . . . /li;
}
}
/ul
/span
/body/html
I have eschewed with explicitly having a print statement, as a
syntactic shortcut.
when it comes to manipulating XML, there are a few axioms...
-
How to Address parts of an XML document variable ?
-
It is common to want to address a portion of an XML document
my $select_li_elements = $html.html.body.span.ul ;
this syntax is ok (actually I do not like this approach), but I like
my 'scanability' to be in xpath form ala:
my $select_li_elements = $html[/html/body/span/ul/li];
and then u have the expressive power of xpath inside of these brackets.
so when declaring a var as xml, it would be this
my $data is XML;
( as an aside, is there any concept of the native types, Scalar,
Array, Hash being in a different namespace then all the other symbols
e.g. could I override Scalar type ?)
next,
-
How do I update an XML document variable ?
-
Here are a few edit type examples reusing the XPATH syntax introduced earlier;
This would replace text context node of div id=mydivid/
$html[/html/body/[EMAIL PROTECTED]'mydivid'] ] = new text value;
This would replace text context node of a div with an id of the value
of $myperlvar
$html[/html/body/[EMAIL PROTECTED] ] = new text value;
This would replace XML children of ul element
$html[/html/body/span/ul] .= lisome new bullet point/li;
This would remove XML children of ul element
$html[/html/body/span/ul] .= null;
I am unsure of what an append scenario would look like.
-
And what about validation?
-
Perhaps one would like to be able to decide if this xml must be
checked for validaty against some schema technology (DTD and relaxNG
as basic) are there any 'adjectives when declaring a type ... I
guess I am suggesting a new sigil enforcing an XML context ;0
then there is the 'processing' XML bit .
-
Iterating through XML
-
should print out the value of each div contained in html
for $myxmlvar[/html/body/div]]{
print; # prints $_, the current loop variable
}
I will stop here ... so I can put on my flame proof suit.
cheers, Jim Fuller
Re: xml and perl 6
On Nov 29, 2007 1:15 PM, Luke Palmer [EMAIL PROTECTED] wrote: language? What would you be able to do with it that you couldn't do if it were a module (arguments such as use it without putting 'use XML::Foo' at the top considered valid)? and to answer specifically the question; 'What would you be able to do with it that you couldn't do if it were a module ?' there is no difference in usage. but by making some fundamental xml processing available by the core (like file access, regex, and a host of other fundamental bits n bobs), u do promote a common and systematic approach to working with XML in all perl modules. I see some real benefits to this (more associated to lingua franca type design patterns). cheers, Jim Fuller
Re: xml and perl 6
James Fuller writes: by making some fundamental xml processing available by the core, u do promote a common and systematic approach to working with XML in all perl modules. Why is that a good thing? What makes you so sure that nobody will come up with a better way of working with XML In Perl 5 would it've been good to add XML::Parser to the core as soon as it was written, and ecouraged everybody to standardize on using that rather than coming up with others? Smylers
Re: xml and perl 6
On Nov 29, 2007 3:44 PM, Smylers [EMAIL PROTECTED] wrote: What makes you so sure that nobody will come up with a better way of working with XML there is power in everyone doing the same thing ... this is a variation of lingua franca design pattern. For example, would we say that the reason why HTML is powerful today based upon the right mix of angle brackets and hyperlinks, etc... I would argue no; its simply because everyone is using it. HTML 'could' just as easily been pure SGML or s-expressions for all I care. Back to the arguement; By placing some basic xml handling in core, then you are enforcing a single authoritative approach to using XML inside of perl ... you are not restricting it ... yes someone can come up with a 'better' way as well. I have been arguing that having some simple functionality, provided by the core, would potentially harmonize usage across modules and promote better understanding of code, in general, through consistent usage. There is a recent analogs in perl, of what happens, for example; the lack of a case statement in perl (which I am personally fine with) meant a multiplication of the ways one implements such a logic structure, in turn reducing understandability in the end we now have 'given'. I would not include XML::Parser though I would expect an XML parser (like expat) to have to 'live' somewhere in perl or be dynamically linked is there one in parrot I wonder . to underpin the structures I have shown in my previous email with faux perl syntax. Once again, the point is that I would like to manage and process XML using native types, structures and xml aware operators, from within perl. If I inherit XPATH, then I get 90% of everything I need. cheers, Jim Fuller
Re: xml and perl 6
On Nov 29, 2007 10:07 AM, James Fuller [EMAIL PROTECTED] wrote: Once again, the point is that I would like to manage and process XML using native types, structures and xml aware operators, from within perl. If I inherit XPATH, then I get 90% of everything I need. But what do you mean native? I think you're misunderstanding the whole core argument. Assume that you install Perl 6, and it comes with everything you need to do XML processing. You have to add a 'use' statement at the top, but the module so used is preinstalled. Having used it, operators work on XML objects: you can add a child node with +, index a document tree with XPath expressions, etc. What more do you need? The module could even, I suppose, insert a filter into the compiler so that your proposed literal syntax would work, but I don't really see the advantage of that over this: my $doc = Document.new(END); somecontenthere/content/some END You mentioned regexes several times, but there's a difference. Regular expressions are often quite short, to the point where the syntax around creating them can overwhelm them (as anyone who's tried to use them in Java or pre-regex-literal Javascript can attest). XML documents? Not so much. I don't see any advantage to adding support for embedded XML to the core parser, which is complex enough as it is. XML + POD, anyone?
Re: xml and perl 6
On Thu, Nov 29, 2007 at 10:20:00AM -0500, Mark J. Reed wrote: The module could even, I suppose, insert a filter into the compiler so that your proposed literal syntax would work, but I don't really see the advantage of that over this: my $doc = Document.new(END); somecontenthere/content/some END Or even: my $doc = Document.new; $docsomecontent = 'here'; Pm
Re: xml and perl 6
HaloO,
James Fuller wrote:
On Nov 29, 2007 1:15 PM, Luke Palmer [EMAIL PROTECTED] wrote:
So to bring some perspective back into this discussion, I'd like to
ask you, what would it mean to you for there to be an XML type in
core? That is,
from a user's perspective, disregarding implementation of the
language? What would you be able to do with it that you couldn't do
if it were a module
Here are my perception of the discussion so far. We must distinguish
two fundamentally different things. One is the feature set of the
language itself and the other are applications expressed in that set.
Since one key aspect of Perl 6 is parsing it should be a strict superset
of XML! XML is all about machine friendly parsing---beat me if that is
over simplified but I'm looking at it from a very abstract point of
view. Perl 6 addresses a much harder task: human friendly parsing ;)
(arguments such as use it without putting 'use XML::Foo' at the top
considered valid)?
This single line is all it boils down to in the end.
well, if my previous posts didn't attract flames this post certainly will ;)
I do not intend to flame. And I'm not an XML expert. But I try to map
your ideas to language features of Perl 6 as they stand right now and
how I remember them.
Here are some examples of psuedo syntax I would find useful (which I
have borrowed from things like XQuery, e4X, etc);
-
declaring some xml in one's perl program;
-
my $sales = sales vendor=John
item type=peas price=4 quantity=6/
item type=carrot price=3 quantity=10/
item type=chips price=5 quantity=3/
/sales;
Shouldn't that be a job for a here doc?
my $sales = q:to'XML-END'
sales vendor=John
item type=peas price=4 quantity=6/
item type=carrot price=3 quantity=10/
item type=chips price=5 quantity=3/
/sales
XML-END
But assuming you a XML::sales type this could just be
my XML::sales $sales( ... constructor syntax anyone? ...);
however this leads to some 'other thoughts, like how does perl and xml
play nice together
what about;
my $html = htmlhead/body
span
h1{ $sometitlevar }/h1
ul
{
loop ($counter = 1; $counter 20; $counter++) {
liTry to count electric sheep . . . /li;
}
}
/ul
/span
/body/html
If you consider that nice. The thing you try to achieve is
handle XML as a programming language which it hardly is and
compensate with the programming constructs from perl. The
better approach is to see XML as typed data that is parsed
from files and that you can manipulate like other data and
write it back.
E.g. a validation run might simply be the condition
if ($doc does XML::SomeDTD) {...}
when it comes to manipulating XML, there are a few axioms...
-
How to Address parts of an XML document variable ?
-
It is common to want to address a portion of an XML document
my $select_li_elements = $html.html.body.span.ul ;
this syntax is ok (actually I do not like this approach), but I like
my 'scanability' to be in xpath form ala:
my $select_li_elements = $html[/html/body/span/ul/li];
Perl 6 has got full-blown namespace support so this might actually
be
my $select_li_elements = $html[html::body::span::ul::li];
Actually I think the hash sigil is more in the spirit of XML so
it should read %htmlhtml::body::span::ul::li.
and then u have the expressive power of xpath inside of these brackets.
What if you had a XPath that does namespace?
so when declaring a var as xml, it would be this
my $data is XML;
Obviously.
( as an aside, is there any concept of the native types, Scalar,
Array, Hash being in a different namespace then all the other symbols
e.g. could I override Scalar type ?)
There is no difference between native and non-native types. Perl 6 has
a well defined syntactical slot for type information and the convention
that the names start with a capital letter.
-
How do I update an XML document variable ?
-
Here are a few edit type examples reusing the XPATH syntax introduced earlier;
Without going into syntax details the manipulation should be through
the same language interface that is available for other data structures.
-
And what about validation?
-
Perhaps one would like to be able to decide if this xml must be
checked for validaty against some schema technology (DTD and relaxNG
as basic) are there any 'adjectives when declaring a type ... I
guess I am suggesting a new sigil enforcing an XML context ;0
It's hardly worth a sigil. Validity checking is a simple type check.
then there is the 'processing' XML bit .
-
Iterating through XML
-
should print out the value of each div
Re: xml and perl 6
--- Alex Kapranoff [EMAIL PROTECTED] wrote: Â ×òâ, 29/11/2007 â 07:18 +0100, James Fuller ïèøåò: On Nov 28, 2007 8:46 PM, chromatic [EMAIL PROTECTED] wrote: On Wednesday 28 November 2007 10:59:30 James Fuller wrote: I do not nec. agree with 'a particular grammer is not' part of the core ... if that grammar is so common to every problem (like regex is) then why not include it? Because it's not necessary for getting and installing other extension modules. The criterion for including a module in the core is Is this necessary to get and install other modules? not Why not include this module? I read this statement as saying that perl's core main purpose is to enable extension versus be a useful programing language ? You say that as if they were somehow mutually exclusive. It's accomplishing one via the other. feels like we are externalizing what I would call build artifacts of a language e.g. a distro of Perl 6 should be easy to adopt and easy to use immediately . I would like to see some basic level of XML support in this distro. I understand that there can be different distros customized to certain problem domains, but as explained I see XML as common to all those problem domains. But is it? I'm sure you can easily find lots of people using Perl professionally without any need of an XML parser/processor. Just like database or web libraries. Why do you consider XML something essential without also insisting on all the other technologies people use in Perl? I've been using Perl for ten years, and I've used tons of CGI and DBI and even a good bit of ACME, but I've never needed XML at all. Not everyone does things the way you do, and I'm glad I didn't have to spend out very limited disk space on features we didn't need. Yeah, disk is cheap now, but don't assume everyone has the same resources, needs, or red tape you have. Paul Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
Re: xml and perl 6
On Wed, Nov 28, 2007 at 07:52:31PM +0100, James Fuller wrote: : On Nov 28, 2007 7:39 PM, Andy Armstrong [EMAIL PROTECTED] wrote: : On 28 Nov 2007, at 18:28, James Fuller wrote: : : A few things I could imagine; native XML data type (and whatever that : means at this late stage) : : What might that mean at any stage? : : from a syntactic point of view, here are 2 interesting examples of : representing XML in a programming context : : http://en.wikipedia.org/wiki/E4X : : and : : http://en.wikipedia.org/wiki/XQuery : : there is lots to learn here. There's lots to unlearn here too. You give two examples of language initiatives that attempt to mesh XML with other language. Fine, that sort of linguistic innovation has been going on since the dawn of computers. Now what if you want to use both of those languages together? How are they related to each other? What's they're pedigree, and whose rules are in operation where? How can you even consistently tell by inspection of the text which language is intended at the top? These are questions Perl 6 is addressing. It will be *trivial* to add syntax such as the above to Perl 6. But unlike the initiatives above, in Perl you always start out in Standard Perl 6 at the top and explicitly derive your new language from that by declaration. You can add a syntax like the above with a single use statement. Unlike the unrelated languages you mention, these syntactic variants are defined in terms of derivation from the standard Perl grammar, which merely functions as a base class of parsing methods. Let me put it this way. Not even the Standard Perl 6 syntax is core in the sense you're thinking of it. There are basically *no* reserved words in Perl 6. What appear to be keywords are only convenient sets of macros that fight it out under longest-token rules, and under those rules there are no distinctions whatsoever between built-in constructs and user-defined constructs. When you derive a new language you are merely adding to or subtracting from those sets of macros, and in the limiting case you can subtract all of them and start over. All is fair if you predeclare. Explicitly. And all of those explicitly derived languages can be considered True Perl. Even those cluttered up with XMLisms. I'm not against use of XMLish syntax where appropriate, which will generally be when you want to send data somewhere portably. After all, I was the first to add an XML parser to Perl. But XML syntax makes a lousy programming language, and only a marginal data description language. And Perl 6 is not about getting trapped in the current fad, however popular it might be. In Perl 6 you have to declare explicitly that you want to be trapped by the current fad. :-) Larry
Re: xml and perl 6
On Thursday 29 November 2007 03:21:18 cdumont wrote: By listening to you all, we shouldn't even think to implement file access... Please drop the sarcasm. A programming language is made by humans and subject to the same evolutions and bugs and in the end is alive and will die. A programming language should evoluate, try to respond quickly to the actual environment in order to survive or expand. Have you *seen* how much time p5p spends on keeping little-used modules that someone successfully argued were absoutely vital to the future of Perl now and forever up to date? If you want to talk about responding quickly to the environment, look at the CPAN. If you want to talk about a low work to value ratio, look at keeping things like B::CC up to date and passing their tests. Now there's a vestigial organ. -- c
Re: xml and perl 6
On Thursday 29 November 2007 07:07:18 James Fuller wrote: I have been arguing that having some simple functionality, provided by the core, would potentially harmonize usage across modules and promote better understanding of code, in general, through consistent usage. That didn't work for File::Find in Perl 5. What makes you think we'll SURELY get it right THIS time? (Put another way, of all of the uses you've seen of File::Find, how many of them were beautiful or seemed like natural expressions of programmer intent?) -- c
Re: xml and perl 6
and to answer specifically the question; 'What would you be able to do with it that you couldn't do if it were a module ?' there is no difference in usage. Perhaps a pro XML-er can weigh in. Unlike many others on this list, I use XML for almost everything. I think the point is what you're saying here above, Jim. The benefits you describe of a native XML data type boil down to a) encouraging a common approach to processing, and b) not having to import modules. The point of DOM and other models is to accomplish 'a' without regard to language, and 'b' is going to be a benefit (not a drawback) to most users who value options. Encouraging a common approach is not an easy or necessarily smart thing in the XML space. I expect that XQuery is going to become more popular over the next 5 years, and that similar domain-specific languages will supplant DOM to a large extent. There's a reason that entire grammars like XPath and XQuery exist to do one thing and one thing alone. Let these languages do what they do well, and let Perl use them via modules (I'm working on an XQilla module now). A native XML type would only serve to antiquate Perl 6 long before it's time (!), and is therefore a ... nonstarter.
Re: xml and perl 6
Danny Brian skribis 2007-11-29 10:57 (-0700): Perhaps a pro XML-er can weigh in. Unlike many others on this list, I use XML for almost everything. I think the point is what you're saying here above, Jim. The benefits you describe of a native XML data type boil down to a) encouraging a common approach to processing, and b) not having to import modules. And it does, but it doesn't have to be native. It can be just standard, including de facto standard. Yes, XML is essential for many programmers. Yes, having a standard XML data type can certainly improve things for many people. But why on earth would it need to be bundled with Perl? All you need to make something the de facto standard, is to be good and the first, or better than all existing options. DBI is Perl 5's primary database API. Very few people ever consider using anything else. I think as many people use DBI as use XML in some way. It is NOT bundled with Perl, and has never been. Yet it is extremely popular. Do the same with XML, please. If anyone else reading this, feels like building this data type, with the code to back it, by all means please start today. But putting it in the core only helps in the forcing-down-one's-throat area. It doesn't improve maintenance, flexibility, or usability one bit. Encouraging a common approach is not an easy or necessarily smart thing in the XML space. Still, though, XML is very probably flexible enough (with its roles) that a single XML data type can still be a good idea. Something representing an XML element with its children is incredibly useful when standardised. And if it doesn't do what you want, just add a role that makes it do that. A native XML type would only serve to antiquate Perl 6 long before it's time (!), and is therefore a ... nonstarter. Amen. -- Met vriendelijke groet, Kind regards, Korajn salutojn, Juerd Waalboer: Perl hacker [EMAIL PROTECTED] http://juerd.nl/sig Convolution: ICT solutions and consultancy [EMAIL PROTECTED]
Re: xml and perl 6
Thanks to all for taking the time to respond at a minimum the discussion has taught me where perl 6 is headed and where the major architectural brake points currently are. gl, Jim Fuller
Re: xml and perl 6
cdumont wrote: By listening to you all, we shouldn't even think to implement file access... I think I'd argue that most file-access features should indeed be considered non-core. This doesn't mean that we shouldn't think to implement them -- or that they wouldn't be part of almost every Perl-6 distro -- just that they are modules. Obviously the ability to use/require a module is needed: so file access to load modules is needed. But a function like open -- or classes such as FileHandle, or IO::* -- should most definitely be considered as non-core, and implemented in modules. (Whether these modules should be automatigically available without a use feature 'files'; statement is a different debate). Dave.
Re: xml and perl 6
cdumont wrote: By listening to you all, we shouldn't even think to implement file access... I think I'd argue that most file-access features should indeed be considered non-core. This doesn't mean that we shouldn't think to implement them -- or that they wouldn't be part of almost every Perl-6 distro -- just that they are modules. Obviously the ability to use/require a module is needed: so file access to load modules is a core feature. But a function like open -- or classes such as FileHandle, or IO::* -- should most definitely be considered as non-core, and implemented in modules. (Whether these modules should be automatigically available without a use feature 'files'; statement is a different debate). Dave.
Re: xml and perl 6
A programming language is made by humans and subject to the same evolutions and bugs and in the end is alive and will die. A programming language should evoluate, try to respond quickly to the actual environment in order to survive or expand. Have you *seen* how much time p5p spends on keeping little-used modules that someone successfully argued were absoutely vital to the future of Perl now and forever up to date? If you want to talk about responding quickly to the environment, look at the CPAN. Yeah, I know that cpan is responsive, I spend my time installing modules from cpan and it helps me a lot. even if perl goals and php goals aren't the same, php is very responsive too and don't hesitate to incorporate quickly PEAR modules if they are goods. Relying on modules has several drawbacks: - too much namespace, kills the namespace: use HiRes::Time::And::I:Cannot::remember::the::damn::namespace - C based modules cannot always be installed according to your environment - use the perl version of the module when you can and therefore slow down the app. - need this one module that has dependencies all over the place all dependencies are not necessary so you rewrite some of the modules to get rid off the dependencies where you can. in the end, I need to reinvente the wheel. - No coherence, that is for me the biggest drawback. (php is absolutely not coherent helas, but the doc!) I guess that this is the main problem. You need something that is not in the core, which in my case is about 95% of the time. So you look for modules in CPAN. After searching for the right namespace (sometime you think you have THE module but a better one is just hide in a place you couldn't think of...) you dive into the documentation and therefore in the API, UI of the module. Here comes the troubles... 5 modules, 5 API, 5 UI,5 docs, 5 universes... I am very grateful for all the people that contributes to CPAN and there is absolutely no need for them to follow any conventions but in the end? my $img = new AssetMediaFactory($path); my $asset=$img-loadAsset(); In that case we are lucky, the module use the same convention but you can have: my $img = new AMF($path); my $asset=$img-load_asset(); //or my $asset=$img-ldass(); And I am not talking about the implementation in the background using hahes, inside-out, modules that stimulate oop behaviors... The way they handle errors,etc... Some of them, rewriting functions that exist in other modules but don't want to get a dependency... And if you need to use the module in your framework and if you want to stay coherent with your framework, you wrap everything. Obviously, you have choosen the 100% perl module because you want to be sure you will be able to use the same module almost everywhere. all modules have their own particular universe, even if it is a well thought one, you have to immerse yourself into it and learning a mini-language everytime. The doc is obviously free of real conventions so you have to search for the info thru all the paragraphs to be sure not to loose something even if you don't need it. SO? Well, implementing modules in perl, getting rid off weird namespaces (not all but with just 26 letters, you can handle a human language so I guess a little thousand functions shouldn't be that a problem), making it fast, available, coherent with perl itself, perl documentation will save many troubles. Perl 6 could do without implementing the XML at a core level. But why not create an interface, directions but not implementation. Unfortunately, I deal with xml too (very helas!), json, raw data,images, sessions, server connections, Databases, pdfs, spreadsheets, url encoding... is implementing all of this in the core a good idea ? think not... But I guess you got the picture. I still think that a poll on the net could be a good idea. Because when somebody comes here and say : I would like to know if this is going to be implemented, what is the answer ? 'You need it. I don't' and then : 'I need it but you don't but I need it' ... A long time has passed since the apocalypses and exegeses. -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
The Core of the Matter (was Re: xml and perl 6)
On 11/29/07, Luke Palmer wrote: I think you are falling into a classic builtin trap. [...] Please, you, everyone, forget about the word core. It is an implementation detail. Yes! Though it's a natural mistake because people assume that The CORE(TM) in Perl6 means something similar to the core in P5, when really it's conceptually (and implementationally) something quite different. I think we need a new slogan: CP6AN is the core, Perl6 is the new -MCPAN -eshell. Or: Perl6 is the seed -- grow your own core. Or: Parrot is the core, Perl6 is just a syntax module. Or simply: Perl6: there is no core. Core-dially, David
xml and perl 6
there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps before Perl 6 is fully baked its time to review what could live in the core versus an external module. thoughts? cheers, Jim Fuller
Re: xml and perl 6
On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote: there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps before Perl 6 is fully baked its time to review what could live in the core versus an external module. thoughts? If I remember the plan correctly, it's roughly that the core consists only of the mechanisms for getting and installing other extension modules - anything that doesn't need to be in the core, isn't. This slim core intentionally won't be useful for that much, other than the basis for building larger Perl 6 distributions aimed at broad types of tasks. The idea being that an ISP would install the web serving distribution, which would be bundled with the sorts of modules appropriate for that task, but not burned with the sorts of modules useful for bioinformatics. The aim is to avoid the problem that Perl 5 finds itself in, where things once added to the core can never be removed, and 15 years later you find that there are several generations of this is current modules in the distribution that are a maintenance burden. Usually a burden that falls on volunteers. Nicholas Clark
Re: xml and perl 6
all makes good sense, to make a poor analogy (and to make my point); the java build tool, Apache Ant went through the same sort of cycle (at a much smaller scale) whereby initial architecture forced a lot of extraneous functionality into the core hard to maintain and limited deployment profile capability was the result. With Ant's latest incarnation, they finally have a good model for extensibility and have been successful at segregating axiomatic functionality to the core and relegating extensions to external libraries. I completely agree that this is also good approach for Perl 6 but I would weakly argue that XML ubiquity is fast making it the 'text' format of the day and perl having many text processing facilities built into its core might want to reconsider some basic premises about how it perceives XML. A few things I could imagine; native XML data type (and whatever that means at this late stage) xml parser, xpath processor built into Perl6 core making it very quick, since we are late stage I would call this an optimization ;), I can even see in a moment of madness a nod to 'whatever' programming and embed some triple inference processing deep into perl6. making perl 6 XML-neutral is a mistake. imho. cheers, Jim Fuller On Nov 28, 2007 7:12 PM, Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote: there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps before Perl 6 is fully its time to review what could live in the core versus an external module. thoughts? If I remember the plan correctly, it's roughly that the core consists only of the mechanisms for getting and installing other extension modules - anything that doesn't need to be in the core, isn't. This slim core intentionally won't be useful for that much, other than the basis for building larger Perl 6 distributions aimed at broad types of tasks. The idea being that an ISP would install the web serving distribution, which would be bundled with the sorts of modules appropriate for that task, but not burned with the sorts of modules useful for bioinformatics. The aim is to avoid the problem that Perl 5 finds itself in, where things once added to the core can never be removed, and 15 years later you find that there are several generations of this is current modules in the distribution that are a maintenance burden. Usually a burden that falls on volunteers. Nicholas Clark
Re: xml and perl 6
On Nov 28, 2007 7:31 PM, C.J. Adams-Collier [EMAIL PROTECTED] wrote: On Wed, 2007-11-28 at 18:12 +, Nicholas Clark wrote: On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote: there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps before Perl 6 is fully baked its time to review what could live in the core versus an external module. thoughts? If I remember the plan correctly, it's roughly that the core consists only of the mechanisms for getting and installing other extension modules - anything that doesn't need to be in the core, isn't. This slim core intentionally won't be useful for that much, other than the basis for building larger Perl 6 distributions aimed at broad types of tasks. James, Perhaps you should create a distribution for xml processing? If there is not yet a Standard Operating Procedure for creating a perl 6 distribution, I think the community would benefit from the creation of such. Start small, with only enough to do a simple XML processing task. Allow for inheritence/extension of the distribution. I see these 'distributions' as deployment profiles. It would be very easy to package up (more akin to customizing a linux distro) perl6 with all those lovely XML pm tweaking here and there, etc. in the meantime, I have yet to get latest trunk perl6 running properly, on parrot, or freebsd then I will start thinking of such a task (everything compiles fine). as an aside I am getting an; load_bytecode couldn't find file 'Protoobject.pbc' current instr.: 'parrot;PGE::Match;__onload' pc 0 (compilers/pge/PGE/Match.pir:14) called from Sub 'parrot;Perl6::Compiler;__onload' pc 0 (perl6.pir:30) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) also I do not want to emulate perl6 in perl5; will try on the OSX box now. cheers, Jim Fuller
languages/perl6 doesn't run (was: xml and perl 6)
On Wed, Nov 28, 2007 at 07:42:29PM +0100, James Fuller wrote: in the meantime, I have yet to get latest trunk perl6 running properly, on parrot, or freebsd then I will start thinking of such a task (everything compiles fine). as an aside I am getting an; load_bytecode couldn't find file 'Protoobject.pbc' current instr.: 'parrot;PGE::Match;__onload' pc 0 (compilers/pge/PGE/Match.pir:14) called from Sub 'parrot;Perl6::Compiler;__onload' pc 0 (perl6.pir:30) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) Interesting -- it looks as though the Protoobject.pbc file isn't being built on your system for some reason. Perhaps do a make realclean and rebuild, so that the Makefiles are updated? If that doesn't resolve it, perhaps you could file a ticket at [EMAIL PROTECTED] and we can follow up there. (There's also a [EMAIL PROTECTED] list, but I think this particular issue is more likely to be a Parrot problem than a perl6 one.) Thanks! Pm
Re: xml and perl 6
On Nov 28, 2007 7:39 PM, Andy Armstrong [EMAIL PROTECTED] wrote: On 28 Nov 2007, at 18:28, James Fuller wrote: A few things I could imagine; native XML data type (and whatever that means at this late stage) What might that mean at any stage? from a syntactic point of view, here are 2 interesting examples of representing XML in a programming context http://en.wikipedia.org/wiki/E4X and http://en.wikipedia.org/wiki/XQuery there is lots to learn here. J
Re: xml and perl 6
Not too put too strong a bias on it, but: XML processors are a dime a dozen. There is no way for us to know *now* what the best XML processor(s) will be a decade from now, and Perl 6 is intended to be a very long term language. And frankly there are enough different use cases to ensure that no single XML processor could possibly be best in all circumstances anyway. We should not canonize a single XML processor (now especially) by putting it in the core. As Nicholas pointed out, it's unlikely that vanilla will be the Perl 6 flavor that any vendor actually ships. But I definitely want to be able to choose between strawberry and chocolate, and perhaps a new flavor of my own (or my company's) design. I really do not want to always get Baskin-Robbins in a blender because everything's in core. The grammar engine is core. A *particular* grammar is not. -'f
Re: xml and perl 6
On Nov 28, 2007 7:50 PM, Geoffrey Broadwell [EMAIL PROTECTED] wrote: Not too put too strong a bias on it, but: XML processors are a dime a dozen. There is no way for us to know *now* what the best XML processor(s) will be a decade from now, and Perl 6 is intended to be a very long term language. And frankly there are enough different use cases to ensure that no single XML processor could possibly be best in all circumstances anyway. We should not canonize a single XML processor (now especially) by putting it in the core. XML Parser is what I am talking about and I would argue that XPATH is simple and standard enough to be included as well. As Nicholas pointed out, it's unlikely that vanilla will be the Perl 6 flavor that any vendor actually ships. But I definitely want to be able to choose between strawberry and chocolate, and perhaps a new flavor of my own (or my company's) design. I really do not want to always get Baskin-Robbins in a blender because everything's in core. The grammar engine is core. A *particular* grammar is not. putting it more harshly ... I expect my basic programming language to solve my basic problems without having to resort to some layer of abstraction in the form of a framework or external module for the simplest scenarios. I have a lot of XML in front of me in all projects that I work on in every programming context and have had so for the past 3-4 years. I am a bit biased, but I can only see more XML for all of us. I do not nec. agree with 'a particular grammer is not' part of the core ... if that grammar is so common to every problem (like regex is) then why not include it? I am going on now but you get the point. cheers, Jim Fuller
Re: xml and perl 6
On 28 Nov 2007, at 18:28, James Fuller wrote: A few things I could imagine; native XML data type (and whatever that means at this late stage) What might that mean at any stage? -- Andy Armstrong, Hexten
Re: xml and perl 6
On Wednesday 28 November 2007 10:59:30 James Fuller wrote: I do not nec. agree with 'a particular grammer is not' part of the core ... if that grammar is so common to every problem (like regex is) then why not include it? Because it's not necessary for getting and installing other extension modules. The criterion for including a module in the core is Is this necessary to get and install other modules? not Why not include this module? -- c
Re: xml and perl 6
On Wed, 2007-11-28 at 19:59 +0100, James Fuller wrote: XML Parser is what I am talking about OK -- do you want an event-based parser? Do you want a DOM parser? Do you want a simplified tree generator parser? Do you care about memory limitations? Run time? Does the parser need to be robust against non-compliant XML documents, or is all the data you will be parsing known to be perfectly conformant with specs? Can you take advantage of the fact that all the XML you need to parse was previously written by your own code in the first place? Conversely, are you willing to *always* pay the performance cost associated with security against complete garbage or carefully crafted evil in the input stream? What about parsers that are optimized for particular schema? (For example, that parse an XML dump of a relational database back into a stream of rows to be pushed efficiently into actual RDBMS tables without having to fit the entire database in memory?) Most importantly -- are you sure that *any* of us can make all those decisions for everyone? Are you sure it's even possible to balance all these requirements? Even if we try to handle the common cases, who decides what those are? I guarantee that HugeBank.com and MyFamilyWebsite.net have different views of what the common cases are. and I would argue that XPATH is simple and standard enough to be included as well. I have used XPath exactly once, ever, and it wasn't really necessary even then. For some tasks, yes, it's a standard tool. But the world is much, MUCH bigger than that. putting it more harshly ... I expect my basic programming language to solve my basic problems without having to resort to some layer of abstraction in the form of a framework or external module for the simplest scenarios. This view frustrates me. I want my programming language to provide me expressive power. And I certainly do want modules available should I choose to be Lazy. But I don't expect that someone in a totally different business (or hobby) should want the same modules I do. That's what CPAN6 is for. Or task-related bundles, for that matter. We should not ship CGI *as core*. We should not ship XML tools *as core*. Frankly, I don't think we should ship DBI *as core*, even though I use databases ever day. But these APIs should be available easily. In fact, I expect to be able to intall Bundle::IntarWeb and get them all, plus all sorts of other useful goodies. But what if I am (say) wanting to ship a video game written in Perl. Why should I have to ship all that web-related crap? But I *will* need to ship an OpenGL binding. Which I would guess is totally unimportant to you, while being vitally important, completely basic, and utterly standard (XML is for youngin's, dagnabbit) to me. The Python folks want to ship batteries included. I want Perl 6 to ship a Mr. Fusion Home Energy Reactor and an easy way to download power adapters. I have a lot of XML in front of me in all projects that I work on in every programming context and have had so for the past 3-4 years. I am a bit biased, but I can only see more XML for all of us. Sure. But the world of XML is not the whole world, just as the world of English is not the whole world -- despite the great difficulty many of us have in recognizing that and writing our software accordingly. I do not nec. agree with 'a particular grammer is not' part of the core ... if that grammar is so common to every problem (like regex is) then why not include it? But that's just it -- it's not common to every problem, only to the problems *YOU* face. I don't by any stretch of the imagination intend this to be a personal attack, by the way. I'm merely saying that numerous people have made similar claims about the feature they need every day being rightfully core. But in nearly every case, that feature was important to *them*, and perhaps even a large class of people, but not to *everyone*. And on occasion, some feature has gotten added to core because it can be used in many different circumstances, or because it's simply not possible to efficiently or easily handle the problem without additions to core. Hence the reason for the amazingly powerful grammars -- you can write parsers in Perl 5 regex (and most of us have), but it's painful, and no amount of tweaking and extending them can make the massive leap in usability and expressive power that Perl 6 grammars bring. With the grammar core in place, XML can be efficiently and easily handled by modules. So it should be. -'f
Re: xml and perl 6
On Wed, 2007-11-28 at 11:46 -0800, chromatic wrote: The criterion for including a module in the core is Is this necessary to get and install other modules? not Why not include this module? WELL SAID. -'f
Re: xml and perl 6
On Wed, 2007-11-28 at 18:12 +, Nicholas Clark wrote: On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote: there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps before Perl 6 is fully baked its time to review what could live in the core versus an external module. thoughts? If I remember the plan correctly, it's roughly that the core consists only of the mechanisms for getting and installing other extension modules - anything that doesn't need to be in the core, isn't. This slim core intentionally won't be useful for that much, other than the basis for building larger Perl 6 distributions aimed at broad types of tasks. James, Perhaps you should create a distribution for xml processing? If there is not yet a Standard Operating Procedure for creating a perl 6 distribution, I think the community would benefit from the creation of such. Start small, with only enough to do a simple XML processing task. Allow for inheritence/extension of the distribution. Cheers, C.J. signature.asc Description: This is a digitally signed message part
