[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RE: Declarative programming requires a different mindset

  • From: Dimitre Novatchev <dnovatchev@gmail.com>
  • To: Olivier Rossel <olivier.rossel@gmail.com>
  • Date: Wed, 31 Mar 2010 09:37:21 -0700

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">&lt;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">&lt;/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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.