[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Assignment no, dynamic scoping si (was: Wishes
Dimitre Novatchev wrote:
In case XSLT is such a bad language to you, what are you doing here in this XSLT list? Would you frequent a Cobol list and tell them how bad their language is? (e.g. Haskell), use HaXML and forget about XSLT. This however will likely not appeal to you as Haskell's variables are immutable too... Dimitre, I'd like to apologize if I hit a nerve. I'm relatively new to XSLT and I'm enjoying it pretty much. OTOH, I never understood what's so bad about trolling a little bit. I'm not advocating some XSLT competitor on "your" list, I'm just poking around some things that bother me, and I did admit that I could be wrong. You shouldn't be upset about that. From the other responses in this thread I realize that this isn't just my personal issue, and I hate if it just goes off in flames instead of being a learning experience for those (like me) who are hitting their head at that corner of XSLT. It is also not an issue of me just choosing a different language. I think anyone representing W3C work should be aware of the great impact you're having. The whole industry has put a huge investment of faith into you (W3C) this creates a current against trying to swim is rather pointless. When working in collaborative projects or other standard activities buildiung on XML, it's not free personal choice, we are stuck on the whim of W3C to feed us some good stuff... or just about so. So, there is absolutely no need for you or anyone representing XSLT to become defensive against some half-way upset remarks from folks like me. Thompson's book has a small, nice appendix comparing functional, imperative and OO programming. Allowing changes of the value of a variable makes imperative languages not side effects free. This makes it very difficult or almost impossible to perform program verification and program transformation. Another general result of imperative languages not being side effects free is that they are much more difficult to maintain than side effects free languages. Some nice features, as for example lazy evaluation, do not fit well languages with side effects.
I'm not sure the hint to mathematics is really a fair answer, because in mathematics variables are also more than static value bindings. In languages like Prolog, where assignments to variables don't exist either, a variable nevertheless has different bindings at different times during "execution" of the program. But XSLT (as far as I know it) does not have a construct in which the binding of a variable ever changes, no unification, etc. The foreach form would be a candidate, but interestingly (and not at all a reason for complaint to me) XSLT uses the "current node set" as the "iteration variable" in these cases. So, my issue was supposed to be a little more than just ranting. I found parameters done right, I can see the use for variables as a handle to constructed node sets (leaving the RTF vs. node set issue aside.) I can even see the use of a variable when it is bound by a select='...' form when you need to get back from constucted node sets into other node sets. But in any case a variable is a static name-value binding. One can shadow one such binding by another using the same name in a statically nested scope, but that's about all. I keep thinking that dynamic scoping as at least an optional feature that lets me shadow such bindings along the call graph (instead of the static structure graph) would be very, very useful. I also suspected that may be there is a valid argument against dynamic scoping, and that you, Dimitre, probably would be able to tell. kind regards, -Gunther
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
|