Re: [xsl] Vendor extensions for XSLT - higher order functions

Subject: Re: [xsl] Vendor extensions for XSLT - higher order functions
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Mon, 23 Jul 2007 11:56:43 -0700
With what I know now about functional programming the show could have been
 over in a few Dimtre-ish folds, maps and translations.


Thanks a lot Justin, for using a word like "Dimitr-ish" and for your
nice Ozzi humor (we miss Australia!).

Hope my wife doesn't see this or otherwise I will have to explain to
her that all these "Dimtre-ish folds, maps and translations" are
actually good and legal ...  :o)



On 7/23/07, Justin Johansson <procode@xxxxxxxxxx> wrote:
Dear fellow XSLT-ers,

I hope this little tail helps the discussion.  While not sure that this
should go on the xsl-list and
in publicly view it is kind of funny and there is an XSLT legend in all of
this.  Moreover, it
is a lesson in functional programming as relevant to our current duellists.

As a small I.T. consultancy, this two person show, myself and my partner
have to show our dues to
Caesar (i.e. the Tax Revenue Office)
as every other business, big or small, does in Australia, and no doubt
similarly in other tax regimes.

In Australia it's call GST (Goods and Services Tax).  Ditto in New Zealand.
(Theirs is 12%; ours 10% of
sales invoice value).  The equivalent in the UK is called VAT.

Anyway, in an attempt to make for good record keeping per taxation
requirements, I investigated
the commercially available accounting programs in Australia.

The most popular is something called MYOB (Mind Your Own Business).
Quicken / QuickBooks
(which I think comes from the US) is also popular.

Another anyway, anyway :-

The user interface to these everyday packages really sucks so I decided to
do our small business
from an XML-based text record repository.  Mad as I am, I found it easier
to type invoices and receipts
into an XML file in Visual Studio, write an XSLT translation and produce
the required reports for the
Tax Office's 3 monthly GST return 10 minutes before closing time on the
last day.  Big fines if
you are late lodging it.

Ripley's Believe If or Not, under 11th hour pressure, I just find it easier
and less time consuming to
enter and fudge information (in the case of lost receipts, ha ha)  to do it
this way, though there has
been a much improvement in process over time.  (Enter Eclipse, Enter MS
InfoPath etc).

The whole job is really really, I mean seriously easy now, and so much
easier than any stupid
off-the-shelf commercially available accounting program.

The toughest thing, in restropect, is that I did it all in XSLT 1.0 over a
weekend.

Man, that was a mind bender.  No assignable variables.  No loops (for i
equals 1 to $number-of-sales)
etc.  The only thing to work with was this bloody recursion paradigm.

With what I know now about functional programming the show could have been
over in a few
Dimtre-ish folds, maps and translations.

Too bad for me, I never knew about FXSL at the time.  And if I did, I'm
sure I would not have known
that it could have solved my problem as sure as Wilkinson Sword razors
shave my afternoon shadow.

I'm hooked on functional programming with XSLT (note 2.0) now but I came to
it of my own discovery
having been a Javascript hacker.

This all happened after serendipitously reading an article called "The
Little Javascripter"
(go on, do your Google search)
which is a story about adopting Scheme, a LISP like functional programming
language, in Javascript.

To cut short a much longer story of enlightenment and discovery, the answer
is that you can do
functional programming in XSLT.  Dimitre has written papers about that.

That one could actually apply functional programming techniques in haste to
produce 11th hour
reports is the tale that Dimitre, and other exponents of functional
programming, should be
telling to the programmer-in-the-street.

Cheers, and make sure you pay your taxes on time.

Justin Johansson




