--- Jim Self <[EMAIL PROTECTED]> wrote:
> I am not quite sure what you are trying to say here, but I don't
> think that what you said
> is quite correct. There is no hard and fast line between what can be
> done via
> non-procedural specification (query) and what can not. The difference
> is in the
> implementation of an abstraction of the low level process of "walking
> the tree" so that it
> can be carried out from a simple specification ("query").
There's an interesting footnote on p. 7 of the 3rd Manifesto:
"We have recently observed a distressing tendency to confuse imperative
with procedural. While it is true that all procedural languages are
imperative, it is important to understqnd the converse (i.e., that all
imperative languages are procedural) is false. In particular, D [the
data language discussed in the 3rd Manifesto] -- or its relational
portion, at any rate -- is imperative, but not procedural."
I'm still trying to digest that one. I think I know what Date and
Darwen are saying here, but I'm not entirely convinced. In fact, one
idea (as far fetched as it may seem) that I've been toying with is
*functional* data language. I have yet to convince myself that such a
thing is practically realizable, but I think therre are good reasons to
think it could be.
===
Gregory Woodhouse <[EMAIL PROTECTED]>
"It is foolish to answer a question that
you do not understand."
--G. Polya ("How to Solve It")
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
