[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RE: Declarative programming requires a different mindset
Something important to add: The most fundamental XSLT feature that makes FXSL possible is <xsl:template> and <xsl:apply-templates>. -- 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 ------------------------------------- I enjoy the massacre of ads. This sentence will slaughter ads without a messy bloodbath. On Wed, Mar 31, 2010 at 9:10 AM, Dimitre Novatchev <dnovatchev@gmail.com> wrote: >> My opinion (to be discussed): >> extracting a subpart of declarations and reusing it in another context >> requires a very deep knowledge of the code structure and of the facts >> that will happen in that given context. >> In one word: reusability is *very* tedious and error-prone. >> > > This is far from the truth. Any code can be reused if it is > implemented as an <xsl:function>. > > The FXSL library for functional programming in XSLT (both 2.0 and 1.0) > is one particular example of reaching and providing an extremely high > degree of reusability. > > Just one "small" example: In FXSL it was very easy to convert and > provide all standard XPath 2.0/XQuery F&Os to higher order functions. > > Most of the functions in FXSL know nothing about who and how is going > to use them -- they are used in myriad of ways that are unplanned and > unthought of. Such genericity and power is much more difficult (if > possible at all) to achieve with an imperative language. > > Why is this so?  Maybe it would help to know that FXSL is mainly a > re-write of Haskell's Prelude module in XSLT. > > > > > -- > 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 > > > On Wed, Mar 31, 2010 at 7:39 AM, Olivier Rossel > <olivier.rossel@gmail.com> wrote: >> >> I am no expert at Prolog, but I have a quite good understanding of XSLT. >> So i would consider myself non-newbie when it comes to declarative programming. >> >> I would like more information about a statement taken from that >> (interesting) conversation. >> >> "In Prolog, components of your program are highly compartmentalized - >> so it is especially >> easy to grab blocks of code and graft them into another process." >> >> As far as I know, reusability in declarative programming is a lot of human work. >> >> For example, in XSLT, you cannot evaluate the relevancy of a >> <xsl:template> just by reading its code. >> You need a very good understanding of the input schema and of *all* >> the other <xsl:template>s. >> And, eventually, running the stylesheet is the only way to clearly >> understand the relationships between the <xsl:template>s. >> >> My opinion (to be discussed): >> extracting a subpart of declarations and reusing it in another context >> requires a very deep knowledge of the code structure and of the facts >> that will happen in that given context. >> In one word: reusability is *very* tedious and error-prone. >> >> On the contrary, when it comes to statically-typed imperative >> languages such as Java, you have a bunch of highly effective static >> analysis tools to assist you when dealing with refactioring, >> modularity, code extraction, static debugging, a priori understanding >> of data structures, data flows and runtime flows. >> >> So my question is: >> what is the R&D status of static analysis tools  for declarative >> programming languages? >> >> >> >> >> >> >> On Wed, Mar 31, 2010 at 4:05 PM,  <w3c@drrw.info> wrote: >> > Kendall, >> > Excellent points! >> > I would say however that personally I try to use the declarative approach as >> > my go to paradigm in xslt - and resort to procedural to handle edge >> > conditions and explicit constructs. >> > IMHO - this also results in smaller more compact and easier to maintain >> > code.  As your example below illustrates. >> > The declarative approach by its very nature supports the general case of >> > inputs - so the code is not brittle - but instead is adaptive to new input >> > patterns that its author had not previously encountered or anticipated >> > directly. >> > DW >> > >> > -------- Original Message -------- >> > Subject: Re: RE: Declarative programming requires a different >> > mindset >> > From: Kendall Shaw <kshaw@kendallshaw.com> >> > Date: Thu, March 25, 2010 5:47 pm >> > To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org> >> > >> > "Costello, Roger L." <costello@mitre.org> writes: >> > >> > [about declarative programming] >> > >> > I enjoy your various posts with high level questions like this. I hope >> > you will keep asking them. >> > >> > The question of what "the definition" of "declarative programming" is, >> > is unanswerable, I think. People use words as tags to coordinate >> > discussion of topics. A conversation often takes the form: >> > >> > Here is a phrase to use as a mnemonic: "..." >> > >> > Here are more phrases asserting the meaning of the mnemonic phrase. >> > >> > Here are more phrases that are meant as an invitiation for you to >> > discuss a topic in terms of those phrases. >> > >> > In such a discussion you make a point by referencing the mnemonic phrase >> > and redefining it. >> > >> >>> A clearer distinction is whether or not the program involves mutable >> >>> state >> >> variables. >> >> >> >> Since XSLT variables don't vary, are all XSLT programs declarative? >> >> >> >> Surely that's not the case. >> > >> > It's worthwhile to think of declarative programming as a style, in my >> > opinion, and not all XSLT programs are written in a declarative style. A >> > declarative programming language would be one that makes declarative >> > programming easier than if it were not a declarative programming language. >> > >> > A program can have parts that are writte in a declarative style and >> > parts that are not. >> > >> > I also think it is worthwhile to think of functional programming and >> > declarative programing as different things. >> > >> > Perl is not a functional programming language, but you can write perl in >> > a declarative style, e.g.: >> > >> > document(title(), body()); >> > >> > is written in a declarative style. >> > >> > You can also program in functional programming style using a procedural >> > language. I suspect you could program in a "less functional" style using >> > a functional programming language, but I can't think of an example. >> > >> >> Would someone give an example of XSLT code that is clearly imperative? >> > >> > This: >> > >> > <!-- given a matching author author --> >> > <xsl:variable name="author" select="f:matching-author(.)"/> >> > <!-- an author-link is the matching author's name and www address --> >> > <author-link> >> > <xsl:copy-of select="$author/name"/> >> > <xsl:copy-of select="$author/www"/> >> > </author-link> >> > >> > is more declarative and less imperative than: >> > >> > <!-- output an author-link start tag --> >> > <xsl:text disable-output-escaping="yes"><author-link></xsl:text> >> > >> > <!-- get the matching author --> >> > <xsl:variable name="author" select="f:matching-author(.)"/> >> > >> > <!-- output it's name --> >> > <xsl:copy-of select="$author/name"/> >> > >> > <!-- output it's www address--> >> > <xsl:copy-of select="$author/ww"/> >> > >> > <!-- output an author-link end tag --> >> > <xsl:text disable-output-escaping="yes"></author-link></xsl:text> >> > >> > So, I think declarative programming is not a precisely definable >> > concept. It refers to those parts of a programming style that you >> > describe as being declarative. >> > >> > Kendall >> > >> > _______________________________________________________________________ >> > >> > XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> > to support XML implementation and development. To minimize >> > spam in the archives, you must subscribe before posting. >> > >> > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> > subscribe: xml-dev-subscribe@lists.xml.org >> > List archive: http://lists.xml.org/archives/xml-dev/ >> > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> > >> > _______________________________________________________________________ >> > XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support >> > XML implementation and development. To minimize spam in the archives, you >> > must subscribe before posting. [Un]Subscribe/change address: >> > http://www.oasis-open.org/mlmanage/ Or unsubscribe: >> > xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@l... >> > List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: >> > http://www.oasis-open.org/maillists/guidelines.php >> >> _______________________________________________________________________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> to support XML implementation and development. To minimize >> spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> List archive: http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|