[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RE: Declarative programming requires a different mindset
> interesting point ! > > my question is: > how did you ensure that your library (which is declarative > programming, if i understand correctly) > will not be polluted by other declarations coming from other part of > the program, that may interfer with > your own workflows? I don't understand this question completely, however the answer can probably be found here: http://web.archive.org/web/20070222111927/http://www.idealliance.org/papers/extreme/proceedings/xslfo-pdf/2006/Novatchev01/EML2006Novatchev01.pdf -- 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 9:17 AM, Olivier Rossel <olivier.rossel@gmail.com> wrote: > interesting point ! > > my question is: > how did you ensure that your library (which is declarative > programming, if i understand correctly) > will not be polluted by other declarations coming from other part of > the program, that may interfer with > your own workflows? > > > On Wed, Mar 31, 2010 at 6:10 PM, 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
|