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:
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"/>
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  = <html><head/><body>
      <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?

loop ($counter = 1; $counter < 20; $counter++) {
     <li>Try to count electric sheep . . . </li>;


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...

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 ?)
l) For someone who is so forcibly putting forward the inclusion of xml into the language, it might have been wise to discover the answer to this question first....

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] .= <li>some 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
m) a NEW sigil???

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.
n) For each of these suggestion, my response has been why not? The whole beauty and power of the perl6 design as it stands now is to allow a programmer to do just what has been suggested. However, it will require a programmer to use perl6 to do this, but also to design the rules that will be unambiguous and elegant. o) In a very real sense, the true answer to JF is that all he wants is already in Perl6 and it is as much a part of the "core" as CGI, database interaction, etc. But in order to tap the power of the Perl6 core, he has to define the behaviour he wants, and to write the module.
cheers, Jim Fuller

Reply via email to