This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Wishes for XSL revisions ...
Trevor Nash writes:
> Gunther,
>
> On Wed, 26 Dec 2001 21:58:33 -0500, you wrote:
>
[...]
> >- Why should any qname have to be hard-coded?
> >
> You should remember that XSLT is designed to be compilable, so you
> should compare it with C or Java rather than Javascript for example.
> These things make more work for the language implementor, and make it
> near impossible to invent good optimisations. These things might make
> the language easier to use, but you would pay through transformations
> taking longer to run. Programs with names constructed at run time are
> also much harder to maintain and less likely to be robust.
Having maintained such programs (mostly written in Lisp) I'd say that
such programs, when well written, are only slightly harder to
maintain. The difficulty comes from trying to determine the call tree
from static code. The points where the call target is determined
dynamically, and the possible call targets for that site, can be
identified by the programmer without difficulty. It is only automatic
tools that try to determine the call tree from the source code that
are confused by this.
Having the ability to pass first class functions around (or at least
their names) greatly simplifies the programming task by facilitating
code reuse, as the postings about generic templates will attest. Less
code ultimately leads to less debugging and better maintainability.
> Another aim of the original lnguage was to make it possible to write
> an incremental processor, i.e. one that could see a change to the
> input tree and make the corresponding change to the output tree
> without reprocessing the whole thing. All of your complaints could be
> explained by that.
>
> I have written a lot of complex XSLT, and have never been stopped yet
> from doing anything I needed to do through lack of these facilities:
> there are other ways to do the same thing. For example, look in the
> archive for this list for 'generic templates'.
I find the generic template code somewhat opaque. It's non-intuitive
to use an artificially contrived element for match template selection.
It is more intuitive to dispatch on a template name. I think that the
care that is necessary in keeping a separate namespace for such
element names also exposes the difficulty of exploiting this
technique.
>From what I've read of his postings, I believe that Dimitre Novatchev,
who seems to be the inspiration behind generic templates and their
leading proponent/spokesperson, would prefer to pass template names
around and that the generic templates technique only uses contrived
elements rather than template names because that is the only value at
a call site that can be controlled dynamically. Dimitre, am I
understanding you correctly?
> 1. It is still difficult to implement a pure functional language
> efficiently: some things are going to be slow however good the
> compiler is. If you make it too difficult you end up with a great
> language but few or no compilers (Eiffel went that way).
One typically only incurs the cost of such dynamic calls when one
employs them. One does not incur an additional cost for all
statically determined calls as well.
> 2. The target audience for XSLT is not computer scientists or even
> programmers, but Web designers. [[I do not intend any insult to Web
> designers here - I am just recognising that different people with
> different backgrounds with have varying difficulty assimilating new
> ideas]] There seems to have been a view that these folk might have
> trouble with a too-pure functional language.
> I'm not sure that was right - looking at the questions on this list it
> seems to be the programmers who are most easily confused. Top of the
> list seems to be variables whose value cannot be changed and for loops
> which aren't.
I regret that my opinion of the abilities of web designers is
determined by a single data point. I was programming the back-end for
a page that required a hierarchy of radio button groups. The leaf
radio button groups had two choices: whether to "include" (I won't
go into what that meant for this application) the corresponding item
or not. The parents had similar buttons which could be used to
group-select all of their children. A "senior" web designer, with
the development of a significant web site behind him, wrote me some
client-side JavaScript to maintain the radio button consistency. It
didn't work. I didn't know any JavaScript but wound up rewriting his
code from scratch to yeild a working result. This wasn't hard because
I had training and experience as a programmer.
I don't feel that this experience allows me to comment about web
designers in general. I do believe that this particular highly
regarded senior web designer, though he would be able to use XSLT to
rearrange data (shuffling table columns around, etc.), would not be
able to apply XSLT to perform any significant data reductions.
Should choral music scores be confined to a single octave because we
don;t all have the range to sing soprano?
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list