[Fwd: Re: Language is not markup and markup is not language.

David Carlisle wrote:
> 
> Is it clear that it isn't complete anyway?

I'm not up to proving that XSL isn't Turing complete but I will give some
hints about why I think that it isn't:

> You have recursive calls, and can pass state via template parameters
> what else do you need?

You can pass state but can you work with the state? Remember that the
Turing machines has not only a concept of "current state" but also its
tape. What would we use in XSL to emulate the tape? The obvious choice is
a string, but how do you index to a particular location in the string? The
string manipulation functions don't seem up to the job.

If someone can me tell me how to get and set the "n"th character in a
string then I will believe (and maybe even prove) that XSL is Turing
complete.

Still, optimization is not an on or off deal. The more constrained a
language is, the easier it is to optimize. Compared to scripting
languages, XSL is incredibly constrained. 

Compared to early drafts, however, it is incredibly flexible. Only time
will tell what optimizations are feasible but it is safe to say that some
optimization opportunities have probably been lost. With the early drafts
statically type checking and optimizing seemed almost doable but by now I
am very skeptical. Maybe we need a smaller, more optimizable XSL subset
for some applications....

To me, the big deal is that XSL is still easier to use, once you get into
its mindset. Scripting languages are not as tree-centric unless they are
designed specifically for tree manipulation.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

The first three Noble Truths of Python:
  All that is not Python is suffering.
  The origin of suffering lies in the use of not-Python.
  The cessation of suffering can be achieved by not using not-Python.
http://www.pauahtun.org/4nobletruthsofpython.html


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list