[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: how xslt2 affects usage of programming constructs

Subject: Re: how xslt2 affects usage of programming constructs
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Mon, 24 Jan 2005 21:01:33 +1100
embedded xpath
On Mon, 24 Jan 2005 10:14:24 +0100, Bryan Rasmussen <bry@xxxxxxxxxx> wrote:
> 
> >
> > I use exclusively f:map() where normally one would use xsl:for-each.
> >
> 
> what is the benefit? i suppose you do it for a specific benefit or is it because
> of syntactical preference.

The benefit should be obvious:

  1. Composability: f:map can be in any place where we could have a
functional composition chain.

   2. It is much simpler and more understandable to write:

      f:map(fsomeFun(), $seq)

than

     <xsl:for-each select="$seq">
         <xsl:sequence select="f:apply(fsomeFun(), $seq)"/>
     </xsl:for-each>



> 
> > As already demonstrated in my recent code, I am increasingly using the
> > FXSL HOF wrappers of the corresponding "original" XPath F & Os -- such
> > as:
> >
> >   f:mult() instead of '*'
> >
> >   f:add() instead of '+'
> >
> >   f:mod() instead of mod
> >
> >   f:string-length() instead of string-length()
> >
> >   f:name() instead of name()
> >
> 
> i would like to read your reasons for this. 

Again, the reasons should be obvious. Having a HOF wrapper with the
same name and signature as any one of all the F & Os provides
essentially a functional programming system, where all standard XPath
2.0 F & Os (and all standard XSLT 2.0 functions) are higher order.

The programmer can immediately start using all standard XPath 2.0 F &
Os (which he knows well) without having to do anything in addition.
The necessary steep learning curve is almost avoided. This is wealth
of functions that are already implemented and they have guaranteed
support by any compliant XSLT 2.0 processor.

Another important result is a set of strict and simple rules how to
write user-defined xsl:function 's that are implemented as higher
order.

Adhering to these rules makes XSLT 2.0 + FXSL really a closed (in
relation of HOF support) functional programming system.

Yet another benefit is that all HOF functions could potentially be
used in a non-XSLT environment (for example if they are available in
pre-compiled form), such as using embedded XPath 2.0 in a programming
language, or why not in XQuery. Of course, in this approach any new
HOF will have to be implemented in XSLT and precompiled before they
can be referenced.


Trying to summarize all the benefits: 

The FXSL + XSLT 2.0 functional programming system has already reached
a state where the solutions to many very difficult problems can be
simply expressed as one-liner XPath expressions.

This may represent a radical change in the way of reasoning and in how
problems are solved in XSLT.


>i have been working on a paper tbat
> has parts that relates to fxsl, and i have found a similar habit in using
> functions at a higher level, but i think my experiences are probably different
> than yours as i have taken a different approach.


That's very interesting -- I'd greatly appreciate to know more about
your approach.

Cheers,
Dimitre Novatchev.

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.