[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RE: Declarative programming requires a different mindset
Now, that I think I maybe start to understand the question: >> 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? The answer is that all FXSL functions are in the "http://fxsl.sf.net" namespace, and all of its templates, or templates passed to it as parameters, are matching nodes in the same "http://fxsl.sf.net" namespace and/or are in mode ( {http://fxsl.sf.net}, "FXSL" ). In this way one can only mess up things if they start writing functions in the "http://fxsl.sf.net" namespace, which will have almost the same result as if they start writing their own stuff in the "http://www.w3.org/1999/XSL/Transform" or "http://www.w3.org/2005/xpath-functions" namespaces. -- 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:29 AM, Dimitre Novatchev <dnovatchev@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? > > 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
|