xsl-list
[Top] [All Lists]

Re: [xsl] Design approaches to separating "pure" code from "impure" code?

2011-05-21 18:57:28
I don't think XSLT has constructs that are "impure code".

The only questionable ones are the document() function and the
<xsl:result-document> element.

Apart from this, there are some functions, such as unparsed-text() or
the functions that produce the current date and/or/time, but I think
that there is a requirements that the functions should be stable.

Also, any <xsl:function> that creates and returns a new node is
strange because on each call with the same arguments such function can
potentially return a "different" result. I am not sure if such code
should be considered "impure" -- it suffices to define nodes as not
having identity and this "anomaly" automatically disappears.

This leaves only extension (non-XSLT) functions as *possibly* impure.

I think that the problem is not how to keep pure and impure code
separate (this problem simply doesn't exist for XSLT-only code, and
any non-XSLT code is separate from any XSLT code), but how to control
the proper sequencing of impure code. There are wellknown ways to do
this (the Monad type-class in Haskell is an example) and similar
things can be done in any functional language (as I did for XSLT 8
years ago). The real question is not if this can be done, but what is
the best syntax sugar (the "do notation" in Haskell) to make
expressing this in a most comfortable way. Of course, this is a task
for the designers of the language.


-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.





On Thu, May 19, 2011 at 6:45 AM, Costello, Roger L. 
<costello(_at_)mitre(_dot_)org> wrote:
Hi Folks,

This is a general design question.

First, let me define some terms:

I define "pure" code as code that doesn't do any I/O.

I define "impure" code as code that does I/O.

(Dimitre could probably provide better definitions of those terms)

I am seeking your suggestions on ways to organize XSLT code to keep pure code 
and impure code separate.

/Roger

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>