Re: [xsl] Re: Efficient Recursive Algorithms in XSLT (Was: Re: Constructing X number of elements)

Subject: Re: [xsl] Re: Efficient Recursive Algorithms in XSLT (Was: Re: Constructing X number of elements)
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Tue, 21 Aug 2001 17:01:41 -0400

Yes, I noticed you'd changed the name of the thread, but only after I'd hit 'send'. My apologies for weighing heavily, if I did!

Since I'm not an expert in implementations, functional language design, or algorithms, I can't speak usefully to your suggestions about where to take the design of the language. From my perspective, there is a usability issue (keeping the language easy to use), although I don't want to stress that, since I find XSLT's functional approach very powerful, and don't want to threaten its integrity with demands to support styles of programming which might be "easier" for some, but which are by their nature, somewhat inimical to XSLT as it stands. (I also think it's a *feature* of the language if it's fun to learn by virtue of taking a different approach from the usual.) Yet I dare say that what you are proposing is completely consistent with this point of view.

Also, FWIW, I find the general education I receive here about functional programming, recursive algorithms and their implementation requirements and scalability, extremely stimulating. Thanks for contributing to that.


At 02:07 PM 8/21/01, you wrote:
> With respect,
> We've given Ilkka the simple recursive solution. And Dimitre has reminded
> us that in the general case, there are also better approaches. But Ilkka's
> problem may not need to be solved in the general case.

Completely agree!

This is why I changed the subject. And the purpose is to show that while there are
plenty of toy solutions for toy problems in the books and FAQ sites, I haven't seen
a single mentioning of the heavy-duty, real champions.

Also, that the parallelism that is inherent in these better algorithmic approaches
could be achieved and exploited by adding support for it (e.g. a new element) in a
future version of XSLT.

It is up to ***us*** to correct this. In an answer, FAQ site, paper, book, ... etc.,
show the toy solution, but also describe the most efficient, most general and (not
only because of these!) one of the most elegant solutions.

Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.      
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
  Mulberry Technologies: A Consultancy Specializing in SGML and XML

XSL-List info and archive:

Current Thread