[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: No side effects holy cow. ( Re: process order (still...)
I was caught up in something else the whole week last week. Sorry. It seems like I am drifting to discussions outside of XSLT. I think we should move any further discussion off the mailing list. -----Original Message----- From: Paul Tchistopolskii [mailto:paul@xxxxxxx] >And I don't think that 'assignable variable' >is evil concept, because we are using boxes to store things >inside the boxes. I do not think mutable variables are evil as well. In fact, I am still more proficient in C than anything else. I used to program Perl all the time. I enjoyed every second of it. Especially when I could use closures in Perl (for Perl/TK). And of course, I assign anonymous subroutines to variables in Perl, pass them in other subroutines, and then call them... No, I have nothing against mutable variables. I was just saying that adding mutable variables to XSLT may not be the best way of solving the problems. I mentioned SQL because it is a very nice and tight language. I guess if we could have the equivalent of stored procedures for XSLT then we would have the best of both worlds. In summary, no holy cow either way. [... description of result-tree processing deleted ...] This is getting very interesting. I know what you mean. I spent the last 6 months (not fulltime, of course) thinking about a generic way of doing tree transformation using some ideas from XSLT. These are some of the points: 1. I really like the template idea. I consider this idea one of the most significant in the last few years. The flexibility it brings to programming is fascinating. This is ultimate dynamic processing. 2. I really like the idea of producing the result tree. For me it is a new paradigm. I also want to keep it with modifications. 3. I want to be able to look at the result tree and possibly modifying it when I am still producing it. 4. I think I need a different way of doing tree matching. I want to be able to say, find a subtree in the input tree that has a specific structure. For instance, I want to be able to label a node (or a subtree) in the pattern, and then say some other place in the tree has the identical (or similar) node (or subtree). [See point 7 also] 5. I want to be able to specify an adaptor for the input, as long as the adaptor filters the input and outputs an XML tree. Same thing with the output. I want to be able to specify an adaptor that will create the final format with the XML trees I have created. In other words, I want to keep the processing on purely XML trees. 6. I want to elevate the status of a template to a module, with helpers inside the module, so that encapsulation can be done easily. I do not consider named-templates central to the new paradigm but nevertheless very useful as helpers (to avoid templates that are 10 pages long with repeatative code). 7. I want to be able to extend a template. Anologous to inheritance in OO, I want the extension idea to reuse code and pattern. I think the extension can have two facets: one for extending the pattern to make it more specific. One for extending the module of the template to modify the result tree created by the template. I don't have my notebook with me so these are all I can think of for this message. I apologise if the descriptions are vague and hard to visualize. I started designing a language that fulfills all these things a few weeks ago. Hopefully, if other things do not distract me, I will finish writing the language report by the end of summer. (Of course, I will either find so many holes in my thinking that I give up doing it, or I will finish the report and shelf it right away as a paper exercise that will never see the light of day.) As much as I would like to say more about this language I have in mind, it is not XSLT related. So I will stop. >That's what makes me happy, because all the innovation in this world >get's implemented by those lazy developers with bad attitude who are >tired of typing more keystrokes than they have to. I should have explained this better. I like the critical attitude (but not personal attacks). Like you say, this is how we improve. What I meant to say was that they did not want to know exactly how it worked before they dismissed it out of hand. I could see their eyes telling me: `I do not need to know this'. Perhaps it was a failure on my part to explain it better. I am not sure what I should think about the number of keystrokes part. On one hand, I do not like the cluttering of characters on my screen. On the other hand, I do appreciate the ease of tag matching in XML. I do not believe XML should be as terse as Lisp or even Java (We ask people to comment the closing braces when they are too far away from their opening braces, right?). And I loath to give up having data and instructions in the same notation. I learned Perl because I refused to program in sh+sed+awk; I just cannot switch my brain fast enough to handle three sets of semantics at the same time. >I understand, >such a view is rare between scietists, who for some reasons >( unclear to me) think that scientists deserve more respect >for the things they are doing. ( Please, don't get this personal - >I very much enjoyed your letters and I don't think you are making >any difference between developers and scientists. ;-) Actually, I was trained as a computer scientist but I never had the chance of being one. When I graduated, the job market was way too tight for me to get a professorship (Or I was not good enough. Choose your interpretation.). I became a software engineer instead. So, I won't take it personally. Regards, Khun Yee XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|