This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Re: Efficient Recursive Algorithms in XSLT (Was: Re: Constructing X number of elements)
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] Re: Efficient Recursive Algorithms in XSLT (Was: Re: Constructing X number of elements)
- From: Wendell Piez <wapiez at mulberrytech dot com>
- Date: Tue, 21 Aug 2001 17:01:41 -0400
- Reply-To: xsl-list at lists dot mulberrytech dot com
Dimitre,
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.
Regards,
Wendell
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@mulberrytech.com
Mulberry Technologies, Inc. http://www.mulberrytech.com
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: http://www.mulberrytech.com/xsl/xsl-list