At 12:52 PM 23/07/2007 -0400, you wrote: >You misunderstand. Michael's remark on the type of examples that ought to be given was (from the perspective of a working programmer who has read and spent thousands of dollars on books over the years) was excellent. > >I, like many, many (may I even say most) programmers have come to the craft by way of job necessities rubbing up against tools, and fueled by imagination and curiosity, with little or no formal training in the academic discipline of programming. I have heard of Don Knuth, and even seen his books on the shelves at book stores, but I don't claim to have read them. > >So examples showing how to use a function to solve a practical business problem are much easier for me to grasp than examples that demonstrate solving a theoretical computer science problem. >-- >Charles Knell >cknell@xxxxxxxxxx - email > > > >-----Original Message----- >From: Dimitre Novatchev <dnovatchev@xxxxxxxxx> >Sent: Mon, 23 Jul 2007 09:09:00 -0700 >To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx >Subject: Re: Re: [xsl] Vendor extensions for XSLT - higher order functions > >On 7/23/07, cknell@xxxxxxxxxx <cknell@xxxxxxxxxx> wrote: >> You do yourself a favor when you listen to criticism, especially well-intentioned criticism from a source with experience in the field. > > >Oh, my statement on the need to learn was not a criticism -- just >stating a fact. > > >> -- >> Charles Knell >> cknell@xxxxxxxxxx - email >> >> >> >> -----Original Message----- >> From: Dimitre Novatchev <dnovatchev@xxxxxxxxx> >> Sent: Mon, 23 Jul 2007 06:52:36 -0700 >> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx >> Subject: Re: [xsl] Vendor extensions for XSLT - higher order functions >> >> > FXSL, unfortunately, is so powerful that I think many "ordinary" users find >> > it rather daunting. A gentler introduction, using examples from the world of >> > commercial IT systems rather than computer science, would help to sell it to >> > the general public. >> >> There is nothing so powerful in FXSL and it implements some most basic concepts. >> >> Concepts like: fold, map, compose, repeat/iterate -- form the >> alphabet of programming. >> >> Certainly, if someone has arrived at grade 5 in school and still >> doesn't know the alphabet, this person will find reading even ordinary >> text rather "daunting". >> >> To summarize, FXSL provides a big potential to learn, requires >> learning, and this is even a bigger value than simply the provided >> functionality. >> >> >> -- >> Cheers, >> Dimitre Novatchev >> --------------------------------------- >> Truly great madness cannot be achieved without significant intelligence. >> --------------------------------------- >> To invent, you need a good imagination and a pile of junk >> ------------------------------------- >> You've achieved success in your field when you don't know whether what >> you're doing is work or play >> >> On 7/21/07, Michael Kay <mike@xxxxxxxxxxxx> wrote: >> > > I am curious to know why some XSLT vendors have implemented >> > > one or more XSLT extension functions with their product to >> > > make for the implementation of higher-order functions (HOF) in XSLT. >> > >> > In the case of Saxon, it was needed by an XQuery user, and availability in >> > XSLT was just a spin-off. It's not possible to use the FXSL approach in >> > XQuery because it relies on xsl:apply-templates. In fact, this kind of >> > capability is needed much more in XQuery because even without FXSL, there >> > are many things you can do with xsl:apply-templates to handle dynamic >> > content that have no simple solution in XQuery. >> > >> > In fact, in business applications I far more often see the need for >> > saxon:evaluate() (in both XSLT and XQuery) where expressions are constructed >> > at run-time from strings. But saxon:evaluate() is easy to understand, and it >> > often gets used to solve problems where compile-time higher-order functions >> > would be a cleaner and more efficient solution. >> > >> > FXSL, unfortunately, is so powerful that I think many "ordinary" users find >> > it rather daunting. A gentler introduction, using examples from the world of >> > commercial IT systems rather than computer science, would help to sell it to >> > the general public. >> > >> > Michael Kay >> > http://www.saxonica.com/ >> >> > > >-- >Cheers, >Dimitre Novatchev >--------------------------------------- >Truly great madness cannot be achieved without significant intelligence. >--------------------------------------- >To invent, you need a good imagination and a pile of junk >------------------------------------- >You've achieved success in your field when you don't know whether what >you're doing is work or play > > > Justin Johansson

=================================================
- If you are coming from left-field, it helps to see right-field as well. -

- A little Karma goes further than a gallon of gas. -
 -- http://en.wikipedia.org/wiki/Karma
=================================================




--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play

Current Thread